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.
For both Web and mobile applications, the team currently favors using GitHub Actions for Continuous Integration.
Depending on the needs of the client and project, the following tools are also often used:
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.
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