Chapters

Hide chapters

iOS App Distribution & Best Practices

First Edition · iOS 14.4 · Swift 5.3 · Xcode 12.4

Section I: iOS App Distribution & Best Practices

Section 1: 17 chapters
Show chapters Hide chapters

Section II: Appendices

Section 2: 2 chapters
Show chapters Hide chapters

14. Continuous Integration
Written by Pietro Rea & Keegan Rush

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

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.

CI components

Continuous integration works through the combination of a build server, jobs and triggers.

Example of a CI workflow
Ekokmjo oj u YU xomypcoz

Different types of CI

Roughly speaking, CI providers come in three different flavors: full service, managed and manual.

Full-service CI

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

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 fastlane or xcodebuild.

Manual CI

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.

Uploading Emitron

To upload Emitron’s project code to your empty repository, you need to initialize Git within Emitron’s project folder on your machine.

git init

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:

touch .github/workflows/run-tests.yml

# 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

Transient builds

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.

Key points

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

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2024 Kodeco Inc.

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a Kodeco Personal Plan.

Unlock now