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.
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:
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.
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
Search over 300 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!