4 min read

As time moves forward, the development of software is becoming more and more geographically and temporally fragmented. This is due to the globalized world in which we now live, and the emergence of many tools and techniques allowing many types of work, including software development, to be decentralized. As with any powerful tool, software development tools that facilitate the sharing of code by multiple developers simultaneously need to be managed appropriately or the results can be quite negative. Continuous integration is one strategy for managing large software codebases through the development process.

Continuous integration is really quite simple on the surface. In order to reduce extra work that accompanies a branch and the mainline of code becoming non-integrable, continuous integration advocates for, well, continuous integration. The basic tenets of continuous integration are fairly well known, but they are worth explicitly mentioning. Projects need to have a code repository; if this isn’t a given in any of your development processes it needs to be. Automating the build of projects can also increase the efficacy of continuous integration. Part of an automated build should also include self-testing in a production level environment. Testing should be performed using the most up-to-date build of a project to ensure the tests are being performed on the correct codebase. All developers need to commit their changes at the absolute least once every working day. These could be considered the basic requirements for a development process that is continuously integrated.

While this blog could focus on one specific continuous integration tool, I think an overview of a few tools to get someone started in the right direction is better. This Wikipedia page compares some different continuous integration softwares available. These softwares are available under both proprietary and open licenses.

A really great starting tool to learn would be Buildbot. There a few reasons to like this tool. First of all, it’s very much open source and completely free. Also, it uses Python as its configuration and control language. Python is an all around good language, and lends itself very well to configuration of other software. Buildbot is a full-fledged continuous integration tool, supporting automated builds and testing and a variety of change notification tools. This all ships as a Python package, meaning its installation and use does not tax resources very much. The tutorial on the Buildbot website will get you up and running and their manual is incredibly detailed. Buildbot is an excellent starting point for someone who is attempting to bring continuous integration into their development process, or someone interested in expanding their skillset. Not everyone is a lover of Python, but many people are lovers of Node.js.

For the Node.js aficionado, another continuous integration open-source solution is NCI. NCI, short for Node.js Continuous Integration, is a tool written in and used by Node.js. The JavaScript base for Node is a powerful attraction for many people, especially beginners, who have the most experience coding with JavaScript. Using Node.js does introduce the requirement of having Node.js, which can be onerous, but Node is worth installing if you don’t have it already. If you use Node already, NCI can be installed using npm, because it is a Node package. A basic start-up tutorial for NCI is located here. The documentation is not as clear, or as large as that of Buildbot. This is in part because NCI is part of Node, so many of its plugins and dependencies have separate documentations. NCI is also a bit less powerful than Buildbot when it ships. One of the benefits of NCI is its modularity. Servers can be large and complex or small and simple; it just depends on what the user wants.

To end on somewhat of a side-note, some continuous integration tools may be simply too powerful and complex for a given developers needs. I myself work with one other developer on certain projects. These projects tend to be small and the utility of a full-fledged continuous integration solution is really less than the cost or hassle. One example of powerful collaboration software that has many continuous integration elements is GitLab. GitLab could definitely effectively perform as a full-fledged continuous integration solution. The community version of GitLab would be better suited as simply a collaboration tool for smaller projects.

Author:

Erik Kappelman is a transportation modeler for the Montana Department of Transportation. He is also the CEO of Duplovici, a technology consulting and web design company.

Erik Kappelman wears many hats including blogger, developer, data consultant, economist, and transportation planner. He lives in Helena, Montana and works for the Department of Transportation as a transportation demand modeler.

LEAVE A REPLY

Please enter your comment!
Please enter your name here