CI/CD for mobile development has never been more important. Mobile apps have been on the bleeding edge of technology pretty much since their arrival. Trying to test them has been its own unique challenge, in large part because of the changing environment that is the mobile development realm.
For a long time, it was also essentially the modern-day Wild West, not only because mobile devices made users incredibly vulnerable to hackers, but also because—given the way apps were tested and the lack of testing standards—it was just as likely that the apps themselves could be a significant problem.
Fortunately, by and large, things have calmed down, security is taken more seriously, and testing is a lot more rigorous than a decade ago. Today’s primary drive is to deliver changes increasingly faster. This is trend, which mostly started with mobile apps, has spread to other types of software, such as game development.
One of the most common ways that mobile app developers try to speed up testing is through continuous integration and continuous delivery, collectively referred to as CI/CD. While not perfect, CI/CD is exceptionally popular and allows for considerably faster app releases than those of a decade ago (and, when correctly performed, without app-breaking bugs).
In this article, we take a quick look at the process, benefits, and downsides of CI/CD for mobile app development.
What is CI/CD?
At its core, the use of CI/CD requires maximizing the use of automation to complete testing of new code so that it can be released more quickly. As some companies have continued to push for faster and faster while at the same time cutting corners (namely by not shifting left), we’ve seen some high-profile releases with major problems, sometimes problems so big that it broke the mobile app being updated.
Until fairly recently, developers saw defects as something that were inevitable, but as they issues subsequently grew larger and more high-profile, a lot of app developers have come to understand how dire the results of a poor release can be, with the potential to negatively impact a company for years after. With the threat that they would lose their users if they didn’t shape up, developers—especially QA testers—were expected to complete testing with minimal disruption to tight release schedules.
Accepting that code needed to be tested before release, and that timelines for development and testing really weren’t going to change, developers began working within a framework that required continuous deliverables. The obvious way to do this was through continuously integrated completed code for testing.
Note that, although they’re related, there’s a big difference between continuously integrating code and continuously delivering it. For example, it’s likely that teams work on multiple elements and new functions simultaneously. Multiple elements or functions may be integrated overtime, followed by the delivery of a group of changes.
Confused? Don’t worry, it’s more simple than it may initially sound. Let’s go ahead and break down those two parts a little more.
What is Continuous Integration (CI)?
Most contemporary developers work in the habit of regularly checking their code back into the main branch. Before doing that, they’re wise to run their code through a CI tool that will review it to make sure that the code doesn’t include defects or problems that could cause significant problems on the branch.
When this is required prior to any code check-in, the process provides a level of code review that ensures developers aren’t creating more problems than they fix during the check-in. The process also provides the developers immediate feedback about their code.
It can also provide a reminder to address something that a developer forgot about, giving them a crucial chance to fix it. Developers may also find that they’re checking in code that contradicts with something in the branch. We all know that rushing is a part of the process, and it isn’t entirely uncommon that developers don’t always start with the right code.
The CI Process
Wise developers aim to avoid checking in code with defects. They also want to avoid checking in old code with their new code.
The best CI tools give developers and development managers an automated way of verifying the quality of code before it goes into the main branch. The result is better quality code ready for delivery and more developer collaboration.
The CI process is pretty straightforward:
- First, it compiles the current code on the branch along with the new code to be checked into the branch. It pulls in applicable libraries and dependencies to check the full build.
- Next, the tool checks and tests the code, including standard unit and integration tests, static analysis, and defect checks. This verifies that the code will not break the build, ensuring that checking in the code doesn’t break the app if it is checked into the branch.
The benefits of verifying the code before it actually hits the branch are obvious, especially when you consider how frequent deliveries occur.
What is Continuous Delivery (CD)?
The other half of the CI/CD process focuses on the regular delivery of updates to the app. The CI process sets up the code, making sure there’s nothing app-breaking find its way into the branch. Then the CD process begins additional tests and reviews to prepare the new code in testing environments for release in the near future.
The primary checks in CD take a holistic approach to managing the code, analyzing its performance, acceptance, security, and other tests required before code is released into a production environment. It requires an environment that is close to the production environment so that the testing is as accurate as possible.
Once the tests complete, the team can deliver the release based on their release schedule. Since they’ve tested all critical aspects, moving it into the production environment can be done with considerably greater confidence (though it is important to run the tests on the production environment too—the more frequent and intelligent the testing, the less lower the likelihood of disaster).
The CD process
The CD process is also pretty straightforward, but it’s more time-consuming since than the CI process because it’s often the last set of checks prior to delivering the code to production. Here are the typical steps:
- The current code is pulled from the main branch to complete a build.
- The target release environment is configured in the staging area, then the new build is pushed to it.
- All of the standard checks and tests are run, with QA engineers often taking over at this point. They ideally run many automated tests, as well as any required manual verification, prior to the release.
- A second build is created and tested from the main branch. This new build is then either used to create an artifact for production or it is used to prepare the move from staging to production.
It’s worth mentioning that there are some variations to this process because there are numerous ways of releasing new code and every company seems to have its own development process. Whatever the case, at the end of this process, all of the newly checked in code will be released in the app for users to access.
- Remember: Without exception, you save you and your team a lot of trouble by finding significant problems before your users start to report them.
Considering CI/CD for mobile app development
Given how today’s app release expectations, most modern mobile app development teams find themselves locked into an environment where automating as much as possible allows for what used to be considered impossible delivery times. That said, CI/CD is far from a perfect method of testing and preparing code. Consider the pros and cons:
Pros
The benefits of CI/CD are numerous:
Cut down on costly defects
Perhaps the greatest of these benefits is that you and your team can significantly cut down on costly defects before they hit production. This gives your team a chance to fix things before anyone knows that there’s a problem. It is also much easier to fix code before it reaches the main branch—and it is exponentially easier to fix code before it reaches production. Once you release code to production, you have a lot more red tape (often in the form of app store policies) and in turn getting fixes through the production environment pipeline can take a lot longer.
Instant rollbacks
With CI/CD, your team benefits from instant rollbacks in states that are close to deployment—should you encounter significant problems before you deploy it. Being able to hit a button or two and have the code return to a previous state can be a real blessing. After you’ve resolved the problem, you can check solutions back into the same clean code.
This heavily cuts down on repetition, maximizing efficiency and saving your team time, and time is frequently the scarcest currency in the production pipeline. Some estimates even have CI/CD as saving as much as 20% of development time. This means that you can get your apps to market faster with a much lower risk of disaster.
More productive developers
Perhaps most importantly, CI/CD leads to more productive developers. You’re cutting out the kinds of tasks that lead to burnout due to their incredibly repetitive and time-consuming nature. With tools to do all of the testing and checks, developers can focus on the code. As a result, your developers are much more likely to feel alright with their work: At the end of the day, people just aren’t machines and can only take so much repetition before their productivity nose-dives.
Cons
The disadvantages of CI/CD are pretty obvious; there’s still a rush, and if you rush code through the process, sooner or later you’ll find that problems are inevitable. For example, it’s possible that there is a better way to do something, but to complete the changes quickly, a developer chooses a temporary solution. Once these solutions deploy to production, it’s much harder to do it a better way later. This can create a lot of work down the road as a growing number of temporary fixes become permanent.
When you constantly change code, you also need to develop a continuous method of monitoring it and generating reports regarding it. In addition to regular testing, you require real-time monitoring to deal with deployed code so that you can find the problems as quickly as possible.
And if you don’t, you can be sure that your users will find those problems, resulting in not only a swarm of complaints aimed at your customer service team members and accompanying spiraling app ratings. This can be difficult to recover from—many a potentially great app has tanked due to this.
It’s simply never worth the risk.
Traditionally, CI/CD also requires that your team assign more team mates to handle the monitoring of the code, or at least more resources, but this is now far less of an issue than it was just recently, as we’ll discuss later in this entry.
The Difference between self-hosted and cloud-based CI/CD
With all that in mind, CI/CD has become incredibly popular within the mobile app world. This has resulted in a wealth of tools that may or may not work well for you. One of the first considerations when looking at CI/CD is whether you want to use self-hosted or cloud-based for your teams. Here’s how they differ:
- Self-hosted is on your local machine. This means you can customize so that you aren’t forced to work with out-of-the-box functionality you don’t need. You also benefit from complete control over your CI/CD process and system. While a fairly large undertaking that can require time and resources, it puts the control completely in your hands.
- Cloud-based is stored and managed in the cloud. Cloud-based CI/CD is far quicker to implement since it’s already set up and ready to use. This does mean that someone else is managing it, so you won’t be able to change the process, and if there are problems, you’ll want to be sure that the product offers solid support. Another huge benefit to cloud-based CI/CD is that these platforms tend to be easy to integrate with very popular tools like GitHub and Bitbucket.
Both of these methods will likely provide you with notifications during the CI/CD process, sending you notifications when different stages complete alongside their results. Self-hosted and cloud-based CI/CD both work to streamline the CI/CD pipeline so that the automated testing and verification run as smoothly and quickly as possible.
CI/CD considerations
Beyond whether your CI/CD setup lives in the cloud or on a local machine, you’d be wise to make several other critical considerations prior to implementing the process. Consider this:
- Compatability: You need to know how well tools will work on your platform, and how much support you’ll have based on that platform.
- Configuration: Look at the configuration requirements to determine if it is a good fit.
- Limitations: Identify any potential limitations, such as the number of builds allowed simultaneously. The larger your team, or the greater the types of changes you make, the greater the chance that you will need to select an option that allows for more than just a few builds at a time.
- Documentation and support: Don’t let this one be an afterthought! Check the documentation and support available for any CI/CD tools you’re considering. Some CI/CD tools are open source, so you will be able to go to the community to get a lot of your answers. Others offer a dedicated support team for customers.
Most of these considerations are ones you probably anticipated—they really aren’t that different from any other tool you need for development and deployment. Still, I recommend making a checklist to ensure that you don’t forget something that could be a deal breaker before you make your final choice. Better safe than sorry!
CI/CD and Sofy
If you haven’t been enmeshed in the development to deployment process, this may seem like a bit much to take in. The process from checking in code to the end user accessing it is not anywhere close to a straight line: There are so many things that need to be checked and verified at each stage of the process.
And yes, there’s a ridiculous amount of repetition. This is exactly why CI/CD was created— to automate all of that repetition.
Fortunately, you don’t have to understand the process, the numerous checks, or the points of verification—Sofy can take care of all of that for you. The development process is complicated and overwhelming even for those who have been through it because of how tight deadlines and turnarounds are.
With Sofy, you can quickly and easily integrate your favorite CI/CD setup and focus on what really matters: Innovating and keeping your user base happy!
Disclaimer: The views and opinions expressed above are those of the contributor and do not necessarily represent or reflect the official beliefs or positions of Sofy.
