We are very excited to introduce the availability of Build Stages as a beta feature today.

Build stages are our interpretation of a flexible and practical continuous delivery pipeline. They give you more control over your build process, and over how your code flows from check-in to production. This allows Travis CI to provide you and your team a better continuous delivery solution.

What are Build Stages?

With build stages, we’re now implementing one of the longest standing feature requests from Travis CI users: in the simplest and most common use case, you can now make one job run only if several other, parallel jobs have completed successfully.

What could this look like in practice? Let’s say you want to test a library like a Ruby gem or an npm package against various runtime (Ruby or Node.js) versions in parallel (we have supported this parallelization with our build matrix feature from the beginning). And you want to release your gem or package only if all tests have passed and completed successfully. Build stages already make this very basic and common workflow possible.

Of course, there are a lot more, and a lot more complicated use cases than this one. You can, for example, also use build stages to warm up dependency caches in a single job on a first stage, then use the cache on several jobs on a second stage. Or, you could generate a Docker image and push it first, then test it on several jobs in parallel. Or, you could run unit tests, deploy to staging, run smoke tests and only then deploy to production.

We’ve been very grateful to our amazing community for having come up with third party solutions to this, such as dmakhno/travis_after_all, alrra/travis-after-all, and badboy/travis-after-all-rs. Now, we’re thrilled to finally accommodate such use cases as a native feature.

Jobs run in parallel, stages sequentially

The concept of build stages is powerful and flexible, yet simple and approachable:

Stages group jobs that run in parallel, while their stages run sequentially.

A stage is a group of jobs that are allowed to run in parallel. However, each one of the stages runs one after another, and will only proceed if all jobs in the previous stage have passed successfully. If one job fails in one stage, all other jobs on the same stage will still complete, but all jobs in subsequent stages will be canceled, and the build fails.

You can configure as many jobs per stage as you need, and you can have as many stages as your delivery process requires.

In the following example, we are running two jobs on the first stage, called test, and then run a single third job on the second stage, called deploy:

How to define Build Stages

Here’s how you’d set up the build configuration for this in your .travis.yml file:

jobs:
  include:
    - stage: test
      script: ./test 1
    - # stage name not required, will continue to use `test`
      script: ./test 2
    - stage: deploy
      script: ./deploy

Stages are identified by their names. You are free to pick any arbitrary names you like, and you do not have to specify the name on every single job (as shown in the example above).

More information about Build Stages

Find out more about stage names, and several other aspects of this feature in our documentation here, including 10 example configurations and builds for various use cases.

Of course, build stages also work as expected when combined with build matrix expansion, our deployment integrations, and features such as allowed failures. You will find more details about this in our documentation.

We are also happy to announce that build stages will be included in the upcoming release of Travis CI Enterprise 2.2.

We’d love to hear your thoughts

We’d love to hear your feedback, thoughts and suggestions for build stages in our beta feature issue.

If you have any questions or need help with your configuration, as always, please do not hesitate to email us at support@travis-ci.com.