nimblehq.co

Continuous Integration

Hero image for Continuous Integration

Automate All The Things! – Anonymous meme character

Automating the execution of checks and test suites each time new code is pushed to the code repository allows developers to:

  • Get fast feedback on their current work. They can thus prepare the necessary changes if their branch breaks the application. In addition, code reviewers can only start reviewing and approving pull requests that pass the required checks.

  • Delegate the execution of tests to a dedicated server, i.e., developers should not have to run the test suites on their machine. Running tests usually use lots of computing resources and require isolated environments.

    Tools

GitHub Actions

For both Web and mobile applications, the team currently favors using GitHub Actions for Continuous Integration.

Alternatives

Depending on the needs of the client and project, the following tools are also often used:

Learn more about Continuous Delivery

Optimizations

Parallelism

To reduce the time it takes to run the test suites, the team uses parallelism to split the tests into jobs.

For example, the team commonly uses the strategy to run non-UI and UI tests in separate jobs. Specifically, with GitHub Actions, the team uses the matrix strategy to run the tests in parallel on different platforms.

Self-hosted Test Runner

Depending on the platform and the project needs, the team uses self-hosted runners to execute the test suites. In other words, the team uses its own machines to run the tests instead of relying on the service providers’s machines.

The main use case is to run tests on self-hosted macOS machines for cost optimizations.

Learn how to use self-hosted runners with GitHub Actions

The team only enables self-hosted runners for private repositories. This is because forks of public repositories can potentially run dangerous code on self-hosted runner machines by creating a pull request that executes the code in a workflow.

Skip CI

Currently, only Bitrise supports skipping builds via the pull request’s title. To not waste CI/CD resources on Bitrise, in specific situations, the developer can skip the build if it is expected to fail or be re-triggered again by adding a [skip ci] prefix in the pull request’s title. Then to resume the workflow trigger, remove the [skip ci] prefix.

[skip ci] [sc-32874] [UI] As a user, I can access my home screen
# or
[skip ci] [#123] [Backend] As a user, I can access my home screen

For more universal approaches, refer to Skip CI from the Committing Code page.

There are a few tags to allow skipping builds supported by Bitrise, such as [skip ci] and [ci skip]. For consistency purposes, let’s stick with the [skip ci] tag.