Continuous integration and delivery (also known as CI/CD) or simply continuous delivery is a software development process determining how code changes within your products are deployed to production – in essence, how productive and proactive your developer teams are. It’s a topic that’s not discussed all that often in mobile – and we want to change that.
While there is extensive information out there on best practices for implementing continuous delivery for web and backend technologies, mobile is often not part of the discussion. So we want to take the time to cover this topic with mobile in mind. Especially since continuous delivery faces a few restrictions and requires adaptation and thinking to apply well to mobile.
When properly implemented, continuous delivery practices and processes allow your mobile teams to build and deploy products at a much faster rate by improving developer productivity in a number of ways, including:
- Making it quicker to find and identify bugs
- Providing automated and standardised testing
- Supporting a frequent (usually weekly) release cadence
Why continuous delivery matters for scaling organisations
When you have a large mobile team, you’re probably pushing changes dozens of times a day – if not hundreds. As a result, inefficiencies and barriers within your feedback and release cycle can quickly add up to huge amounts of lost time.
One of the main goals of your mobile developer team should be to shorten the feedback cycle as much as possible, making it easier for developers to make changes quickly and making you more responsive as a business.
Why take a continuous approach to releases?
Implementing a weekly or fortnightly release cadence for your mobile app shifts your approach from deadline-driven work to continual iteration.
Instead of ensuring the latest version of your product is ready to ship on a set release date, you’re pushing regular changes to an internal version of your product, testing, and then rolling out to your user base. As a result, your team are no longer striving hard for everything to be perfect for one set release date – and dealing with all the bureaucracy that comes with release management – they’re working to make improvements to features and UX week after week.
What’s more, having a weekly cut-off point forces dev teams to ensure anything they contribute is ready to go to production, eliminating delays to releases when features aren’t yet ready to push.
Of course, there will be times you want to get a crucial feature or update released with a concerted and coordinated marketing push – but if you want to move as quickly as your competitors, you can’t operate all the time.
Automation is key for continuous delivery
If you properly implement automation to manage your continuous delivery processes, you’ll avoid many potential points for human error which can arise along the way.
For example, giving machines dedicated access to be able to publish to the store automatically, or auto-release at the press of a button, means you spread responsibility across your engineering team rather than having a single person responsible for overseeing the process. One of the best things about automation is it means there is no single human point of failure – this makes the process more efficient and less prone to errors.
Ideally, you’ll want every part of your continuous delivery process to be automated. However, in practice, there aren’t currently any off-the-shelf tools that will do everything for you. With some effort though, it’s possible to build the scripts you need to achieve full automation from code to delivery, with no manual input required – we’ve achieved this in some of our teams.
Of course, automation doesn’t mean everything has to happen with zero human input. In fact, we’d recommend that you add confirmation times or block points requiring human confirmation if you have a strict release process or protocol. But just because you have a process that requires human involvement doesn’t mean you shouldn’t invest in automation. Automation means you can change the person responsible faster and share responsibility more easily – it’s a lot harder to do this with manual processes.
Choosing the right release cadence
In mobile development, due to necessary steps such as store validation, it’s just not possible to go faster than a certain release cadence. What’s more, users need to download updates to your app to access features and fixes – think about how annoying it would be for your users if they had to update the app every day.
When it comes to your release cadence, you also need to think about what’s commercially right for your organisation. For example, if you’re a bank and require heavy validation before every release, a weekly release will likely be too much. Or if your app is available in countries where people have restrictive data plans, too many releases will eat into their allowance.
As mobile product engineers, we’ll always have caveats and constraints around continuous delivery, so we need to think about how we adjust and adapt to these in order to shorten feedback cycles, remain responsive and make progress as fast as possible.
Benefits of continuous delivery
One of the key benefits of continuous delivery is that it eases up chaos and removes stress from the developer environment.
Of course, it’s impossible to eliminate all releases outside of your schedule as there will always be situations arising like crashes and bugs which need hotfixes. However, often after a release, it will become apparent that a feature is missing or an element of UX needs tweaking – these aren’t hotfixes, but they are time-sensitive to a certain degree.
If you have a monthly release schedule, and changes like this can’t wait, you’ll end up having to perform exceptional releases which can disrupt working processes and introduce additional overheads. Whereas, if you have a release every week, you can simply raise a ticket, the team can start working on it and it will be ready for next week’s release.
Additionally, continuous delivery enables faster feedback – if you’re building a feature, the earlier it goes to users, the sooner you’ll know whether it works or not and you can make adjustments quickly.
Stages of continuous delivery
Alpha stage
In CI/CD, you would generally start your release with an alpha group – typically an internal deployment channel. Every time something gets built within your CI cycle, it gets published here immediately.
You’ll want to encourage people within your organisation to use this internal version as much as possible – perhaps through incentivisation such as discounts and freebies – so that they can identify bugs needing to be fixed before production.
Don’t just limit your alpha group to your tech or development teams though, it’s a great way of getting everyone in your company involved in using and testing your app to gain as many different perspectives and explore as many use cases as possible.
The great thing about alpha environments is that they can be updated 100 times a day without impacting anyone, allowing your internal team to thoroughly test functionality. The sooner new functionality gets used, the sooner bugs will get found – because you’ll never eliminate bugs by just thinking about them harder.
Beta stage
If, for whatever reason, you have a slower release cadence in your organisation – for example monthly – you may want to have a beta group of users who can use the product before it’s fully validated.
This way, you can release weekly to the beta group and keep your monthly cadence for your main release. If the app doesn’t pass all checks at the beta stage, it doesn’t get deployed to the next release cycle – you might even decide to skip the next week’s release to the beta group to fix the issue.
Incremental release
If you’re releasing weekly updates to a large user base, at the incremental release stage you might start by releasing to 2% of your users. Then, if everything seems to be working you would progress to 5%, then 10%, before releasing it to everyone.
The key thing is to start small. That way, if you have a crash or other bug, you only impact a small percentage of your users and you can stop the release at this point to fix it. Releasing in stages like this limits the risks associated with a faster release cadence by getting easy feedback from an initial small group of users. If you release to 100% of users straight away and introduce a crash, the result could be disastrous for your business.
Assessing continuous delivery success
When you’re assessing the success of your CI/CD process, of course you’ll want to look at user metrics such as error rate, crash rate, session length and any other metrics which are tied to your business KPIs.
You’ll also want to look at internal metrics such as how many times you need to deviate from your normal processes – for example, to perform hotfixes. If you’re having to perform hotfixes too often, this might tell you that you’re letting too many things fall through the cracks and your validation process isn't good enough.
On the other hand, a high number of hotfixes might indicate that people are abusing the process and using it to introduce specific features which aren’t business-critical. In this case, you’d need to look at why people feel they aren’t able to wait and look at whether you’re releasing often enough, or perhaps seeing if there’s a better way of helping your team manage workload and priorities.
Ultimately, metrics shouldn’t be looked at in isolation. Look at your continuous delivery processes holistically and identify trends over time to see how changes to your continuous delivery process have impacted team efficiency, productivity and developer experience as well as business KPIs relating to the performance of your app.
Summary
A well-implemented continuous delivery system should always give you confidence in your release – and confidence in handling situations when things go wrong.
Continuous delivery is a staple of any business that relies on mobile products because it makes your developer teams more efficient, improves the day-to-day experience of your developers, gives you a much faster feedback cycle and avoids unnecessary overheads as a result of unplanned releases.
