Developer, tech enthusiast, and gamer.

Continuous integration and delivery to Azure websites with Bamboo

Fortunately for Azure developers, there are a lot of great ways to set up continuous delivery (CD) to Websites. For less complex continuous integration (CI) scenarios, I use kudu deployment scripts in conjunction with the built in support for Github, Bitbucket, and TFS. In a more complex scenario that requires additional steps like unit test runners for both .NET and JavaScript, I use Bamboo CI server. As build servers go, Bamboo has quickly become one of my favorites. And if your ALM lives in the Atlassian world like mine does, integration between tools like JIRA, Stash, and Confluence really make Bamboo the ideal CI server in your devops workflow.

Set up your build plan

This is pretty straightforward if you set up a build in other build servers like TeamCity or TFS Build services. In the case of a .NET app, you'll checkout your code, run Nuget package restore, run MSBuild against your sln or csproj, and finally publish your results as an Artifact (more on that later).

Once your plan is set up, then you can define the tasks for your build. A basic 3 step plan of code checkout, package restore, and build is a the ideal starting point. Once that's working well, you can then add in any other more customized tasks like test runners.

For the Script task, I'm calling the nuget.exe I've added to my repository in order to supply custom credentials for my private feeds in my nuget.config. Another great way to do this in Bamboo is to add the nuget.exe as a custom executable in the server configuration. Once added, you can use the Command task to call Nuget and pass in any arguments.

For the build step, I'm using the MSBuild task, specifying the version, and then passing in the configuration argument for a Debug build.

Now that the Tasks are set, I want to do one last thing which is publish my build output as a shared artifact to make it available to my deployment project. Via the Artifacts tab, I select Create definition, and then name and supply the pattern for the files to become available.

Set up your deployment

First, create a new deployment project and link it to the build plan you just created. Your new project will allow you to set up one or more environments for you to promote/deploy your builds to. For example, you may want to enable CD to your development web site but you also want the ability to promote a build directly to production.

For each environment you set up, you'll have the ability to set up the tasks necessary for deployment as well as its triggers and notifications. For example, you'll want to trigger a deployment to your development website after each successful build on your main develop branch but would not want that same trigger on your staged production environment.

To make the actual deployment to my Azure website, I'm using an MSBuild task against my build output artifact supplying the /p:DeployOnBuild command along with the /p:PublishProfile with a few additional arguments to make the deployment happen successfully. The key requirement here however is that I've already downloaded my publishing profile from the Azure portal for my Website and have imported it into my project via the Publish dialog in visual studio.aspx). The only customization I've made to the imported profile was to remove the password so that its not stored in source control, allowing me to simply pass it as an argument to my MSBuild deployment task.

So why MSBuild and not WebDeploy? Web deploy is incredibly difficult to use from the command line as many will attest to. I've tried and failed myself, which is why I've ultimately settled on this very reliable and customizable method of deployment. And while I'm essentially building the project twice, there is very little overhead in doing so. It even gives you an opportunity to tune your deployment build with additional arguments, like switching to Release (with config transforms) when promoting a dev build to production.

commit -> trigger build -> successful -> trigger deployment -> deployment complete -> ask for raise

Integrate Stash with Slack via incoming webhooks

Integrate Stash with Slack via incoming webhooks

Kegbot and the dream of merging beer with technology

Kegbot and the dream of merging beer with technology