The Deployment Designer

The Deployment Designer

The Deployment Designer is typically the final Distributed System Designer that you will use in a given iteration. This designer will allow you to perform a pre-deployment verification step, called a trial deployment, in which you validate the deployment of your application against a specific logical datacenter. During this process, settings and constraints will either fit together nicely or clash and generate warnings and errors.

To create a deployment diagram, you must have a completed application diagram and at least one logical datacenter diagram completed as well. Right-click the application diagram and select Define Deployment. Visual Studio prompts you for the logical datacenter onto which you want to deploy your application. (See Figure 5-15.) In other words, choose the datacenter against which you validate your application.

Figure 5-15 Defining a trial deployment

TIP
If you created a system diagram, you can right-click that diagram and define the deployment.

Using the Deployment Designer is quite easy. You just drag an application from the System View—which provides a list of all the applications in your application diagram—onto the appropriate Host server in the logical datacenter. Repeat this process until all your applications are bound. Figure 5-16 shows the Deployment Designer with two of the three applications bound to the public and private IIS server Hosts, respectively. Only the wsReview ASP.NET Web service remains unbound.

The designer will provide visual feedback via tooltips that indicate the compatibility of the application on the logical server. This will guide you to appropriately bind the application to a valid server. The feedback also checks for compatible endpoints (communication capabilities), and hosting restrictions enabled by the model.

Figure 5-16 Binding applications to a Host

Validating the Deployment

Much of the deployment validation is done as you are dragging and dropping your applications from the System View window onto the Logical Datacenter Designer surface. Right away, the simple communication rules are enforced. For example, if you try to drag an application that requires HTTP access onto a Host that doesn't support that type of endpoint, it won't drop. Instead, you'll get the “no drop” mouse pointer (a circle with a line through it). This occurs because communication can flow only between certain connected endpoints and is restricted to using only the same type of communication paths that are in the datacenter model.

TIP
If Visual Studio stops you from dropping your application onto a Host and gives you the “no drop” pointer, just hover your cursor over that Host for a second or two and a tooltip will pop up, indicating what the problem is. More than likely, the Host doesn't have the right kind of endpoints and you'll need to return to the Logical Datacenter Designer to make some adjustments.

Deeper constraint violations won't be apparent until a validation is performed. Remember that much finer policies can be created using the Settings and Constraints Editor, in both the Logical Datacenter Designer and the Application Designer. Individual elements in the diagrams can be provided with constraints that further restrict the behavior and capabilities of applications deployed in the datacenter. These constraint violations won't surface as you are dragging and dropping, but they will occur later when you actually validate the diagram and review the errors and warnings.

To perform an explicit validation, you need to right-click the deployment diagram and then choose Validate Diagram. Make sure all your applications are bound correctly and no implicit validation errors or warnings occurred. The validation process will compile all the related documents and then provide a list of errors and warnings. (See Figure 5-17.) No errors or warnings means that your application will deploy successfully to the datacenter.

Figure 5-17 Deployment errors and warnings

NOTE
Some items in the error list can be double-clicked, taking you directly to the offending application or Host. Make your changes according to both the guidance of the error message and that of your organization. What I mean is, don't let the tool override your constraints. Errors and warnings sometimes mean that the infrastructure architect and application architect need to meet and talk, compromising where necessary.

Generating a Deployment Report

The deployment report is simply an XML document that can serve whatever purpose the team might have. It can be transformed or used as input for some other process, such as scripting a deployment. Team System also generates an HTML report for reference. It contains the following information:

• Inventory of all systems, including names and types

• Resources for each of the systems, including assemblies, executables, directories, resource files, endpoints, and web.config files

• Server settings, including versions, domain controller, terminal server, IIS settings, application pools, .NET versions, and GAC settings

• Embedded diagrams (optional)

The report serves as a bill of materials report for the deployment team. It enumerates all the servers and services. Figure 5-18 shows an example of the report as it is in XML format. Figure 5-19 shows the same report as HTML, suitable for presentation and communication with IT professionals and architects.

Figure 5-18 Sample deployment report (XML)

Figure 5-19 Sample deployment report (HTML)

TIP
Look for a file named DeploymentReport.xsl. It contains the XSL template that converts the XML deployment report into the nice-looking HTML report. Feel free to edit this .xsl document to customize the deployment report. By default, this template is found in \Common7\Packages\SDM\XSL\1033 (for US English).

Both the XML and HTML documents are generated from the trial deployment created using the Deployment Designer. Team System provides you with some options when generating the report, such as including the diagrams, owners, binaries, source code, and other content files. When generated, all these files are copied to a specified folder, maintaining a structure of all the files. For troubleshooting, you might also want to run the report, asking to see only exceptions. Figure 5-20 shows the various reporting options that are available.

Figure 5-20 Deployment report options

NOTE
Microsoft has said that a future version of Team System will allow the deployment report to be used as input for automated deployment, possibly integrating with Microsoft Operations Manager (MOM) and Systems Management Server (SMS).