Written by Brightec Team
Oct 03, 2014

Why Continuous Integration?

This is the first of a four part series - ‘Evolving the development process’. Part 1 looks at CI (Continuous Integration).

CI vs CD

CI (Continuous Integration) is a development process where code is integrated into the main repositories regularly by developers where it is built and tested automatically.  

It’s a step away from CD (Continuous Deployment), where good code that passes tests is deployed frequently - we deploy to our clients nightly. The system integrates well into an agile culture and fast iterations mean issues are caught quickly. This might seem like overkill for a small development team, but you’d be wrong; it’s actually more of a necessity. We work as a team using limited resources of both developers and time.

Given those two unchanging variables, our project manager has to break a sweat managing the work load to match. CI allows us to make time and ultimately this is what dev tools is all about - taking the laborious unskilled tasks and automating them. This makes developers happy as we can focus on all the creative awesome code stuff and (thankfully for us) it makes our project manager happy as we can accommodate a larger volume of work.

The benefits of CI

It may be you have quite a small build time, don’t worry we all do.  

Creating a clean android build takes 2 minutes and 11 seconds, unit tests take only 17 seconds. Saving 148 seconds isn’t a lot I admit, but there’s more to it than that as CI allows us to:

  • Remove the necessity to email the client a new build (or a link to Testflight/ Play store etc) - If you have no CI usually it’s up to the developers to create a build and email the client or the project manager who then forwards it on.
  • There is no need to manually upload a build to your current distribution tool - Testflight / Play store
  • Automated build notes - there’s no confusion as to what is included in the build
  • Clarification emails are kept to a minimum - questions such as; whether this is the latest build, what kind of build is this, what version, what’s included etc are no longer necessary as all that information is automatically provided
  • Down time is minimised - As the team expands, it’s inevitable that with increasing frequency the build will get broken. This can be a huge time waster. If we can inform the guilty parties ASAP everyone can get back to work quickly.
  • Increased stability - Running automated tests like Monkey will find difficult to replicate bugs quickly and provide useful debugging information. Incorporating unit tests as part of the build processes forces new code not to break existing tests.  This encourages a testing culture as unit tests are always kept up to date.
  • Developers can develop. Duh. It may seem obvious but automation reduces interruptions and context switches.

Letting developers develop

I think that last point is one of the strongest reasons to deploy CI.

"Researchers have found that interruptions during a task that requires a high level of concentration may cost up to 15 minutes until the same level of productivity and concentration compared to before the interruption can be achieved”

The more we can automate unnecessary interruptions, the more we gain in terms of development and focus. Automation allows us to give clients and project managers the tools and information they need.  Find out more about the dangers of context switching here.

"Researchers have found that interruptions during a task that requires a high level of concentration may cost up to 15 minutes until the same level of productivity and concentration compared to before the interruption can be achieved"

We develop with Jenkins

We set up our CI system using Jenkins - a pretty ubiquitous tool which has tons of support. I’ve never worked anywhere that didn’t use Jenkins. We’ve started simple with a few builds, but you may find you need more.

The android builds represent our two main branches: Dev which is “unstable” work in progress and Release which is a stable build intended for an imminent release. Both builds are scheduled nightly and are emailed to our client and testers along which an indication of version.

We maintain very close relationships with our clients and so are happy to send out nightly builds. If this is not the case you may wish to set up a manual “deploy” which ships off at the end of a sprint for example. There are some great plugins available for Jenkins. Here are some we’ve used:

This article was originally written for Brightec by Seren Matthews

Next Post

Code Style expectations