Heads up... You're reading this book for free, with parts of this chapter shown beyond this point astext.
You can unlock the rest of this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.
Automation makes a developer’s life so much easier. One benefit of automation is that it removes some of the capacity for human errors. When your build script records all the steps for distribution, you’re much less likely to archive the app on the wrong Git branch or with the wrong build configuration.
So far, the automation you’ve explored is great for your own personal use. But working as a team, while filled with benefits, comes with its own set of problems.
In a team, coordinating work between developers can be as much work as the programming itself. Combining, or integrating, the work of each developer is a challenge.
Continuous integration (CI) is the development practice of integrating the team’s work early and often.
Rather than waiting weeks or months for the team to complete large chunks of work, CI makes quick work of team coordination by integrating all code in one central location. By frequently running unit tests to ensure that integration is successful, CI keeps the team clued in to the state of the app’s codebase.
Note: This chapter assumes some basic knowledge of Git and the command line, as well as your own GitHub account.
More CI benefits
Effortless integration is the first and foremost benefit of CI, but the advantages don’t end there. Here are some other important benefits.
Detecting problems early
Often, when someone refers to continuous integration, they’re referring to CI services. Developers implement continuous integration through the use of a CI service that provides a build server. While you can roll your continuous integration solution, it’s much easier with a service.
Providing a single source of truth
CI services leave your personal computer out of the equation. All you need to do is push your latest code to GitHub, and CI will build your app and run your tests in the cloud.
Continuous integration works through the combination of a build server, jobs and triggers.
Different types of CI
Roughly speaking, CI providers come in three different flavors: full service, managed and manual.
This is the most convenient option of the three. With a full-service CI provider, you get a simple point-and-click interface. The interface guides you through setting up your build to deploying it to TestFlight or elsewhere.
Managed CI straddles the line between guided point-and-click options and full customization. A managed CI service handles the hardware for you in the cloud. All you need to do is provide a build script, usually using
These services provide the most opportunity for customization. In addition to handling app building and deployment, you’ll also need to manage your own build server.
Implementing your first CI
Now that you know what continuous integration does and how it works, it’s time to jump in by implementing CI in the Emitron project.
Creating a GitHub repository
Any project that uses CI needs a version control system such as Git. Without it, there’s no easy way for your CI server to integrate everyone’s changes.
To upload Emitron’s project code to your empty repository, you need to initialize Git within Emitron’s project folder on your machine.
git add . && git commit -m "Initial commit"
git remote add origin \ https://github.com/TheCodedSelf/emitron.git
git branch -M main
git push -u origin main
Setting up GitHub Actions
Since your project is already on GitHub, GitHub Actions is a convenient solution for CI. Since you already have a GitHub account, you won’t need to sign up for any other third-party accounts.
mkdir .github && mkdir .github/workflows
Creating a workflow
Next, run this to create your first workflow file:
# 1 name: Run tests # 2 on: push # 3 jobs: build: runs-on: macos-latest # 4 steps: # 5 - uses: actions/checkout@v2 # 6 - name: Install fastlane run: | bundle install # 7 - name: Execute fastlane run: | bundle exec fastlane test
Usually, CI servers are transient. Whenever GitHub Actions runs one of your workflows, the build server starts in a clean state. Each time a workflow runs, you need to fetch the repository with
checkout and install any dependencies you need, such as fastlane.
Running the workflow
In your terminal window, run this command:
git add .github/workflows/run-tests.yml
git commit -m "Add first workflow"
git push -u origin main
Viewing the results
Back in your browser, navigate to your GitHub repository.
- CI helps you easily integrate the work of many developers.
- By paying attention to public build status, you can catch failing tests early, before they become a problem.
- Your CI server becomes a single source of truth that you can rely on if things aren’t working locally.
- A workflow is the combination of a trigger with one or more jobs.
- CI services can be full service, managed or manual.
Where to go from here?
In this chapter, you explored the benefits and practices behind continuous integration. You also created your first CI workflow, which runs Emitron’s tests and reports back on the state of the build.