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 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:
- 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.