A solid continuous integration strategy for an enterprise web application is more than just an automated build. You really need a layered approach to maintain a high level of confidence in your code base.
- Run unit tests – these are fast running unit tests with no external dependencies. We use NUnit.
- Run integration tests – these are tests that have a dependency on a database. The primarily purpose is to test NHibernate mappings.
- Run acceptance tests – these tests are written in the Given, When, Then style. We write the tests in BehaveN, but we expect that a stakeholder could read them and verify the business rules are correct.
- Deploy to CI and run UI tests – these are qunit and Selenium tests. They require the code to be deployed to a real web server before the tests run. That’s what this article is about.
- Deploy to QA – once the automated UI tests have passed, we deploy to our QA server for manual testing.
Step 1: Install WebDeploy on the web server you want to deploy to.
Step 2: Configure Web.config transforms. This will enable you to change connection strings and whatnot based on your build configuration.
Currently this is only supported for web applications, but since it’s built on top of MSBuild tasks, you can do the same thing to an App.config with a little extra work. Take a peak at Microsoft.Web.Publishing.targets (C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web) to see how to use the build tasks.
<UsingTask TaskName="TransformXml" AssemblyFile="Microsoft.Web.Publishing.Tasks.dll"/>
<UsingTask TaskName="MSDeploy" AssemblyFile="Microsoft.Web.Publishing.Tasks.dll"/>
Step 3: Figure out the MSBuild command line arguments that work for your application. This took a bit of trial and error before landing on this:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe MyProject.sln /p:Configuration=QA /p:OutputPath=bin /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MsDeployServiceUrl=https://myserver:8172/msdeploy.axd /p:username=***** /p:password=***** /p:AllowUntrustedCertificate=True /p:DeployIisAppPath=ci /p:MSDeployPublishMethod=WMSVC
Step 4: Configure the Build Runner in TeamCity
Paste the command line parameters you figured out in Step 3 into the Build Runner configuration in TeamCity:
Step 5: Configure build dependencies in TeamCity. This means the integration tests will only run if the unit tests have passed and so on.
Step 6: Write some code.
Nice work. Do you use Selenium to parse the QUnit output on a number of targeted browsers?
Yes, we’re using Selenium to parse the QUnit output, but only on Firefox right now. Also, Selenium RC is running in a console window. The next step is to work launching the server component into the build process or test fixture setup and teardown.
Nice post Michael, I’ve got one little question for you; do you know if it’s possible to authenticate via integrated auth in the MSBuild command rather than needing to put plain text credentials in the params?
I’m not sure if it’s possible, I’d like to keep the password out of the config too.
Well I’ve got the question out there, let’s see if there are any bites: http://stackoverflow.com/questions/4210379/can-msbuild-deploy-using-integrated-authentication-or-only-basic
Short of an acceptable answer, you can create an MSBuild file to build the .csproj targeting “Package” then a separate target to execute the [project].deploy.cmd command in the package. This one runs integrated auth by default, it’s just that it’s a bit clunkier than one nice MSBuild command against an existing .csproj.
I did a little digging and posted a response to your question on stackoverflow. I haven’t tried it out yet, but it looks like /p:AuthType=NTLM might be worth a shot. Good luck!
Just solved this here: http://stackoverflow.com/questions/4210379/can-msbuild-deploy-using-integrated-authentication-or-only-basic
Drop the password param but keep username and don’t assign it a value. Strange, but true…