Continuous Integration: Let the Robots Have Your Back
Continuous integration is a bit of a buzzword, but it could be a very important part of your workflow. The idea behind this is the development team pushes their code into a shared repository frequently that has an automated process to verify and perform a build of the site. While it won’t prevent you from committing bugs, it will likely help your team squash them sooner and it will get your team thinking about the impact of each change in a much more significant way.
What is Continuous Integration?
The need for continuous integration comes first from the idea that teams will have to integrate their work at some point. Whether that is simply integrating it into the current state of production or with one another, it will still have to be done and it shouldn’t result in a broken site when it gets there. Working siloed off for long stretches can be a developer’s default mode at times and this can lead to trouble. That task you’ve been working on in that separate branch seems to merge fine with the rest of the team’s work, but when it gets pushed to a production server, nothing works. This is why the philosophy of continuous integration (CI) is so important in teams.
CI doesn’t prevent someone from committing broken code and it doesn’t replace developers testing their own work, but it does change the psychology of when and what is pushed. Knowing that code pushed to this shared repository causes a system to run tests and check that the build of the site, (or application or whichever project really), is still working as expected will cause developers to take a moment to confirm that the work they are doing meshes well with everyone else. Most CI tools have notification systems that can be set up so that the team is notified when a build fails and that can be useful for getting attention to only committing vetted work.
Continuous Integration Tools
A common misconception is that CI tools like CircleCI and TravisCI can run and build your site with no effort on your part. You can certainly get to a point where your team can just reap the benefits of these tools, but that takes a good chunk of time to get to. That isn’t to discourage you from getting to use this great tech, but a good dose of reality is good when you are working with new stuff.
Tools like CircleCI can be set up with a configuration file and some settings through the web interface so that you can have the container it builds be very similar to the production environment you are going to launch the code on. This makes testing more accurate and lowers the chance of false alarms. For the most part, the documentation on these tools are very good and should get you most of the way to where you want to be. We’ve had good luck with CI tools improving our ability to spin up testable environments and catch issues long before they could ever get out to a production server. There is one thing that you should remember with all of this, however, you have to write your own tests.
That is usually the biggest hang up for teams looking to get involved in Continuous Integration. You have to pair it with some sort of automated testing. Whether that is unit, regression, or browser testing, something needs to confirm the build or you just have a repository with merged code. We’ve talked a bit about some easy to setup headless testing that you could use to get started with these tools and I think it’s a great place to start. You’ll want more than that at some point, but you have to start somewhere.