My Continuous Integration and Automated Release Build System

Generally, if something bad is going to happen, it's best to know about it sooner rather than later. To me, this is a lot of what continouis integration (CI) is about.

When contemplating a build server for the Darwen Audio Software Project I was considering setting up a dedicated machine. However, I didn't like the excess. Yet another machine consuming power and space, and frequently sitting idle waiting to start a build.

So, I thought, why not give it a try on my main development machine? This machine contains an Intel i5-3570K processor and 24 GB of RAM. Using this machine simultaneously as a build server meant I'd be running multiple VMs as build agents on it, in addition to my normal development tasks (usually using Visual Studio 2015).

I wasn't sure how lagging performance might be but it ended up working out really well. I don't notice any lag at all when using Visual Studio and having all three VMs running. I have Jenkins running on the host OS as it watches my repo's mainline so that a new git push to it causes builds to kick off (typical Continuous Integration).

My continuous build jobs in Jenkins:

Jenkins Continuous Integration Build Jobs

I'm making software for multiple platforms (Windows, Linux and OS X). For Windows compilations, I'm using Visual Studio and Microsoft's C++ compiler, on Linux I'm using gcc and on OS X I'm using clang. It's awesome to get that nearly instantaneous feedback that my code is (or is not) compiling on all three major C++ compilers.

But there's more! Single-click build and releases. When it comes to software distribution, manually packaging a release build into an installer is tedious and error-prone. Through a little bit of scripting I've also got Jenkins jobs that build release versions for each platform; packaging them into an installer that is ready for distribution.

The screenshot below shows these jobs for my proof-of-concept "Sine Player" project:

One Click Release Build Jobs

Building any one of these jobs results in a ready-to-distribute installer for the corresponding platform. When the release job is successful, Jenkins automatically copies it to a release folder on the system as shown below:

Darwen Audio Releases

It doesn't end here. There are more things I want to do with this system. I don't yet have any automated testing steps in place other than the UT's that run as part of the build. I'm very interested in adding automated testing steps to the process. I'm also currently contemplating how Docker containers might be useful in this setup.

Date: October 3rd, 2016 at 8:13am
Author: Terence Darwen
Tags: Continuous Integration, Build Server, One Click Release, Cross-Platform Development, Sabbatical

Previous Next