This blog will focus on the why’s (and a cursory bit of how’s) of using a continuous integration system in robotics. What is continuous integration? Well, it encompasses a general set of principles and the idea that you can have automated builds and tests on your code base running behind the scenes. When I first began my career in robotics, this wasn’t even something on the radar anywhere I went. Much of the robotics community is very much an offshoot of the university research community, and many projects are worked on by a single person as a one-off prototype with very tight deadlines. This naturally can lead to a lack of rigorous software engineering principles during development. One of those is the idea of an automated build server. I will address that issue in this blog. Deadlines and projects come and go (sometimes very quickly), but the time saved by setting up a build server is magnified over every project and employee using it.
At Neya, we have set up a build server using Jenkins (http://jenkins-ci.org/). Easily installable through apt on a Linux box or a basic download/install process, Jenkins has straightforward setup instructions. The base platform will allow you to automate builds running on the machine it was installed on. I recommend creating a simple hello world project using your company standard build system (cmake, ros, visual studio, etc) and using that as a setup to test the build server. Preferably something that compiles relatively quickly. Using an existing project with a multiple-minute compile time will greatly increase your down time while doing the basic setup.
Using the basic setup with just a build script doesn’t seem at first glance to be all that particularly useful. You’d have to have a separate build machine for every platform type, and you have to go to your build server page and click to start a build, or put it on a simple automated schedule. That doesn’t really get you what you want. Fortunately, Jenkins also allows plug-in development, and while you can always make a plug-in for your particular build system, there are already quite a few plug-ins developed for the more common ones. For instance, if you use cmake, there is a plug-in for cmake builds that correctly automates the cmake/make process for you. If you use subversion or git, there are plug-ins to link your projects to those servers. You can then set up your projects to automatically build any time someone does a check-in. Don’t want to go to the build server page to check your build status? Well, there is a plug-in that will allow you to set up email lists for whenever the build status changes.
Finally, and most importantly, there are plug-ins to integrate the build server to various types of virtual machine systems, including both virtualbox and vmware. Setting these up allows your build server to compile the software for multiple platforms simultaneously. I’ve found this to be one of the most useful tolls available on a build server (beyond automated testing, which I will hit on in my next blog). Writing software that can run on multiple architectures is not that hard, but maintaining it through months of development and different developers is. A simple automated process that tells a developer that they broke the windows build with a change they made that worked on their Linux system can save hours and hours of headaches with developers and even customers later on down the road.
While sometimes it may seem to be superfluous and time consuming to set up, I can attest that setting up and managing a basic build management system is not only easy to do, but saves way more time in the long run that it takes to set up. You will have a project that is being developed for deployment to multiple different architectures. The first time someone makes a change they think works because it compiled on their machine and the build server blasts out an email saying it failed on the other 3 architectures is a thing of beauty. You will have not only saved time, but you may have not found out that bug for weeks. Whenever someone forgets to add a new file to the repository, you find out immediately, instead of a month later when you give a new employee repository access and they try to do an install. Have a bug fix on something you sent out 3 months ago that your customer finally got around to testing? Well, now you can have the build server automatically tee a new release up on command, instead of having to make sure you’ve still got that setup correctly for a project you haven’t compiled in months. It is clearly worth the day or two of initial setup and day or two a month of maintenance required. Now, making sure the engineers who have deadlines use it for their projects is another story entirely!