Walk-Thru: Using Wolfpack to automatically deploy and smoke test your system

First, some history...

The advent of NuGet has revolutionised many many aspects of the .Net ecosystem; MyGet, Chocolatey & OctopusDeploy to name a few solutions building upon its success bring even more features to the table.

I also spotted that NuGet could solve a problem I was having with my OSS System Monitoring software Wolfpack; essentially this is a core application framework that uses plugins for extension (Wolfpack Contrib) but how to unify, standardise and streamline how these plugins are made available? NuGet to the rescue again - I wrapped the NuGet infrastructure (I deem NuGet to be so ubiquitous and stable that is has transcended into the software "infrastrucuture" hall of fame) with a new OSS project called Sidewinder. Sidewinder allows me to wrap all my little extension and plugins in NuGet packages and deploy them directly from the Wolfpack application - it even allows me to issue a new version of Wolfpack and have Wolfpack update itself, sweet huh?

About the same time as Sidewinder was born, I also started another OSS project called TripleA as result of discovering "Continuous Delivery" - this project set out to streamline the building of system level and deployment verification tests (TripleA is the helper framework that this article alludes to) that should be used to provide "system" level verification that a deployed version of your application is fit for purpose and ready for a more in-depth rigorous test cycle.

So...to finally tie all this together I want to present the intersection of these projects as a free, OSS solution for the automatic deployment and smoke/system/deployment verification test of the your software.

Scenario

A very typical scenario encountered during development is something like this...

• Make a change, locally test it
• Commit the change, starting a build on the CI server
• Deploy the build
• Run some smoke tests
• Promote the build through the environments after further testing

Wolfpack brings automation to the majority of these steps...

1. A developer makes a change and triggers the CI build process. Unit tests run and a build is produced. Two NuGet packages are also produced - one contains the application deployment (lets say this is an ASP.Net website) and the other contains the smoke tests to verify the deployment and that the application is working correctly, at least enough to commit to more in-depth testing.

2. These two NuGet packages are uploaded to a NuGet feed server as part of the build script. There are several options here...

• MyGet - "NaaS" - NuGet as a Service
• Host your own - instructions for hosting your own private gallery

3. Wolfpack is running and has the "Deployment" plugin installed and configured to detect new versions of the Application Deployment NuGet package.

4. The Application Deployment NuGet package is downloaded from the feed and unpacked into the configured folder on the target server. The contents of the NuGet package could include MSI, BatchFile, Powershell script, MSBuild script etc or even something like a Dropkick deployment. Wolfpack will run the command line it has been configured for once the package contents have been unpacked.

5. Once the command line has completed a Wolfpack alert is generated based on the exit code of the process it started to perform the deployment. Wolfpack offers a number of plugins to communicate its alerts including email, hipchat, growl (prowl to smartphones).

...phew...ok, we have automated the deployment side of things...the latest build of your application is installed on the target server - but does it work...is that new feature working or that bug fixed?

6. Wolfpack can also be configured to go and check for a NuGet package update in response to ANY alert that it generates...perfect, the alert that told us the Application Deployment package had executed provides the trigger to check for a Smoke Test NuGet package update; as a new version has been created Wolfpack downloads it...
7. ...and as part of the download Wolfpack will also detect any dependencies your Smoke Test package has and download those too...what's that...your Test package has a dependency...on the NUnit.Runner package? No problem...that's been pulled down too, it saved you including it your package!

Wolfpack "Growl" alert containing test results

8. Ok, the Smoke Test package and all dependencies has been downloaded and unpacked...Wolfpack will now run the command line you have configured it with to execute the NUnit console app against the assemblies that contain your tests. This will produce an xml file containing the test results - Wolfpack will parse this and extract the pass/fail/skipped etc counts and...
9. Finally create an alert containing the test result information
10. Automated deployment and smoke test complete!

The two alerts Wolfpack generated during this process can optionally be stored in a Wolfpack database - it supports SqlServer, SQLite & MongoDb at the moment. Storage of alerts allows you to query them in the future (for instance the duration of the deployment is captured) and to also hook this data up to some sort of visualisation...oh, did I mention that Wolfpack has native support for Geckoboard, one of the leading business intelligence dashboards?!

Sidewinder

Sidewinder is the silent partner in all of this. In order to leverage NuGet as a deployment package for my plugins I needed a wrapper around it to be able to control it from within Wolfpack. I also quickly realised that what I was trying to do was...

A) not Wolfpack specific
B) able to deploy pretty much any file your application might need post installation.

So I immediately started the Sidewinder Codeplex project and to ensure it "delivered the goods" I was to dog food it with Wolfpack. Sidewinder allows you to package files and deploy them from within your own application - these could be binaries (as in the case of a Wolfpack plugin) or content type files, anything really and it works like this...

1. You package up the new files you want to deploy into a NuGet package and publish this to a feed.
2. In your application solution you reference Sidewinder via its NuGet package and add a small snippet of code that instructs Sidewinder to check for an update to the NuGet package that contains your updates.
3. Sidewinder indicates if a new version is available and your application should quit running with a suitable message as it will have file locks on the very same files you might be updating.
4. In the meantime the Sidewinder library has downloaded the NuGet package and unpacked it to a temp folder and launched Sidewinder.exe....this is waiting for your application, the one that launched it, to close...
5. Once your app shuts down the waiting Sidewinder.exe completes the deployment by copying the contents of the temp folder to the root of your application.

Sidewinder can also be used independently to download ANY NuGet package (optionally plus dependent packages) and deploy it to ANY folder you choose - it doesn't have to be embedded directly in your application. To do this just call Sidewinder.exe from a command prompt with the name of the package to download and a folder to install it into like this...

sidewinder.exe /p wolfpack /i d:\wolfpack

This will download the entire Wolfpack install package and place it in d:\wolfpack - you are ready to rock with Wolfpack. 

Now - if you are familiar with Chocolatey you will be saying hold on a minute, this is what Chocolatey does...and better too (Sidewinder doesn't run any powershell scripts in your packages)...and you would be right to a degree.  Sidewinder was born to provide an update mechanism that was embedded internally to your application - if just so happens that a slight tweak to the original design allowed it to be used directly from the command prompt too. It's a lightweight, stripped down NuGet package installer can simply grabs the package and puts it into a folder of your choice.

TripleA

So far I've illustrated Wolfpack (and Sidewinder as this does all the NuGet package downloading) in action...what about TripleA I hear you ask?

TripleA is designed to make writing smoke or deployment verification tests a lot easier. It is not a new testing framework and it does not replace NUnit, MSpec etc - rather think of it as a set of extensible helpers that you can call from a test within your existing test framework that lets you arrange and assert things at a "system" level.

It turns complex things into simple, parameterised one-liners(ish) that can arrange or assert something about your system.

eg: your latest deployment should redirect users that belong to a specific role to a new landing web page. Think of the code involved to do that...ensure a user exists in the database for the role, call the web page and login with the user identity, assert that you are redirected to the expected url....it is not trivial stuff. TripleA makes this easy in four simple steps.

1. Create the TripleA session and configure it with two steps...
2. Add the custom sql step to add a new user to the database in the correct role
3. Call the login webpage passing the credentials and asserting the redirect url is as expected
4. Execute the session (think of this as a pipeline of arrange or act steps) and assert that the steps all passed.

TripleA ships with fairly good support for web, database (SqlServer), windows services, file system and process manipulation so you have a great chance it will work right out of the box for helping you verify a deployment of your system. It is also built from the ground up with extensibility in mind (all the built-in components are created using the extension framework so I know it works!) - you can roll new extensions really easily so creating domain specific arrange/asserts steps that developers can then easily use in new tests.

You can do it

You will need...
1. Wolfpack, grab the zip from codeplex and unzip it (remember you might need to right click and "unblock" it before you unzip it).

• Wolfpack is a windows service but also runs as a console app, recommended to use it like this whilst you are evaluating it.
• In the next version (2.5) Wolfpack will be installable via Chocolatey

2. Install the "deployment" plugin. Simply open a command prompt and CD to the folder you unzipped Wolfpack to.
3. Type wolfpack.agent.exe /update:Wolfpack.Contrib.Deployment

• This will download and install the dlls/config that contain the NuGet version check and automatic NUnit runner.
• You will need to follow the configuration guide here to set up these plugins

4. Create two "demo" NuGet packages - one with something you would like deployed and one with some NUnit tests in you would like run.
5. Wolfpack should deploy the former and execute the latter and send you an alert after it has done each!

Hopefully I have demonstrated how Wolfpack, Sidewinder and TripleA work together to produce a free, open source automated deployment solution...and remember Wolfpack does a lot more...once installed on a server to automate your deployments it can also monitor a whole range of system parameters such as disk space, MSMQ's, cpu load, ssl certificate expiry to name a few!

Some related posts of mine you might like...

• DDVT - why you should approach your smoke tests/deployment verification with a declarative/bdd/test first stance.
• Deployment, the final (.Net) frontier - I guess the post that really started the journey that this one finishes! 

Finally I'd like to do more of these "Walk-Thru" guides for common scenarios where you might want to deploy Wolfpack. It's grown into a pretty extensive system and part of my frustration is getting the message out to people just what it is capable of - hopefully these "walk-thru" guides can help achieve this and if you have any requests I'd be happy to consider doing a guide for your scenario. I'll probably put these on the Wolfpack codeplex wiki eventually - better to concentrate the documentation in one place.

Some future guides I would like to write are...

• Using Wolfpack with Geckoboard - how to set up the Wolfpack Geckoboard Activity to power your Geckoboard business dashboard.
• How Wolfpack can monitor your CI build - the BuildAnalytics feature allows you to monitor build status and extract stats from common build artifacts like test and coverage results.
• AppStats - how you can actively pump KPI/metrics into Wolfpack so they can be tracked (and visualised with Geckoboard).

As always if you have an issue or suggestion for any of these projects then the best place to get in contact is through their codeplex discussion page.