We Are Mobile First
DevOps refers to the practice of unifying software development with software operations and, in this series, I’ll look to explain how we utilise its characteristics to develop and deploy software with maximum efficiency and minimal interruptions.
Here at We Are Mobile First, we put a strong emphasis on the importance of peer-reviewed work. During the development process, code can be ever-changing and by employing good practices we are able to efficiently process code and ensure it’s free of mistakes.
Our code reviews are done in the form of a pull request, as we use GitFlow, so each new feature and bugfix is assessed by multiple members of the team. Whilst these checks may take some time initially, in the long-term they prevent us from having to inefficiently refactor code much further down the line.
As part of our process to ensure that we are creating high quality software, we use continuous integration and continuous delivery.
Continuous integration emphasises the importance of automated testing to check that the application is functional whenever new commits are integrated to the main branch, whereas continuous delivery is an extension of this that also automates the release process, so that you can deploy your application at any time with the click of a mouse.
We use both to automate the building, testing and delivery of our digital products. This automation allows us to catch problems promptly, enhances collaboration, broadens our test coverage and allows us to generate statistics over time.
You may have also heard of the term ‘continuous deployment’. This goes one step further in the automation process meaning that all deployment is automated and every change, that passes all stages of testing, is released to customers without the need for human intervention.
As you can see, automation can really make your life easier when it comes to reducing time spent on manual testing.
We wanted to automate more of our procedures in order to maximise efficiency.
In particular, we wanted to tie each feature to a particular build so we could track and control delivery, as well as automate both our internal deployment (to quality assurance) and our test running.
As we develop new features, we ensure that they are each first developer tested, either via an automated test or through manual testing. We also ensure that these features pass quality assurance testing, either by running unit tests, regression tests, an integration test, or a combination of the three.
In this particular instance, we decided to self-host the CI server, contrary to what we have tried in the past, as we wanted to have more control over the end product.
Fastlane has evolved a lot since last year so we decided to self-host using Jenkins in a Mac Mini using Fastlane as a build tool.
Fastlane, an open-source suite developed by Felix Krause, features tools that can do everything from generating snapshots, to deploying to the store, and Jenkins is an open-source continuous integration server, written in Java, with the advantage of having over 400 plugins that make it customisable to your needs.
Our goal was to have Jenkins periodically ping our remote repository of code to check if there was an open pull request. As soon as there’s a new pull request, or changes are pushed to the remote repository, Jenkins will download it and Fastlane will take care of building, writing and deploying the changelog. In the next post in this series, I’ll explain how to set up both Fastlane and Jenkins in a Mac Mini.
By developing and deploying the correct automated configuration, we are able to work more efficiently to create functional builds, meaning we can focus more of our energy on building great software and less on the repetition of monotonous tasks!
https://en.wikipedia.org/wiki/DevOps
https://www.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd
(Hero image credit: Igor Sun via Unsplash)