As mobile developers, we constantly strive for efficiency, optimizing our code-base through refactoring, proper code decoupling, intelligent code reusability and other object-oriented best practices, which is even more pivotal when working in teams, and working with tools like git for collaborative code-sharing, and tracking tasks, using agile methodologies.
This is what has led to the concept of Continuous Development, which encompasses the iterative methodologies of Continuous Integration (CI), and Continuous Deployment (CD).
Continuous Integration, abbreviated as CI, is the practice of having developers continuously (several times a day) integrate code into a shared git repository, triggering an automated build that would verify the integrity of the latest code commit, regressively.
What is Continuous Integration (CI)
CI serves purposely to detect errors in the entire code-base earlier 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 also provides the added benefit of greater transparency, the ability for other developers to access new code and catch potential issues earlier on.
Through development strategies such as GitFlow, teams would anoint a team-member whom would review code rapidly prior to it being pushed into the main development branch where an automated test tool would pick up the latest code and test for regression issues.
Prominent CI tools widely-used in the industry include Jenkins, CircleCI, Bamboo and TravisCI, which ideally would perform the part of either detecting new commits as they come in to a branch, or work on a daily/hourly interval and perform an automated build, as well as run pre-defined test cases. The outcome of those tests would be composed in a CI report that details the result of the build as well as all the test cases.
What is Continuous Deployment
Continuous Deployment, according to the Agile Alliance, is the philosophy of minimizing “the time lapsed between development writing one line of code and this new code being used by live users, in production“.
To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.
Instruments and processes such as continuous integration (CI) which we just mentioned, provide the process and mechanism for pushing code rapidly to a centralized repository branch, triggering an automated CI build to test for any regression concerns. This is where Continuous Deployment or CD comes in, along with fastlane, with the ability to take orchestrate code that has been tested through delivering app iterations rapidly to beta testers, and subsequently end-users in production. You will learn next what fastlane is, and how it helps automate the tasks of packaging and distributing your app, providing greater transparency and removing barriers to deploying your app more continuously.
What is fastlane?
Fastlane essentially is ”the easiest way to automate building and releasing your iOS and Android apps”, via a suite of tools that can either work autonomously, or in tandem, to accomplish tasks such as:-
- automate building and packaging iOS apps producing .ipa files;
- automate taking screenshots of your app across different screen types, sizes, and languages;
- automate uploading the screenshots and metadata and the packaged files to iTunes Connect directly, bypassing Xcode;
- automate and manage refreshing, renewing, repairing and managing signing certificates, provisioning profiles and push notification profiles;
- synchronize and share your certificates and profiles efficiently across other team- members;
- automate managing and on boarding testers to using your app, through TestFlight; and automate running tests for your app.
The net outcome of utilizing one more of the utilities above, is time, your ability to save hours and days working through app submission, provisioning and taking screenshots, and instead focusing on the aspects of your app development that do matter, solving bugs and adding new features. This is the mantra of continuous deployment and continuous development, the ability to code and release iteratively and rapidly, with minimal barriers, and this is what fastlane is.
Fastlane was the brainchild of Felix Krause , developed and open-sourced on Github back in 2014. After achieving a cult-like following by indie developers and eventually mainstream, being used by thousands of companies, in late 2015 was acquired by
Twitter and formed part of Twitter’s Fabric development suite, along with the author. Barely a year later, in early 2017, Fabric was itself acquired by Google , as part of Google’s Firebase mobile development platform , and the author moved to Google. Despite the project moving to Twitter and afterward Google, it very much remains an open-source and active project.
Fastlane is a ruby-powered configuration file, called a fastfile, grouped by lanes to serve different purposes and needs. For instance, you would have a lane for deploying to the App Store, from which you would have specific tasks, called actions, that you want to accomplish, such as incrementing your build number as you build your app, run actions such as cocoapods install, run tests, take screenshots, and upload your app and associative metadata to the App Store.
lane :beta do increment_build_number gym testflight end lane :appstore do increment_build_number cocoapods scan snapshot sigh deliver sh "./customScript.sh" ... slack end
As shown in the fastFile code-snippet above, you would have another lane for beta, to beta-test your app, and run through the automated tasks (actions) you would associate with beta-testing, from incrementing your build count, to building your app and pushing it to TestFlight. Of course, you could plug in other third-party tools, such as pushing to Fabric instead of TestFlight, as we will demonstrate in later chapters.
The real power of fastlane is in its extensibility, its ability to integrate with all of your familiar existing tools, and there are over 170 custom actions currently, according to the official website, with the ability to integrate with all major CI systems, such as Jenkins, which we will cover in later chapters.
THE FASTLANE SUITE OF TOOLS
Fastlane consists of the following family of tools, for both iOS and Android:
- gym, which automates building and packaging of your iOS apps, generating ipa; deliver, which uploads screenshots and metadata as well as .ipa files to iTunes Connect directly, without having to manually do so via Xcode;
- snapshot, which automates taking screenshots of your app for different screen types/ sizes, devices and languages;
- pem, which takes the hassle out of refreshing and renewing push notification profiles; sigh, which takes the hassle out of provisioning your app and device;
- produce, which automatically creates your iOS app on iTunes Connect and Dev Portal, without the need to enter it manually on the website;
- cert, for automatically maintaining iOS code signing certificates;
- pilot and boarding, which makes managing your TestFlight testers and builds easy, right from terminal;
- match, which helps in syncing and sharing your certificates and profiles with other team-members; and
- scan, which makes running automated tests on your apps a great deal more convenient.
As mentioned before, there are numerous custom actions that integrate with familiar tools you already have as part of your workflow, such as:
- Jenkins CI;
- SSH; and more.
Check out the book Continuous Delivery for Mobile with Fastlane to help get you started with setting up your mobile development environment for continuous delivery.