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
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