CI-as-a-service: the next step in the evolution of Continuous Integration?

Jul 25, 2017

If you work in software development, and haven’t been living under a very large rock for the last decade, then you’re probably familiar with CI. CI (Continuous Integrations & Continuous Deployment) is the process of automating the more laborious tasks of development such as testing, building and deploying.

Committing code to a shared repository and running integration tests early and often is now a hallmark of agile development and essential to rapidly delivering cohesive software.

The technology and tools are still relatively new, but the practice is already evolving with a new wave of advanced tools with features designed specifically for mobile. Hence, the mobile development team here at Resilient have fully embraced the philosophy and the latest tools as part of their everyday work.

Why use CI/CD?

The later an issue is identified in the process, the more expensive it is to fix.  Using CI our tests are running constantly right from the very start, meaning bugs are found as soon as possible and can then be fixed at the lowest level of cost.  Cheaper bug fixes means more bug fixes and less bugs in the final product and therefore a higher quality of software being used by the end user.

Also, CI frees up time spent on repetitive manual tasks or puzzling over what went wrong in a build. This results in developers having more confidence in their code and are more likely to innovate and try new things without being afraid to break something.

Lastly, it lends itself to cohesive collaboration, and it removes the dependency on a certain people to conduct certain activities e.g. Steve might be the guy who builds the app. If Steve’s away and no-one knows his passwords, the app doesn’t get built! With CI this would never happen. The latest code base always has a build ready and the tools to build are held in a central location, ready for action 24/7 at the click of a “build” button.

How has CI/CD changed?

Most people think of Jenkins when they think of CI, and it’s been the go-to tool for many years. The problem with Jenkins (as a first/second generation CI tool) is that creating and maintaining large numbers of jobs at one time can be very time-consuming.

Jenkins is a powerful tool that has given us a wealth of valuable lessons about the automation process. But as CI technologies are growing out of their infancy, and the new age of DevOps is now a staple of any modern software development environment, we’ve found it’s time for us to thank Jenkins for his loyal service and move on.

So we’ve decided to go with the current trend of moving from hosting our own CI servers to using remote services. This approach reduces admin burden and maintenance overhead, so we spend less time and energy maintaining servers and more time being productive and cool.

CI as a service?

There is a glut of new cloud-hosted CI services available – Travis, Circle CI and Codeship are a few of the favourites. Circle CI is a top quality service, our first choice. However, we found offered some very appealing features especially for mobile. We also found that the Bitrise support was superb, their team was extremely responsive and friendly both on their Slack team and also their support forum.  Plus, BitRise is open source and has a GUI style workflow making it a lot easier to use than purely YAML-driven tools like CircleCI and Travis. The icing on the cake is the ability to install the entire tool locally enabling us to diagnose bugs and fine tune workflows with more control.

How does CI work at Resilient?

CI is flexible and can be applied in many different ways depending on how your project or your team (or both) are organised. For example, here at the Resilient offices our developers are organised into two teams, each with its own development environment (we call them Spitfire and Hurricane).

Our mobile devs live in the Spitfire team committing code early and often – of course. The tests run on every commit (or ‘push’) to the remote repository.  When the tests have passed and the feature is ‘finished’, it’s time for the code review. Once the code is reviewed and ready for QA, the feature is then merged into the main code base/branch.

Merging into the main branch triggers automated ‘deployment’ of the app where test versions are built and delivered to the Spitfire team’s QA staff. Once that version has passed QA the code is merged into a “production” branch which in turn triggers the automated deployment to the Appstore and Google Play store.

All of this activity is documented or communicated in the company’s favourite corporate chat client-Slack, so anyone who wants the latest progress updates can simply join the relevant channel on Slack to see who’s committing what changes, testing what build and which features are in progress.