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.

Using Visual Studio and SSDT you can immediately publish a fresh database or update an existing one by simply right clicking the database project and choosing ‘Publish’. This will bring up a dialog that lets you edit the connection string to your database and set various options related to the publish.

At this point you have a choice – whether to register your published database as a Data Tier Application or not. Please do so.  There are two distinct advantages

• You can enable database drift detection.
• You can query the server to see what version database is published there, when and by whom.

Registering a database as a Data-Tier Application stores a copy of the current state of the database schema in system metadata tables as well as associated information relating to the publish itself.  To see quick info you can run

select * from sysdac_instances

against the msdb database on the server you published to.

Database drift is a very useful feature that allows you to check whether somebody has directly altered the database in some way since the last publish. I know this is a problem for many small teams – a query is a little slow so an index is added, a default was applied to a column because an app was throwing exceptions further down the pipeline and it had to be fixed quickly. This allows you to detect that, find the changes and if necessary bring them in to your project or else delete them. I always choose the option to block publish when database has drifted from registered version.

Now that you have selected your server, registered the database as a DTA and prevented drift, save the profile in the form .publish.xml. This isn’t just so that you can double click the profile to immediately publish (although you can of course) this is so that when TeamCity (you ARE using CI aren’t you?) builds your SSDT solution you can tell it which profile to use to automatically publish your database.  How good is that?

In the TeamCity build step that actually builds your solution you can select a target of ‘Build Publish’ and then in your command line parameters add the following

/p:SqlPublishProfilePath=<profilename> /p:DeployOnBuild=true

Where <profilename> is the full name of your profile e.g. myserver.publish.xml.

Done!  An easily updated, version controlled database that watches for people messing about with it on the server and lets you know.  What more could you ask for?

Here is the outline of how it all hangs together, I will do a few more detailed posts to follow up.

The solution itself consists of three projects. Two database projects and a unit test project.  They are checked into GIT (using BitBucket) and TeamCity watches the repository to trigger a build.  The build creates a dacpac for each database, publishes the changes to the appropriate server, runs the unit tests and saves the dacpacs into a nuget package that is published by TeamCity itself.

Out of the box, TeamCity can handle the build but you need MSTest and SSDT installed on the build server.  That is where your troubles begin.  You can download an MSTest agent as I wrote about here.  You can even install the SSDT tools for VS2012 (though that was a bit hit and miss for me). The real problem is that with VS2013 the SSDT tools are integrated and no longer available as a separate download.  In the end I had to settle for installing VS2013 on the build server.  Microsoft allows your developer license to be used on the build server and at least I can easily update the SSDT version – I’m not particularly happy about having to do it though.

In order to publish your database to the correct server you just need to include appropriate publish profile files and Microsoft have provided the ability in database unit tests to switch config files according to the build server machine name. The publishing part worked fine for me but the config switching seems flaky and if you put a whitespace in the wrong place your config will be ignored.  My workaround here was to resort to Slow Cheetah – a plugin from NuGet that allows config switching for app.config in the same way that you can achieve it with web.config. This works well but remember to restore your nuget packages as the first build step in TeamCity. It’s not so restrictive as a config that switches based on machine name (we only have a single build server so would be unable to test on multiple platforms).

The result is that on every check in, the dacpacs are built, deployed to a test environment, tested and if they pass, made available via a nuget feed for other projects.

It feels good when it all just starts working!

However if you need to run MSTest for your unit tests TeamCity recommends you install the full Visual Studio.  If you already have a licence for this then it is ok to install a second copy for your build server, but what if the build server is at a client premises and they don’t want to buy a license? I came across this stack overflow post that pointed me to an MSTest Agent download for 2010. You can download the Agents for Visual Studio 2013 from here. All you need is the executable so don’t install the agent as a service and you don’t need the controller.

Hope that helps.