Back in December 2018, our very own DevOps Engineer Tim explained to us exactly what is meant by the term DevOps. Today, he’s taking over the blog once again to tell us all about continuous integration.
Without further ado, we’ll hand over to Tim to explain.
These days, agile software development techniques allow new innovations to be implemented, tested, reviewed and deployed in timescales that were unthinkable ten years ago. This allows businesses to be highly adaptive to evolving customer needs. In turn, this increases customer satisfaction and reduces churn.
As outlined in my previous post, DevOps is at the heart of making this happen, using a collection of techniques and tools collectively referred to as the DevOps toolchain. (Illustrated in the flow diagram below).
Continuous Integration (CI) relies on developers regularly committing software (source code, configuration files etc.) to a central repository. Here it can be automatically built, tested and deployed.
If you are reading this post, the chances are you’re already using Git or have at least heard of it. Git has rapidly become the de facto way of tracking and managing changes to software. While this isn’t meant to be a tutorial on using Git, fundamentally the workflow is as illustrated in the diagram below.
In order to implement a change, for example to add a new feature, you can clone or check out the appropriate Git repository (repo) and create a new branch of the software. You can then work on this branch in complete isolation from the master branch from which it is derived.
As you work on the software, every time some part of the new development is done you commit your changes to the Git repository. This essentially saves a snapshot of the branch at that instant. This is important as it allows you to subsequently rollback to a previously saved version in the event that you accidentally break something. Once you’re happy that it is appropriate, usually when part of the development has been completed and committed, you push the changes to a central, upstream server.
Once the changes you’ve made have been successfully tested, you can request that the branch you’ve been working on is merged back into the master branch.
The CI approach means that every time software is committed, it can be built, unit tested and deployed to a test environment if required. On complex projects, the savings in time, frustration and errors are huge.
There are various continuous integration tools available to support this way of working. Not only do they support the usual business of committing and pushing changes, they also support all the other aspects of the development lifecycle.
Software build environments can even be containerised. For example, to build one of the projects I am currently working on, our DevOps build server simply spawns a Docker container with the appropriate tools on it.
When combined with a CI tool’s continuous deployment (CD) capabilities – which allows the seamless deployment of software, and rapid turnaround of new features and bugfixes – this significantly decreases a new innovation’s time to market and increases customer satisfaction.
Want to know more about DevOps? Check out our other DevOps blogs and keep an eye out for the next post in the series.