Chapters
Chapters

Chapters

Hide chapters

Android App Distribution

First Edition · Android 12 · Kotlin 1.5 · Android Studio Bumblebee

Before You Begin

Section 0: 5 chapters
Show chapters Hide chapters

Section I: App Store Quick Start

Section 1: 4 chapters
Show chapters Hide chapters

Section II: Security & Optimization

Section 2: 6 chapters
Show chapters Hide chapters

Section III: Automation: Continuous Integration & Delivery

Section 3: 2 chapters
Show chapters Hide chapters

Section IV: Beyond Publication

Section 4: 3 chapters
Show chapters Hide chapters

12. Continuous Integration & Build Servers
Written by Evana Margain Puig

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In the previous chapter, you learned about Fastlane, one of the best automation tools for your local environment used by developers worldwide. You also learned how to build, test, take screenshots and release your app with Fastlane.

Fastlane is a great tool and one that you’ll often encounter in your Android development career. But most companies take it one step further. Instead of making developers do automation tasks on their local machines, they delegate them to build servers.

This chapter will teach you how to use a free and open-source build server hosted by GitHub called GitHub Actions. With its help, you’ll take your automation skills to the next level. Even better, you’ll free your computer from executing tasks locally so you can continue developing while the server does its job.

The benefits of CI

Before diving into build servers, it’s important to understand two common terms: Continuous integration and Continuous delivery, also known as CI/CD. These two terms are often a source of confusion, and many developers have trouble understanding the difference between them.

  • Continuous integration: A development practice where you continuously merge code into the main repository. Once you merge the code, a series of automated tasks occur, such as testing or linting the code.

  • Continuous delivery: The process of delivering useful and working code to the final user in a consistent timeframe. Depending on the project and number of developers, a company can choose a CD pipeline that runs as often as once a day or infrequently as every two weeks.

Finally, take a look at build servers.

  • Build servers: Dedicated instances of virtual machines that can build, test and run your code. In Android, the server you use will compile Android code on a version you specify when configuring it.

Advantages of using a build server

At this point, you may be thinking there’s not much of a difference between build servers and what you learned in the last chapter. Here are some examples of the advantages build servers provide:

Which CI/CD provider to use?

There are many CI/CD providers out there. Like most things in tech, and life, each has its advantages and disadvantages. Here’s a list of the some of the most commonly used CI/CD providers in the Android platform. This list is not exhaustive, but a good starting point when looking for a provider.

GitHub Actions

Bitrise

CircleCI

Jenkins

GitHub Actions

You are going to use GitHub Actions as the CI tool for this chapter. Before using GitHub Actions, you need to upload the project to GitHub. If you already know how to do this, create a repo with PodPlay and skip the next section. Otherwise, follow along.

Uploading PodPlay to GitHub

You didn’t come to this chapter to only read theory, and at this point, you’re probably eager to create your own CI/CD pipeline. To work through this part of the chapter, you’ll need a GitHub account and to upload your PodPlay code to a repository there.

Getting started with GitHub Actions

Go to the main page of the repository. In the horizontal menu below the repo’s name, click the button labeled Actions.

YAML building blocks

A build server can execute many key actions through the YAML files. GitHub has a catalog of pre-made actions that you can integrate into your flows.

Name

This is the name at the top of the YAML file in line three. You can rename it to anything you want. Preferably, choose a name that will help you identify what that particular flow does.

Triggers

As the word suggests, Triggers are situations that cause a workflow to run.

Branch triggers

The most common trigger is when a specific action happens on a branch. In this example, you’ll use a push to the master branch. This kind of trigger may also occur when you merge a pull request in a branch.

on:
  # Triggers the workflow on push or pull request events but only for the master branch
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

on:
  push:
    branches:
      - 'master'

Ignoring branches

In the same way that you can trigger a flow when something happens, you can also ignore branches. Imagine a feature branch where developers are making tons of changes, but none of them is final. You can ignore those branches so developers don’t overload the build server with any minor changes they make to their branches.

on:
  push:
    branches-ignore:
      - 'feature/**'

Workflow dispatch

In the YAML file GitHub Actions generated for you, the next line reads workflow_dispatch: with nothing else. This line tells GitHub Actions that you want to run the flow manually directly from their site.

Jobs and steps

The next part of the code is jobs. Jobs are a group of actions that run together independently of other jobs to complete a particular action.

Creating a job

Your current sample file only has one job. To practice, you’ll now create another job that will run your tests.

  test:

Setup tasks, commands & actions

As mentioned earlier, jobs run several steps. If you look at the sample file, each step starts with a hyphen and can consist of one or more lines. They continue until you encounter the next hyphen, a new job or the end of the file.

Setup tasks

If you have a complex workflow, setup tasks will help you define a specific job’s dependencies and other technical aspects. You already learned about one setup task, the runs-on keyword. As you learned before, this tells the virtual machine what kind of environment you want your flow to run on.

    runs-on: ubuntu-latest

Commands

Commands are instructions you give to the build server’s terminal and run in an automated way. Whenever you run a manual Android build, as shown at the beginning of the chapter, you give instructions to the terminal to execute things.

    steps: #1
      - name: Run a log message #2
        run: echo This is my job for running tests! #3

Actions

Explaining what an action is might seem redundant, but think of it this way. Action is a single command in your workflow. It’s the smallest unit in your YAML file: Workflow > Jobs > Steps > Actions.

      - uses: actions/checkout@v2 #1

      - name: set up JDK #2
        uses: actions/setup-java@v1 #3
        with:
          java-version: 11 #4

      - name: Unit tests
        run: ./gradlew test #5

  test:
    runs-on: ubuntu-latest
    steps: #1
      - name: Run a log message #2
        run: echo This is my job for running tests! #3

      - uses: actions/checkout@v2

      - name: set up JDK #2
        uses: actions/setup-java@v1 #3
        with:
          java-version: 11 #4

      - name: Unit tests
        run: ./gradlew test

Key points

  • CI is short for Continuous integration. It refers to the process of continually merging your code into a repository. The server takes care of testing, linting and other helpful things in your code.
  • CD is short for Continuous delivery, the process of delivering to production as often as possible with the help of a build server. This process is not covered in detail here because it’s a topic on its own, but the same build server can take care of it.
  • Build servers are powerful machines that release your time and resources while saving your project from human error when automating tasks.
  • There are many CI/CD providers with their own advantages and disadvantages.
  • In this book, you tried GitHub Actions as your build server because it’s free and easy to use.
  • You need to upload a project to a GitHub repo to use GitHub Actions in it.
  • GitHub Actions provides pre-made workflows that match your needs and get you started with a YAML template.
  • YAML files are the base of Continuous Integration Servers, and the language and commands are very similar across build servers.
  • You can set up triggers, such as when you create a pull request or push code to the repository, to automatically start your workflows.
  • Workflow Dispatch refers to manually triggering a workflow without the trigger happening automatically.
  • YAML files require a series of keywords to work. The most important are jobs, steps and actions.
  • It’s easy to monitor and debug your workflows through the GitHub Actions tab on the repository’s webpage.

Where to go from here?

Congratulations! You just created your first CI pipeline.

11. Automation Tools for Your Local Environment
13. Getting Top Ratings & Avoiding Negative Reviews: Gathering In-App Feedback
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 accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now