Every software company sooner or later starts to deliver its software periodically. Mobile applications are not an exception. Mobile development teams try to keep up with innovations, new trends and design ideas. As a result, the delivery cycle becomes more frequent. Some teams deliver once a month, some once a week and others deliver on a daily basis. Engineers responsible for software delivery should “follow the delivery process” strictly, otherwise, things could fall apart. Tests might fail or not run at all, beta versions might not get distributed, version control commits could be forgotten, etc…
Luckily, it all can be easily avoided by automating the release process and making it easier to follow without actually doing anything. In this article,we are going to talk about delivery process automation at Home24 and its benefits.
The delivery process in every company might vary depending on the software that should be delivered and the purpose of delivery. Some use automated tests, some use manual tests some deliver beta versions for a group of testers and some do all of the above (believe it or not, but some don’t test their software at all). It is important to describe delivery scope at Home24 first before we describe its automation.
Let’s start with the Home24 mobile application deliverables.
We have 2 flavours of the app. One is a production build, it targets real servers that serve real clients. The other is a so-called “staging” build. We use it to target a “non-production” environment, to test new features or, simply, to integrate changes. “Non-production” means that real users will never be affected by changing things in the “staging” environment.
Our goals are to deliver builds for:
- The production environment
- The staging environment
Both of those builds will be tested via automated tests. Newly integrated features for the staging build will be partially tested, manually, by a QA team. Production builds will always be tested both automatically and manually, they will also be distributed to a closed beta testers group. After a period of one week, enough feedback is collected from the beta testing group and the build can be promoted to release candidate. While production builds are not as frequent, staging builds occur several times a week.
After we have an understanding of our delivery scope we can separate the delivery process into 2 tasks:
- Staging release delivery
- Production release delivery
If we would follow the delivery process manually (which we actually did for quite a while), we would do the following:
- Prepare the correct build that targets the environment we need (staging/production)
- Run automated tests
- Distribute the build among beta testers and QAs
- Release the build to our clients
Of course in reality that is a more complex, multi-staged process as shown in the diagram.
It is worth mentioning that such process can be error-prone when executed manually. Engineers that follow those steps manually can often overlook something. Since we release pretty often, we don’t want to do the same repetitive task over and over again. We asked ourselves if we can do the release just by pressing a button? The answer was YES WE CAN! And so we did…
Scripting our way through the release process </>
We have chosen our services and tools carefully so that there will be a way to trigger them remotely through a console or, in other words, automate them through a script.
We’ve written a small program in Java that initiates all necessary steps in our delivery process, but it doesn’t really matter what scripting language you choose.
Nowadays we do only 2 things manually in our release process:
- We write release notes
- We press the “Release” button
And that is it!
But release process is not over yet… Before our app hits the broad audience, there is still work to do…
When we are ready to release our mobile application to our clients, we don’t rush in head first but rather do it gradually through a process called “Canary release”.
“Canary release” or a “Progressive rollout“ is a common practice in the software world that basically means that a product will be released to a small audience first. It allows us to monitor the software behaviour while we are slowly increasing the audience percentage. The more users we get through canary release, the more potential bugs we might discover and fix before we release to all 100% of our clients. That leads us to another very important part of our continuous delivery. Monitoring.
After we have tested our software manually and automatically through unit tests, and have given it to our beta testers, we might think we’ve covered all the corners and there is nothing that can possibly go wrong. But in reality, the risk of potential problems is higher than we think, once the app is out there and running on million devices. We still need to constantly monitor live application status to make sure everything is functioning as expected.
In the Home24 mobile team we use a great online service called Apptelligent. It allows us to monitor crashes almost in real-time, along with other predefined criteria for user behaviour.
Another benefit of Apptelligent is that it allows us to communicate with it through an API, that helps us to integrate our delivery process according to the current live status of our mobile applications. For example, we can stop our Canary Release process if the crash rate is too high and we can see all important KPIs on our dashboard that are related to the current status of our apps.
CI server makes things easier
CI server is often used to manage building and delivery processes. In our case, we use Circle CI as our CI server. Among other things, it constantly monitors for updates in a Master branch of our mobile applications GitHub repository and when it sees one, it triggers the delivery process automatically. After the process is finished it notifies us by email (and this is how we know that the coffee break is over).
Thanks to tools and technology, we are successfully streamlined and have fully automated the delivery process for our mobile applications, which is now hassle-free and far less error-prone. Some might say that it takes quite a lot of time to create all the scripts and connect all the dots together. That would be a fair statement, but it all pays off eventually. The automated delivery process gives us security during our releases and saves us a precious time that we could use for other important tasks (like playing ping pong 🙂 ).