Web services B2B implementation demonstration: Deployment process

In the eighth article of a continuing series, Kevin Koch implements the debug and release configurations for the Web service applications, creates a deployment script, and explains the principles behind the staging and production configurations.

Now that both demonstration applications are fully implemented, it's time to create a deployment process to propagate the applications to a production environment. We'll examine the change in mind state required once an application is placed in a production environment and develop deployment scripts to make production builds a smooth process.

Development, staging, production
Let's begin by reviewing some common development principles. Most developers are familiar with the terms development, staging, and production in the context of a development cycle. Each term represents a different tier in the development process, with development being the first, staging the second, and production finishing the cycle.

Web services B2B implementation demonstration
Welcome to the seventh article in a 10-part series exploring in detail the implementation of a B2B Web service. The series takes you through the development of a complete B2B Web services application. During the course of the series, we encourage members to comment on the progress of the application. Do you have a better implementation? Do you have a question about our B2B solution? Start an article discussion and let us hear from you; we will do our best to address the issue. Catch up on the series with these articles:

The development cycle is where the formation of the application takes place. This is where requirements and use cases are translated into documentation and code implementation. Unfortunately, the development process often leaves many holes or bugs and/or missed requirements, which necessitate a staging or Quality Assurance (QA) cycle.

The staging cycle is a pre-production environment, which should always mirror the configuration of the actual production environment. This gives the QA team a chance to test the application in a simulated production environment without affecting real production data. The QA team goes through a ritual feature and bug discovery process and escalates any problems into a conflict resolution system.

At this point, we encounter a loop back in the process. Any bugs entered into the conflict resolution system are passed back to the developer, and the process returns to step one again. It may take several staging builds before the QA team is satisfied with the state of the application and gives the approval to pass the build onto production.

Once the application is considered production ready, a hand off usually takes place with an operational department that is responsible for uploading the staging server build onto the production server. Minor changes may need to take place for any misalignment of configuration parameters between the two servers. Typically, a release notes document is generated for customers or any other teams in the company so they are aware of the changes that were made.

All measures humanly possible should be taken to ensure that the build placed on the production environment is stable and free of critical bugs. Imagine a bug causing data corruption slipping past the QA team and causing loss of revenue for thousands of customers or irreversible database damage. The importance of a stable production build cannot be stressed enough.

Fortunately, deployment of an ASP.NET application is relatively simple. Most ASP.NET developers are familiar with the so-called XCopy deployment process, which, essentially, copies the entire contents of the development build to the staging server.

It is my personal preference to not have any source code placed onto the staging or production servers, so we will implement a secondary step in the XCopy deployment to strip out files that are not necessary for staging and production builds.

For the purpose of this article, we will run through the process of creating the staging/production build since most developers will not have access to multiple servers. We'll begin by creating the deployment script for Tom's application.

Navigate to the folder where Tom's B2B application resides on your hard drive and create a subfolder named "deploy." It's important to do this outside of Visual Studio because we don't need this folder included in the actual application environment; it is simply a supporting member of the application.

Within the deploy directory, create two new files named DeployWSB2BTom.cmd (Listing A) and ExcludedProjectFiles.txt (Listing B).

The .cmd file runs as a command prompt window and uses the simple DOS XCopy command to copy the directory structure of Tom's application to a new location. You will need to edit the file to replace the paths with the correct paths to Tom's application on your local hard drive. Also, create the correct destination folder structure as desired.

You'll notice the XCopy command has a few parameters specified. The /S switch indicates to copy all subfolders and the /Y switch indicates to disable overwrite confirmation messages. The final parameter points to the ExcludedProjectFiles.txt text file, which contains a list of files that should not be copied to the destination directory.

Within this text file there are a number of particular file extensions that are excluded, as well as specific directories. All files, folders, and global extension identifiers that are not required for production are listed within this text file, one per line. The excluded files and directories are either required for debugging or have no relevance to the functional portion of the application.

Before executing the command script, open up Tom's ASP.NET solution file in Visual Studio .NET. With the simple flick of a drop-down, we can configure the application to be compiled in an optimized format for production. Next to the play button in the VS.NET IDE, there is a drop-down that should currently be displaying "Debug." Click on this drop-down, and select "Release."

By making this change, we tell Visual Studio to compile the application without debug symbols and debug information and also to compile the application using the different parameters specified in the configuration manager. Because our application requires no specific changes in the configuration manager, we can simply flip the drop-down to "Release" mode and then rebuild the application.

Once the application has been recompiled, we can then run our deployment script. Double check the paths to ensure the correct directory structures are in place; then, double-click the DeployWSB2BTom.cmd file in Tom's deploy directory. A command prompt window will appear and list all of the files that were copied; it will pause upon completion. Hit any key to close the window once it is finished.

We now need to duplicate this functionality for John's application. Repeat the same process by creating a deploy subfolder below John's main application directory. Create two new files named DeployWSB2BJohn.cmd (Listing C) and ExcludedProjectFiles.txt (Listing D).

Each server will more than likely require its own separate configurations. A good way to manage this is through your source code repository application. Creating a configuration file and then separate subfolders—for development, staging, and production—will allow you to place the same files with different configurations into each folder. For example, your database connection string in your Web.config file may be different between servers, so a separate Web.config file would be placed into each configuration subfolder for each server.

The build deployment scripts we created deliberately leave out the Web.config file because 99 percent of the time it is not universal across all servers. Once the build is created, it is simply a matter of extracting the correct configuration files from your repository for the appropriate server.

Once the configuration changes have taken place, the entire build can be zipped up into a package and sent to the production/staging server. It is then unpacked on the server and extracted into the correct folder in real time. One of the benefits of ASP.NET is that you can do live updates without affecting the application.

However, a caveat I've encountered through my own experience is that the ASP.NET worker process is restarted if your assemblies have changed, and, therefore, the existing user sessions are dropped. This is apparently not supposed to happen but does.

Next in the series
In the ninth installment of Kevin Koch's Web services B2B implementation demonstration, he will: provide a complete walkthrough of the entire application, diagram application flow, and transaction threads; discuss possible enhancements and extensions; and reiterate main design points and principles.

After updating the production/staging build, the new assemblies and Web.config files are loaded into the .NET runtime. It is always a good idea to run a simple sanity test through the system to ensure that the application is functioning correctly.

Editor's Picks

Free Newsletters, In your Inbox