Continuous Integration (CI) is an essential part to any modern development process. Gone are the days of monolithic releases with massive changes, today it’s all about releasing fast and often. Most teams have come to rely on some sort of automated CI system. In this article we are going to talk about some of the benefits of CI and how it fits into small, medium and large projects followed by a quick overview of three different hosted CI services and how they apply to projects of various sizes.
Wikipedia defines Continuous Integration as
… the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day.
Continuous Integration is very frequently accompanied by Continuous Delivery/Deployment (CD) and very often when people talk about CI they refer to both.
CI relies on two main principles:
- Changes are merged to main source branch as often reasonably possible. The tasks are explicitly split up in such a way so that to avoid creating gigantic change sets.
- Each change is fully tested. Automated testing is the cornerstone of CI. In a team environment, and even on a personal project, it’s nearly impossible to insure that latest changes don’t break existing code without tests. Every time a change set is merged to master, CI runs entire suite to guarantee nothing was impacted negatively.
Open Source Projects
If you have an open source project, whenever it’s a tiny NPM module or a large application, if it’s publicly hosted on GitHub or BitBucket and has automated tests, you can take advantage of CI right away. You will immediately see some benefits:
- Each time you push new changes, CI will pull your latests code, build, configure and run your tests in a clean environment. This means that if you forgot to commit a required library for example and the tests pass locally, they will fail on CI letting you know about the omission.
- At a minimum you could show your users on the README page that you have a passing build. At best, if you have hooked up a Code Coverage tool you could show how much of the code is exercised by the automated test.
The configuration for CI in such projects is generally boils down to installing dependencies and running the tests. Any self-respecting hosted CI provider can handle this type of projects and given that majority of open source libraries are maintained by a sole developer, the builds for such projects don’t need to be happening very often nor they are very complicated.
In an effort to support and give back to open source, some CI providers offer free plans for open source projects. So if you have been working on one and don’t yet have CI hooked up, I recommend doing that right after finishing the article. You might have seen these badges around GitHub. After setting up your project with a CI provider, you can then add a badge to the
README file via shields.io to proudly show of your passing build.