How We Have Automated Mobile Apps Submission to Stores

Why is a small time-to-market figure a competitive advantage for a company that develops its own products? It's simple: the faster you deliver updates to users, the faster you get feedback, the faster you can fix bugs, test features and refine them. The customers on their end manage the product better if they get results from the team quickly. They can also make adjustments quickly, with the flexibility to fully manage the final product.

In complex processes that bring together analysts, designers, developers, QA engineers, optimizing each step makes a significant contribution to the final result. So, when we started to develop our mobile app development business. We started looking for opportunities to automate every step as much as possible to save people from manual work and to secure against mistakes.

Below is a description of what that journey looked like, what results we came up with and what benefits we achieved.

Step 1: automation

At the start more than 10 years ago, developers were building versions manually, testers would come to them to get builds, connect a smartphone to a computer, download the build for themselves, and so on. The process was not very fast and, most importantly, it was hindered by the human factor as the testers had to ping the team, and the developers were distracted from their tasks in order to hand over the product to them.

We started by implementing automation through Jenkins. Teams were given sets of scripts to prepare builds and submit them to our own App Store. On this site, each project automatically had a page where the latest version of the app was published. From here, testers would take the release for review.

This is the first step that separated the development and testing processes: we no longer had to physically connect the phone to the computer. We even made QR code generation so that people don't have to type in addresses and tap the links on their smartphone screen with their fingers, just point their camera at the computer screen, scan the code, and get an application.

It was already very convenient, but there was one problem as the service supported only one version. If it was necessary to bring up a previous version to test an update, difficulties began to arise. And when our applications grew to thousands of users, it became necessary to have several retrospective versions of the application at hand. The point is that users don't update their software in an orderly fashion, and if older versions start to fail, we need to be able to reproduce the problem.

Step 2: version control

At that time, several products for managing application versions appeared. We researched the market and chose the Beta service. It allowed adding groups of users (developers, testers), assigning different rights to them, configuring what notifications will be received by certain users. Most importantly, we were able to upload and manage version chains.

We determined what versions we need and how we should work with the environments. Some things we found out by trial and error, for example, how many debug-versions we need for a particular environment, so that we do not get confused and quickly identify the sources of problems in applications. We started with our own debug-versions for each environment and eventually came to one version, switching between environments through a separate screen, if necessary.

A few years later, we switched to the App Distribution service, which runs on the Firebase platform. This solution is now used by our mobile teams. In Firebase, the application usually has three versions: (1) dev - the environment is deployed to us, (2) stage - where the customer accepts the work, (3) release build, which is automatically deployed to the published app version.

App Distribution allows you to download the build and automatically send notifications to responsible employees. Those in charge, like testers and developers, can connect right away, and if their smartphone is connected to our infrastructure, they get the update on their device right away.

At the same time, the toolkit for automating builds and publishing evolved. The next milestone was the transition from Jenkins. For a while, we experimented with Gitlab CI/CD, but eventually the company management has decided to move to Azure DevOps (TFS).

Step 3: TFS pipelines

We now have a set of events in our processes that automatically run the pipelining in TFS to perform certain tasks. For example, after merge, the source is pumped out to the developer branch, build takes place, artifacts are sent to Firebase, and a version card is automatically created.

TFS prepares automatic builds with a description of what was done for each build. As we have already told earlier, release notes are automatically pulled from the performed tasks. The tester can immediately see which build is up to date and what has changed in it and can download it and test it.

This eliminates possible delays due to the fact that someone has downloaded something wrong, signed something incorrectly, causing a confusion that will ultimately interfere with the release.

Result: fast and transparent CI/CD processes

It saves the tester’s time to get the build, so they don't have to bother the team to get a version delivered. All participants in the process know at any given time what they need, as TFS tags automatically change the status of the build, and all changes can be conveniently tracked. In fact, when each participant has finished their section, they can forget about the task; automation further controls the process.

Now we have developed an approach to building versions for all possible environments. The processes are debugged and automated. The next big goal is the transition to TBD. We still have to figure it out. For example, there are questions about how to test code if it is constantly filled in the wizard, how to work with hotfixes...

We are now practicing these approaches on one of the largest projects, where TBD is being built from the very beginning. In a few months, the product will be delivered, and by that time we will have a complete picture of the processes. We will share our experience.