This is not a how-to blog post guiding you to DEVOPS heaven. I write down the steps we are taking to get continuous deployment in place for our project. Every time we take another step I’ll update this post.

First of all: what are we aiming at?

We do our project using scrum. Product owners, scrum master and developers form the team. Like most projects we struggle with things like build, release and automated tests. Things scrum assumes to be just there. What do we want our continuous deployment to do?

Continuous deployment for us is being able to get the software build, deployed and tested without user interaction.

TFS 2015 with the scrum template is the tooling we use. TFVC is the version control. Build will create the software and do the unit testing. Release Management handles the deployment.

Step by step

Below is a schema of the proces we have in place now.

1. Build

First we created a build definition that pulls the sources from version control and puts the software on a drop location. During the build the unit tests are run. This was created the first week of the project.

We created / configured the proces for the build in the project portal. The supplied Visual Studio template was a good start. After a few days we added some steps like a powershell to update the assembly version with the build number.

2. Release

With the build creating software on the drop location we started creating the release pipelines. Installation of the software is done with DSC.

All developers (and testers) now have the tooling to start a release. Everything is triggered manually, but that will soon change.

3. Schedule

In the build definition we setup the trigger to scheduled every night. Now we have a nightly build.

4. Auto deployment

Together with the nightly build we added another step to the build that triggers the release of that build. This is done with an API call. Now we have new software on our server every morning.

Next steps

We plan to include test manager in the mix. After the auto deployment the integration tests are run and a report is waiting our team in the morning.

Takeaway

You might notice that this post is really superficial and not of much use when you run into trouble. Since every project is different and google-is-your-friend, I’m sure you’ll manage.

My post describes the steps we (you) need to take to get continuous deployment implemented in the project. I think multiple small steps are better than one huge leap. In the end we need to add business value by writing software. Sometimes the tooling gets in the way of that.