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. These are even more pivotal when working in teams, working with tools like Git for collaborative code sharing, and tracking tasks using agile methodologies.

For project managers, being able to mitigate risks, reduce risks, and quantify development is pivotal to a project's success. This is what has led to the umbrella concept of Continuous Development, which encompasses the iterative methodologies of Continuous Integration (CI) and continuous deployment and delivery.

Development is a complicated domain in and of itself, and through rapidly introducing new code authored by different developers, the risk of introducing bugs is extremely likely. Besides the obvious errors, regression issues can many times be masked into future iterations, only to be discovered later, when technical code commitment is deeply entrenched. 

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:

• Unit testing
• Regression testing
• Integration testing
• Acceptance testing

Unit testing is the lowest level of testing, whereby the developer asserts a set of conditions that need to be true, as well as some that should be false and should essentially be very narrow and well-defined in scope. For instance, developers would assert what should happen when a text field has no input or when special characters are inputted, and will test various other constraints of the text field.

Regression testing is a type of testing that is written to address a bug and ensure that the bug will not occur again in the future. It will, therefore, be tested in future builds, and new tests will be added on top to ensure that those tests pass perpetually, providing the same outcome. 

Integration testing is performed across various realms or containers to ensure that in a decoupled environment, a code is fit into a bigger piece with another bit of code, and to make sure the integration is successful.

Acceptable testing is not an automated test but is rather manual testing that is done by the product owner to ensure the feature is implemented correctly. The testing is not done based on code/component isolation, but as a complete use case, end-to-end, from a user's perspective. 

This kind of test falls under continuous delivery, which we will be discussing later in this chapter, whereby the business/product team must assert whether a feature has been implemented correctly for it to be a candidate for production release. 

CI is the practice of having developers continuously (several times a day) integrate code into a shared Git repository, triggering an automated build that will regressively verify the integrity of the latest code commit. We will take a look at what CI and CD are next. 

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 time lapse 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:

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:

• Lower-risk releases: By being able to constantly release software internally and externally, the risk of long-term and hard-to-detect errors/issues is low. 
• Quality releases: Through automation tools, more automated testing, CD, and CI, developers gain the benefit of being less prone to errors. Unit testing and regression testing ensure that the code is more soundly built. 
• Respond to market faster: Releasing frequent small changes, to not only testers but even production, allows for User Experience (UX) and other feature feedback to be given more continuously, allowing for the project to pivot more quickly. This reduces the cost of having to change a larger set of features through a commitment to less code prior to feedback. 

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.

fastlane can be simply described as the easiest way to automate building and release your iOS and Android apps, via a suite of tools that can work either autonomously or in tandem to accomplish tasks such as:

• Automation of building and packaging iOS apps producing .ipa files
• Automation of taking screenshots of your app across different screen types, sizes, and languages
• Automation of uploading the screenshots and metadata and the packaged files to iTunes Connect directly, bypassing Xcode
• Automation of and management of refreshing, renewing, repairing, and managing signing certificates, provisioning profiles, and push notification profiles
• Synchronization and sharing of your certificates and profiles efficiently across to other team members
• Automation of managing and onboarding testers using your app, through TestFlight
• Automation of running tests for your app

The benefit of leveraging one or more fastlane actions is in your ability to save hours and even days, saving you the laborious task of having to submit, provision, and take screenshots manually, and instead allowing you to focus on what matters: that is, feature development. This is the mantra of Continuous Deployment and CD—the ability to code and release iteratively and rapidly, with minimal barriers. This is what fastlane is.

You also won't need to remember and call the individual fastlane actions individually; by using a Fastfile configuration file, you can store the actions in the sequence you want, under a grouping you can define and label, such as alpha testing, and call all the actions that belong to that grouping. 

fastlane was the brainchild of Felix Krause (https://krausefx.com/), developed and open sourced on GitHub (https://github.com/fastlane/fastlane) back in 2014. After achieving a cult-like following by indie developers and eventually becoming mainstream and being used by thousands of companies, in late 2015, fastlane was acquired by Twitter (https://krausefx.com/blog/fastlane-is-now-part-of-fabric) as part of Twitter's Fabric development suite (https://fabric.io/login?redirect_url=%2Fhome). Just over a year later, in early 2017, Fabric itself was acquired by Google (https://krausefx.com/blog/fastlane-is-joining-google), as part of Google’s Firebase mobile development platform (https://firebase.google.com/), and the author moved to Google. Despite the project moving to Twitter and then 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 have a lane for deploying to the App Store, from which you have specific tasks, called actions, that you want to accomplish, such as incrementing your build number as you build your app, running actions such as cocoapods installment, running tests, taking screenshots, and uploading your app and associative metadata to the App Store. Take a look at the following code snippet:

lane :beta do
# Increment build number in XCode
  increment_build_number  
# Build your app            
  gym       
# Upload to TestFlight                
  testflight                
end
lane :appstore do
  increment_build_number 
# Run cocoapods install
  cocoapods     
# Run tests              
  scan     
# Take screenshots                      
  snapshot              
# Provisioning      
  sigh    
# Upload app, screenshots and meta-data                            
  deliver           
# Run your own custom script          
  sh "./customScript.sh"              
  ...
# Notify your contacts on Slack
  slack                                
end                                                                                                                                              

As shown in the preceding Fastfile code snippet, you would have another lane for the 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; there are currently over 170 custom actions (https://docs.fastlane.tools/actions/), 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.

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:

In brief, the fastlane tools accomplish the following automations:

• gym: Automates building and packaging of your iOS apps, generating ipa files
• deliver: Uploads screenshots and metadata, as well as .ipa files to iTunes Connect directly, without having to manually do so via Xcode
• snapshot: Automates taking screenshots of your app for different screen types/sizes, devices, and languages
• pem: Takes the hassle out of refreshing and renewing push notification profiles
• sigh: Takes the hassle out of provisioning your app and device
• produce: Automatically creates your iOS app on iTunes Connect and the dev portal, without the need to enter it manually on the website
• cert: Automatically maintains iOS code signing certificates
• pilot: With boarding, makes managing your TestFlight testers and builds easy, right from the Terminal
• match: Helps in syncing and sharing your certificates and profiles with other team members
• scan: Makes running automated tests on your apps a great deal more convenient

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

• Slack
• Cocoapods
• Gradle
• Crashlytics
• Git
• IFTTT
• Jenkins CI
• SSH

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.

Before we begin working with fastlane, it's important to point out where you can access the fastlane documentation. Make sure you bookmark docs.fastlane.tools (https://docs.fastlane.tools/) for future reference, as well as the project GitHub page at github.com/fastlane/fastlane, as they will both no doubt come in handy throughout this book as we work on our project. In particular, the following sub-sections will prove especially useful throughout this book:

• docs.fastlane.tools/actions: A list of built-in fastlane actions. You can also type fastlane actions in the Terminal to get a list of all the pre-built actions and their associated details, right in the Terminal.
• docs.fastlane.tools/codesigning/getting-started: A quick reminder page on how to work with provisioning profiles and certificates.  
• docs.fastlane.tools/plugins/available-plugins: A list of all available plugins, some troubleshooting for popular plugins, and guidance on how to create your own plugins.

Additionally, you can also check out sample fastlane setups (https://github.com/fastlane/examples) from other companies, which you can refer to as you learn more about what each of the lanes and actions does and understand fastlane in greater detail.

In this chapter, you got an introduction to what fastlane is, as we mentioned the suite of tools that make up the toolchain. Additionally, we introduced you to the concepts of CI and CD and why they are quintessential to contemporary development teams.

In the next chapter, we will start to set up our environment by creating our project in Xcode and an initial setup of fastlane.