While re-implementing my continuous delivery pipeline in TeamCity last week, I skipped over charting the load tests results from WCAT. This weekend I returned to this task to find that it was less tricky than it originally appeared.

So what do you do when you have a nice little build lab with two implementations of an automated deployment pipeline that includes unit testing, automated interface testing, automated deployments, smoke testing, automated load tests, static analysis, warning tracking, and automated sort-of QA and production deployments? Take it to the cloud, of course.

Over the series of 12 posts, I have built a continuous delivery pipeline around the MVC Music Store tutorial web site. The journey included making changes to support unit testing, creating a CI build, adding automated multi-environment deployment, automated interface testing, automated load testing stage, and static analysis. Up until now, this was entirely on Jenkins, but today I intend to re-implement the pipeline on TeamCity.

As part of a long series of posts, I implemented a version of the MVC Music Store tutorial application on top of a pair of SQL Server CE databases. SQL Server CE is great for small apps, being a portable file-based database that can easily be moved to a full SQL Server instance. Last week I migrated my application to use full SQL Server instances instead of the SDF file and picked up a 3x performance improvement. It was interesting enough that I decided to share :)

Running static analysis checks can help keep us on track with our standards, identify unused code, identify similar code blocks, and much more. In a manual process, running these tools can be time consuming, costing time to wait for the run complete, more time if we don't abandon them after the first run and have to maintain a schedule, and even more time if someone has to keep a spreadsheet somewhere to compare the results from run to run. Add an automated build process, and we can net the same level of information and trending for a modest setup cost.

Adding load testing to my continuous build process provides several benefits for a fairly cheap entry fee. As the development process progresses, I'll have a baseline and know if I add something to the application that impacts the performance. I'll also be able to accurately discuss it's performance when asked, instead of guessing.

Automating the deployment of software to the various test, QA, and Production environments streamlines the software delivery process, provides a well-practiced routine prior to the production deployment, and removes a lot of the risks that come with depending on people's memories and checklists in order to get a working production push.

Human beings are good at creative tasks. Put an end user in front of an interface and ask them to find an error and good luck stuffing that particular cat back into the bag. Where we don't perform as well is performing those tasks repetitively.

Executing an integration build and unit test run on the build server is all well and good, but before we can say a build is complete and ready to go, it's a good idea to know it will work when it is deployed. Executing a test deployment and then smoke testing it will ensure the archived build is ready to be deployed to test or production environments and that the necessary configurations and resources are available and working.

The purpose of the integration build is to bring potential issues to the surface as quickly as possible. Unit tests run quickly and adding them to the continuous integration build helps flush out defects as close to the beginning of the process as possible. Generally build engines will support unit test framework by directly integrating with them or by providing an ability to execute the test framework and import their results.