The scenario:
I have an Azure App Service that is hosting 5 different WebJobs. I have configured a release on Visual Studio Team Services (VSTS) to deploy each WebJob to Azure, independently from each other.
The problem:
Deploying a WebJob deletes the other WebJobs that were already deployed!!!
Solution:
Tick the “Set DoNotDelete flag” – current files/folders in the App Service in will be preserved while publishing website.
I’ve been using Bamboo CI Server for the last few months to automate builds and deployments. I like the tool because it has good integration with Jira (both tools are from Atlassian), it’s easy enough to configure new builds and deployments, triggers, notifications, etc.
But I realised that something important was missing: Bamboo allows you to add a test runner task in a build project but not in a deployment project! This means that you can’t run tests after a successful deployment (smoke tests, integration tests, …), at least not without a workaround.
The trick is to configure your test runner as an executable in Bamboo. These are the steps in order to configure NUnit and run tests in a deployment project (it should work for any other test runner):
Go to Bamboo Administration and click on “Executables” on the left panel.
Click on “add an executable as a server capability”
Add the path to NUnit Console and a label for the new executable. It is important to set the type to “Command” in order to use it in a Deployment project:
Click on the “Add” button to save the new command.
You can either add a new task for the tests to an existing deployment or add a new deployment project that will only run the tests.
I decided to add a new deployment project that will be triggered after a successful deployment because it’s easier to understand if there is actually a problem with the deployment itself or if the integration tests are failing. Also, this way I am able to run the tests at any time without having to deploy the application.
Whatever your choice is, add a new “Command” task to the deployment project:
In the “Executable” dropdown you should be able to find the command you configured for NUnit. Add arguments and environment variables if necessary:
Save the task and run the deployment. This is an excerpt of the generated log that contains the test results:
NUnit-Console version 2.6.4.14350 Copyright (C) 2002-2012 Charlie Poole. Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov. Copyright (C) 2000-2002 Philip Craig. All Rights Reserved. Runtime Environment - OS Version: Microsoft Windows NT 6.2.9200.0 CLR Version: 2.0.50727.8009 ( Net 3.5 ) ProcessModel: Default DomainUsage: Default Execution Runtime: net-4.0 ..F.F.F.F Tests run: 5, Errors: 0, Failures: 4, Inconclusive: 0, Time: 6.8491962 seconds Not run: 0, Invalid: 0, Ignored: 0, Skipped: 0 Errors and Failures: 1) Test Failure : GivenAnUrl_WhenGettingPage_ShouldreturnSuccessStatusCode("/Home.aspx") Expected: True But was: False 2) Test Failure : GivenAnUrl_WhenGettingPage_ShouldreturnSuccessStatusCode("/Services/Activate.aspx") Expected: True But was: False 3) Test Failure : GivenAnUrl_WhenGettingPage_ShouldreturnSuccessStatusCode("/Administration/LostPassword.aspx") Expected: True But was: False 4) Test Failure : GivenAnUrl_WhenGettingPage_ShouldreturnSuccessStatusCode("/Shop/Product/List.aspx") Expected: True But was: False Failing task since return code of [C:\Program Files (x86)\NUnit 2.6.4\bin\nunit-console.exe integration-tests-uat.nunit --config="release"] was 4 while expected 0 Finished task 'Run integration tests' with result: Failed Finalising the build... Stopping timer. Build 12484609-16973828-16613398 completed. Finished processing deployment result Deployment of 'release-16' on 'UAT - Integration Tests'
That’s it! The output is not nicely formatted as in the build tasks but it does the job – you can see how many tests were run and how many have failed (if any).
The scenario – I am working on an ASP.NET web site that is hosted on Azure as a Cloud Service.
I have automated both the build and the deployment to the cloud using the Bamboo build server. The build compiles the solution, runs the unit tests and generates the deployment packages that are used by Bamboo to deploy the site to Azure.
I could use Bamboo to manage all deployments but given that Cloud Services offer out-of-the-box support for blue-green deployments I decided to take advantage of both systems. This is how I have organised things:
Deployment to Staging is performed by Bamboo. Automated tests are executed as part of the deployment to check if everything is working as expected. Additional manual tests should be executed as well before deploying to Production.
This is done using the Azure Management Portal – simply click on the Swap button and traffic will be routed to the Staging environment, which now becomes the Production environment.
Something went wrong? No problem, click on the Swap button again to switch the environments – it’s just as simple as that.
Azure Web Sites or Cloud Services offer out-of-the-box support for blue-green deployments, which provide a simple and powerful way to test a deployment before going to production and roll it back, if necessary.
You can use your Continuous Delivery server in conjunction with Azure Management Portal to manage your deployments to the cloud – consider all the advantages and disadvantages and use the functionalities of each system that makes your life easier 🙂
Rui Jarimba 