First off you want to get the commit id you currently have deployed and the commit id you want to deploy and copy them to Notepad (or wherever). Next you want to run a diff between the two commits. We currently use BitBucket, so I’ll show that first, but this also works with GitHub (and it’s actually a lot easier).

BitBucket

Annoyingly, BitBucket doesn’t officially support diffing between two commits. However, looking at this issue it seems that it is unofficially supported. We can diff the two commits using the following url:

https://bitbucket.org/OWNER/PROJECT/branches/compare/COMMIT-CURRENTLY-LIVE..COMMIT-TO-DEPLOY#commits

Of course, you’ll need to replace OWNER and PROJECT with the correct values and also replace the COMMIT-CURRENTLY-LIVE and COMMIT-TO-DEPLOY with the commit ids taken from the Octopus releases. The commit ids need to be in the specified order, with the earlier commit (the one currently live) first.

Once you’ve done this you’ll see a screen with the following:

This contains every commit between the two versions. Also, see where it says “Merged in PROJ-99” in the list of commits? That PROJ-99 refers to the JIRA issue that was created for that particular feature. This means we can also tell you exactly what features are about to be shipped! This is fantastic when you go a while between releases, or have many people working on the same project and it becomes difficult to know exactly what was worked on.

You can also see the diff of each file under the “Diff” tab:

So, we can see every line of code that has changed between the currently live version and the version we are about to deploy. Pretty neat!

GitHub

GitHub do actually support diffing between commits. The sytnax is pretty much the same:

https://github.com/OWNER>/PROJECT/compare/COMMIT-CURRENTLY-LIVE..COMMIT-TO-DEPLOY

Here’s what you end up with once you’ve done that:

(Note this is a personal project, so no JIRA issues )

Again, a nice list of commits and the diff between the two versions.

So there you go – now you can know exactly what, down to every line of code, you’re about to release.

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.