Continuous Delivery for Mobile with fastlane: Automating mobile application development and deployment for iOS and Android

Continuous Delivery (CD) and Continuous Integration (CI) have emerged as an industry standard in order to instill confidence in each iteration of code change. Tool automation relies on automation testing, which is broken down into several types of testing and testing categories:

CI serves to detect errors in the entire code base early on through the frequency of code integration by developers, whereas having significant gaps between integrations will result in more masked and complex errors accumulating.

CI entices developers to commit early and frequently, integrating the code commits into shared code repositories daily, or even hourly, instead of building features and code in isolation to integrate them when the feature is complete. Committing frequently and early adds greater transparency and the ability for other developers to access new code and catch potential issues early on. It solicits opinions, debates, and testing in a more agile manner, and reduces merge conflicts; or, at the very least, it discovers conflicts early on. 

Through development strategies such as GitFlow (https://www.atlassian.com/git/tutorials/comparing-workflows), teams appoint a team member who will review code rapidly, prior to it being pushed into the main development branch where an automated test tool picks up the latest code and tests for regression issues.

Prominent CI tools widely used in the industry include Jenkins (https://github.com/jenkinsci/jenkins), CircleCI (https://circleci.com/about/), Atlassian's Bamboo (https://www.atlassian.com/software/bamboo), and TravisCI (https://github.com/travis-ci/travis-ci), which ideally perform the part of either detecting new commits as they come into a branch or working at daily/hourly intervals and performing an automated build, as well as running predefined test cases. The outcome of these tests is composed in a CI report that details the result of the build, as well as all the test cases.

The key term is automation, the use of tools to automate testing and delivery continuously, reducing the possibilities for developers and testers to cause errors. 

In the later chapters of the book, we will demonstrate how to integrate fastlane into a development-CI workflow with Jenkins. Now, we will take a look at CD.

Continuous Deployment, according to Agile Alliance, is the philosophy of minimizing the timelapse between development writing one line of code and the new code being used by live users in production. In fact, it can be considered an extension of CI. 

CI reduces risk through automated bug discovery (unit testing and regression testing); Continuous Deployment reduces risk by being able to distribute the product to alpha and beta testers more frequently, to obtain feedback more quickly.

That is, teams will benefit from being able to solicit earlier feedback and test hypotheses more rapidly through Continuous Deployment, which affords practices such as A/B beta testing. Reducing lead time reduces the risk of the unknown that comes with assumptions. 

To achieve Continuous Deployment, the team relies on infrastructure that automates and instruments various steps leading to deployment so that after each integration successfully meets the release criteria, the live application is updated with new code.

Instruments and processes, such as CI, which we just mentioned, provide the process and mechanism for continuously pushing code to a centralized repository branch, triggering an automated CI build to test for any regression concerns. 

Continuous delivery is commonly mistaken with CD; however, they are distinct differences, despite sharing commonalities. CD implies that every change is deployed to production continuously, whereas continuous delivery implies that the team ensures every change can be deployed to production but may opt not to. The distinction is the ability to filter or omit a change from production. This is usually due to business reasons (release timing). Take a look at the following diagram:

Figure 1: Family of tools that are part of fastlane (Source: fastlane.tools)

Like Continuous Deployment, continuous delivery focuses on automation tools in order to promote code from the shared code repository into distribution to beta testers or production. The code is picked up from a branch that should always be in a deployable state, gets built through CI, and is subsequently deployed using CD. Continuous delivery is the business choice to promote beta features into production manually. 

This doesn't mean that the feature is not delivered to beta testers; in fact, it is more common that the feature makes it to the beta testers as well as a business team to decide on the timing of the release. It is also based on other factors, such as if the code been well-tested, with the decision left to the product owner.

The benefits of CD and CI include the following:

This is where CD comes in, along with fastlane, with the ability to orchestrate code that has been tested by delivering app iterations rapidly to beta testers, and subsequently, to end users in production. Next, you will learn what fastlane is and how it helps to automate the tasks of packaging and distributing your app, providing greater transparency and removing barriers to deploying your app more continuously.

Over the years, iOS developers have come to appreciate the pain that comes with interacting with the App Store, iTunes Connect, and the Apple developer portal. The manual process of having to go into the portal in order to deal with provisions profiles and to hand a new team member access to code sign the app frustrates the best of developers. 

Updating the App Store screenshots each time the app's UI changes and each time a new iPhone or iPad screen size is introduced is laborious, especially when the screens have to be done for each locality (English, German, French, for instance).

Deploying the app to testers, and subsequently out to the App Store itself, is another cumbersome set of tasks that developers will often hesitate or drag their feet at. To deploy a new app to beta testers, developers have to go through the process of having to increment the app's bundle version number, push a new version back to Git, code sign the app with a valid provisioning profile, generate an IPA file, and then deploy it to TestFlight. 

This is what makes fastlane a quintessential tool for the iOS developer; it breaks down the mental and physical barriers to CD through simple commands that, when grouped into lanes, allow not only developers but even less savvy technical folks to trigger a set of actions that accomplishes all of the preceding actions with minimal fuss. Reducing the cost of ownership by allowing any developer (or non-developer), as opposed to depending on one centralized subject-matter expert, means there are fewer bottlenecks. 

fastlane consists of the following family of tools, for both iOS and Android:

Figure 2: Family of tools that are part of fastlane (Source: Fastlane.tools)

In brief, the fastlane tools accomplish the following automations:

Furthermore, there are numerous custom actions that integrate with familiar tools you already have as part of your workflow, such as:

The suite of tools that fastlane provides are all due to Spaceship (https://github.com/fastlane/fastlane/tree/master/spaceship#readme), a framework that directly connects with the Apple developer center through APIs via HTTP, rather than previously scraping Apple's web services. This increases the speed of all the fastlane tools tremendously; in fact, it speeds up over 90% of actions, as it bypasses the overhead involved with loading images and other unnecessary assets not pertinent to the tasks at hand. The following is the logo of Spaceship:

The Spaceship is a Ruby library that exposes the Apple developer center and iTunes Connect API. It's superfast, well-tested, and supports all of the operations you can do via the browser.

Spaceship even handles authentication (including 2-factor authentication) with Apple's servers securely, storing the result in the user's local folder privately. You can try out Spaceship in Xcode Playgrounds by typing in fastlane spaceship (you will need to install pry first by typing in sudo gem install pry).  Take a look at the following screenshot:

In the preceding playground screenshot, we created a new app called Spaceship App, by trying out a Spaceship command. Consult the Spaceship documentation by typing docs in Playground, and you can find some more recipes you can try directly on here. However, as with most, you won't need to work with Spaceship directly, as fastlane will appropriately facade a lot of the tasks through simpler actions, but it is useful to look a little under the hood and see how the fastlane engine works.