Continuous Integration: Fighting the Fear

This is an older post published on my blog on Feb 07 2015, I’m moving a few old posts over here.

The Fear

If you’re anything like me, and judging by the brilliant people I work with there must be more of us out there, then every now and then you get the fear. The fear is that feeling you get when complexity starts to creep in. When processes you have to go through start to get hard to repeat, or begin eating more and more time. The gut feeling that there must be a better way.

Continuous what?

Recently “devops” has become a popular talking point so I doubt you’ll have read too far without hearing the term continuous integration, but just incase I’m your first…


It all starts with git flow for us, we’ve adapted it slightly but it’s the same idea. We have three permanent branches:

  • release is our current staging or UAT branch. Again no one has permission to push into this branch and it has the same restrictions around passing builds. Once we have finished testing a pull request can be made and merged when the project lead is ready.
  • develop is our current integrated build. All other feature branches need to be merged into this branch to move towards a release. Depending on the project size, pull requests are sometimes required so that code can be reviewed by one of the senior team members. Stash gives us the ability to restrict how many approvals are required for a merge and by which group of people.


TeamCity is a “Continuous Integration Server” from JetBrains that really is the the hub of our toolchain. You can configure multiple projects, with each one containing multiple build configurations. A build configuration is essentially a series of steps that can be triggered in different way, for us they’re going to be triggered by our branches.

Octopus Deploy

Octopus Deploy is a brilliant application, pretty much built on top of powershell with one purpose, deploy your software. It’s pretty much aimed at .NET developers, but that’s ok, we’re .NET developers. Your milage may vary.

The big picture

Here’s the situation you have to imagine: Deployments are now run of the mill, your main focus is on the quality of the project. A request come in, you review it with the developer and when you’re happy you approve the merge. Now you go about your work, a message will arrive to let you know it’s deployed in a few minutes so you can go and experiment with the most up to date version.

What does this mean for your team?

Most importantly, they can get on with what you pay them to do. Build things! Personally I’ve found that as we’ve started to decompose our systems into smaller components it started to become a bit difficult to make changes to a service that I’ve not looked at in a while. Did I remember all of the steps required to deploy? Even if it was written down, is it up to date? All of that is gone now, I know the CI server is going to take care of it all for me.