A complete guide to CI: from defining goals and problems to configuring and assessing final results

Post 1 – Why CI?

Before we get down to business, I just want to say that we’ve been planning to write about continuous integration for quite some time. And once we began, we realized that it’d be hardly possible to squeeze this huge chunk of information into a single article. So we figured out it would be a blog post series in three installments covering each and every aspect of the topic including the problem to solve and prerequisites for the practice, competitor analysis and selecting the best fitting system, installation, configuration peculiarities as well as troubles that may occur.

This very post is dedicated to explaining what CI is, what it is needed for and the best (in our opinion) software options.

Overview

It only seems logical to start with describing what on earth CI is. Plainly speaking,

a CI system is software designed for monitoring your source control service (in our case, GitHub) and automatically triggering builds on any updates, running tests or deploying a project to the server. In case of failure, your CI system will send notifications to a person who has committed the latest change as well as to anyone interested.

The thought of running CI has been bouncing around our heads for a while.

It’s very trendy now and I guess if asked, any developer team will tell you they’ve already been continuously integrating for ages.

Have we decided to do that – yes, have we managed to get down to installing the software and configuring it right away – no. It took us time to get ready for CI, implement it in our work approaches and principles, make sure the whole team would accept the new practice.

It’s not enough to just read books or blogs on the topic and simply rush into it. As with every new method, it will work only if it perfectly corresponds to the team’s needs and goals.

Prerequisites for practicing CI

We believe that automating work processes to the max raises our (and I guess any) team’s efficiency. Continuous integration was seen as exactly one of the ways to do it: we thought we’d be able to accomplish much more with less effort.

One of the reasons for implementing CI was our desire to always have reliable, precise data on the source code status in the system. For instance, you can immediately see whether your latest product build has crashed (meaning you’d better not use this version on GitHub) or it is successful and ready for deploying.

Moreover, we wanted to be prepared for a release at any time without worrying about issues missed or still requiring fixing and not being in a rush to finish testing at the very last moment. Consistently running unit tests via a CI server is a solid guarantee that you’ll bypass regression bugs (you know how it happens: you nail a new feature and watch some part of your code get broken) and spares you the trouble of manually checking code.

Another benefit of running tests is help with code refactoring: when your CI server has got it covered, you don’t feel freaked out about accidentally breaking code.

Additionally, we considered tracking code accordance with the coding standards, automatic fixes of minor formatting errors, code coverage and others.

If all the above mentioned things are done with a specialized framework, the team is left with much more time for interesting and challenging tasks and much more loyalty to the job :)

CI tools

When in quest for the best fitting system, we looked through several options but eventually picked TeamCity. I’m by no means saying that this very software is the only best out there. It’s just a matter of personal preferences and project peculiarities. So here are possible CI solutions:

• Jenkins CI
• Travis CI
• phpUnderControl add-on for CruiseControl
• TeamCity
• Bamboo (we didn’t actually examined this one but just in case you want to try)

I’m going to guide you through the first four options on the list for you to get your bearings in the CI universe. Let’s get started.

Jenkins CI

I believe it’s the most popular and widely used open source CI tool forked from Hudson, another well-known CI system, and recognized by virtually any developer. Its community is large and keeps on growing with lots of active users.

Jenkins CI would be a great match for those working on Java projects a lot though it obviously supports other technologies. For instance, you can try out a ready-made PHP template.

Thanks to over 600 plugins, you can easily customize the tool to suit your own needs and requirements.

Why we’ve banned it: it may look like we’re quibbling but the reason for rejecting it is the UI which definitely needs refinements. I know that functionality is key but guys, design really matters.

Travis CI

Travis CI is a hosted continuous integration service. Though we haven’t personally considered using SaaS, we can’t but mention this big name. It’s certainly a star tool, smooth and polished and with very easy setup.

According to the owners, the system allows developers to focus on writing code while building, testing and deploying will be covered.

The tool supports enough languages including Java, PHP, Ruby, Python and others and features GitHub integration. We have been also impressed with how good and clear documentation is. We needed info on headless browsers testing and managed to quickly find it on the Getting Started page right away.

If you have an open source project, you’ll be lucky to use Travis CI for free. Owners of proprietary products will have to spend some money depending on the company specifics (see the Pricing).

Why we’ve banned it: first of all, we think the price is too high compared to what we’ve expected. Secondly, we’re not completely satisfied with the security policy since some clients won’t be happy to share their source code on a third-party server.

phpUnderControl

phpUnderControl is an add-on for CruiseControl, a CI tool and a framework for a continuous build process.

It helps to make your first experience with PHP and CruiseControl as smooth and easy as possible. Besides, phpUnderControl integrates lots of great PHP development tools.

Why we’ve banned it: there is actually no particular reason, we’ve just taken a look at it and felt like it’s not what we’re looking for.

TeamCity, finally

TeamCity by JetBrains, a leading vendor of developer tools, is a CI service supporting lots of technologies including our beloved PHP.

TeamCity is available in both paid and free versions with the latter having a limit on build agents and build configurations. But you can always remove the limit if needed by paying a fee.

The system features over 100 helpful plugins and handy documentation. Moreover, it provides integration with IDE (IntelliJ, Eclipse, Visual Studio).

I can’t pick a single reason that has influenced our decision to stick with TeamCity. It’s rather a combination of characteristics such as the trusted developer company, great design, an opportunity to download without a breach of licence, the features cut out for our needs. We’ve agreed that the product simply belongs with the team.

Hope that now you’ve got a better idea of CI, the ways it works and possible software options. It’ll be just awesome if you manage to find your own go-to tool among the listed ones.

The next post of the series will thoroughly describe the process of getting started with CI. I’ll give every necessary detail for you to avoid annoying issues and save your time. I wish we had had such information when setting up & configuring TeamCity ourselves as it cost us time and some nerves. Now we’ll be glad to share our first-hand experience to prevent you from suffering the same :)

Tell us, do you practice CI? If yes, what is your tool of choice? And if not, would you think about considering it?