Having a fully automated build and release process is, in my opinion, one of the best things you can do as a development team. We’ve spent the last 2 years moving to a fully automated build and release process and it has had an enormous impact on the way we develop and, more importantly, release software. Releasing has gone from something we do on average quarterly to something we can do daily if required. I shudder when I think of doing a manual release now – the time taken, the mistakes when setting up the release (manual backups, spelling errors or wrong values in configs, not remembering to copy all the necessary files or folders, etc…).

Here I want to demonstrate one fantastic benefit of having an automated release process – knowing exactly what you’ve deployed, down to every single line of code.

Here’s a screenshot of an Octopus release, which shows exactly what commit this code is running from:

We can see that this release is currently on our test environment by the green tick next to “Test” under the “Lifecycle” section. The bit in the red box is what we’re really interested in here. This tells this release is running the code that was checked in with commit id “ff83e86…”. We can take this id and link it back to our VCS (we currently use BitBucket, a VCS based on Git). Here is the exact source code now running in test:

So how do we include the commit in the release? Octopus uses NuGet packages as its deployment mechanism. NuGet packages can contain release notes, and it is these release notes that get displayed in the red box in the image above. We can include a release notes file in the project, use TeamCity to update it with the commit using a straightforward PowerShell script, and include it when building the NuGet package.

Setting up the files

There are two files we need: the release notes file and the PowerShell script to update the release notes file.

Note that here I’ve included them at the solution level as there’s only one project we will deploy, however these can be put at a project level if required.

Both the files are simple affairs. Here’s what each file contains:

ReleaseNotes.txt

Commit: %commitId%

UpdateReleaseNotes.ps1

Param(
[string]$commitId
)
(Get-Content .\ReleaseNotes.txt) | Foreach-Object {$_ -replace '%commitId%', $commitId} | out-file .\ReleaseNotes.txt


The release notes contains a placeholder for the commit id. The PowerShell script opens the release notes file, replaces the placeholder with a passed in parameter and saves it. This parameter will come from TeamCity.

Running the PowerShell script

Next up we need to run this script from our build server, passing in the commit id that triggered the build. In the build configuration, add a build step to run a PowerShell script:

(Note to self: update TeamCity!)

Here we are running the PowerShell script and, in the Script Arguments, passing in one of TeamCitys built-in parameters – the commit id from our VCS that will be used for the build.

Adding the release notes to the NuGet package

Now all that is left is to add the ReleaseNotes.txt to the NuGet package that is built by OctoPack. OctoPack has a number of parameters it accepts, one of which is the location of a release notes file:

And we’re done! Now, whenever we deploy the release using Octopus, we will see the commit that the release was built from.

Edit: Erik Eckhard has a great way of achieving the same result without adding a file to your solution in the comments below.