The Smoke Tester Solution Structure and your First Test

Recently I open sourced a very useful tool called the Post Deployment Smoke Tester. The Post Deployment Smoke Tester is a tool that allows you to run a suite of tests on your environment after you have deployed a piece of software. These tests are invaluable in a large corporate enterprise as more often than not, the people who are doing your deployments are not the original developers.

Out of the box the tool contains many tests that should be immediately useful to you, but you may wish to add in your own. It is early days for this tool so we wont have provided everything that is possible out of the box. If you do need to add in a new test type then you can do so very easily.

If you do want to add or amend any of the tests, then this short article will help you navigate around the Smoke Tester solution structure.

The Smoke Tester tool is split into 4 main components. TestConfiguration, InstallationSmokeTest, ConfigurationTests and CommonCode. The relations-ships between these 4 modules are shown below.

Architecture Diagram for the Smoke Tester Modules
Architecture Diagram for the Smoke Tester Modules

Both TestConfiguration and InstallationSmokeTest are your test editor/runners. Generally you won’t have much need to change these unless you want to add some extra functionality. You main areas of interest will most likely be the ConfigurationTests and CommonCode assemblies. This is where you modify or implement new test types.

Advertisements

Post Deployment Smoke Testing Open Source Project

I have just released a new open source project called the Post Deployment Smoke Tester. This project has been a collaborative effort between a number of fellow developers in response to a typical enterprise software development problem, getting rapid feedback on the success of your deployments into production.

This tool has literally saved my teams bacon a number of times, and maybe it can help you too.

The credits for this toolset are as follows:

Open Source Release : Stephen Haunts

Original Author : Hugh Phoenix-Hulme

Contributors : Stephen Haunts, Jon-Paul Flood, Daniel Steele, Oliver Sintim-Aboagye, Mark Jones

The all Familiar Problem

For anyone working in an Enterprise Software environment, I am sure you have all encountered the same problems. You finish your development and testing. You package up a release and prepare all the release documentation for the operations team and submit the change request into your Change Request system for approval. Then the release is deployed during your standard outage/change window, normally at an ungodly hour of the night.

Smoke Test Config Editor - Results
Smoke Test Config Editor – Results

The people who do the deployments generally have no knowledge about what they are deploying, they will just follow the change instructions that you have written. You will normally only really know if the release has been a proper success once your users get their hands on it the next day. In some businesses that can be a big risk if an outage or problem with the system has a financial or customer service impact.

Integrating Continuous Delivery into a Large Organisation

I recently started working for a new company as a Development Manager, and one of the things I am looking to introduce with my new team is a Continuous Integration and Continuous Delivery pipeline to make us more efficient at delivering reliable releases, frequently into production. Whilst I was looking for some useful resources for the team I came across an excellent video by Jez Humble that discusses not only Continuous Delivery, but the challenges faced in introducing this into large organisations with mature waterfall style change control processes.

This video is an excellent introduction to the topic and if you are also considering introducing a similar process into your organisation, then I highly recommend watching the video. The technology side of introducing Continuous Delivery is quite straight forward. There are many tools, patterns and practices available to help you with this no matter what you development environment it. My teams environment happens to be .NET using TFS, but this is all just as relevant even if you work in other environments like Python, Ruby, Java etc.