Software development can be complicated, especially when things go wrong. Say two developers are working on a project. They are each coding on separate branches of the master code in isolation. Throughout development they’ve tested their code and everything works. When they’ve completed their code they test it again and everything works. Then when it’s all finished, they both integrate their code into the master and… everything breaks.
This is known as ‘integration hell’. At the end of a project, when one branch of the code is pushed back up to the master, things often just break, for no discernible reason. Even if there were no problems during development or testing, when the two branches are added back to the master separately, something goes wrong and the new branches of code don’t get on with each other for whatever reason. Suddenly the developers are left with two choices: revert the changes and start again, or go through the code piece by piece fixing whatever went wrong. Both of these options cost time and money, they put the project over budget and behind schedule so neither is really preferred.
The solution is to integrate early, and integrate often. To continuously integrate, you could say…
What is continuous integration?
Continuous integration (CI) is the practice of frequently updating the master code repository with new or changed code to keep it up to date – any changes to the master code will have been automatically tested by the CI server. If any integration problems are found by the tests, the merge can be stopped before it is completed and the whole thing breaks. Continuous integration testing during the merge avoids last-minute problems and unexpected schedule delays.
The problem with developers continuously integrating their code to the master repository, is that if they’re doing it that continuously then they’re not going to have any time to do any actual coding. That’s where continuous integrations tools come in.
What is a CI server?
A CI server automates the integration, leaving the developer more time to code. These can be set up to integrate every five minutes, every day, or whenever a developer interacts with the CI server.
When a change is committed to the repository (often GitHub) the repository sends a request to the CI server, which runs tests against the master code. If the tests are successful, the CI server commits it to be built, if the tests fail, it alerts the developers that an issue needs fixing.
There are many tools out there that can help developers automate this process, and – as is usually the case in technology – there is no best-of-the-best, one-size-fits-all solution. But two very good options are Jenkins, and Travis CI.
What is Jenkins?
Jenkins is an open source CI server that automates integration. Integration, tests and builds can be triggered any time a code branch is pulled from the master, and also scheduled periodically throughout the project. Jenkins allows for customised builds based on conditions specified by the developer.
Customisation is one of the main benefits of the Jenkins CI server. A wide plugin archive can be configured to change the way Jenkins looks and operates, as well as add new functionality for things like authentication, alerts and credentials. There are also plugins that help run Jenkins in collaboration with Kubernetes and Docker.
Because of its open source model, Jenkins is completely free to download and use on any public or private projects. But, unlike Travis CI, the server isn’t hosted by the company, so it requires the developer to have their own dedicated server to run it on.
One disadvantage of Jenkins for continuous integration is that because it is highly configurable, original, out-of-the-box setup can be quite involved, and it can take a couple of hours to a couple of days to get everything ideally configured, whereas Travis CI comes ready to go.
What is Travis CI?
Travis CI offers a hosted, automated continuous integration option that cuts out the need for a dedicated server. Because the Travis CI server is hosted in the cloud it has the benefit that projects can be tested in different environments, on different machines, running different OSs, by different developers. These tests can be done synchronously on Linux and macOS machines, which speeds up testing. Also, the hosted environment means that the Travis CI community takes care of maintenance and updates of the server, whereas because Jenkins runs on the developers’ own server, any maintenance updates would have to be done by the developers themselves. Although, companies with highly-sensitive projects may feel uncomfortable with sending them off to a third-party service, so many large businesses and government offices prefer the in-house option of running Jenkins on their own server, which they can control usage and prevent access to.
Travis CI comes with support for Docker and a wide range of language, but it doesn’t have the customisation that Jenkins offers, or the archive of plugins. This gives Travis CI less functionality, but it does make it a lot easier to setup and run. Travis CI comes basically ready to use, and setup takes minutes rather than hours/days.
Travis CI is free for open source projects, but the enterprise plan for private projects comes with a cost. However, there is no dedicated server cost – like for Jenkins.
Neither Travis CI nor Jenkins is ‘better’ than the other, but one may be more suited to a particular project. Small, open source projects would be better suited to Travis CI because it’s free to run and quick to set up. Large, enterprise projects are better suited to Jenkins because of the free licensing for private projects and wide range of customisable features. And, if it’s a large project, it’s likely that the developer will already have a server to run Jenkins on anyway, effectively at no extra cost.
Fasthosts provides powerful, reliable dedicated servers perfect for hosting projects of any size. Visit the Fasthosts website for more information on Dedicated Servers.
