Getting the Most out of Docker and Workflows, Part 2: All About Workflows

Note from the publisher: You have managed to find some of our old content and it may be outdated and/or incorrect. Try searching in our docs or on the blog for current information.

---

In the previous installment, we saw how Docker images add power and customization to the build process. In this installment we’ll show you how to amplify that power by using the CircleCI 2.0 Workflows feature.

Workflows in detail

Simply stated, Workflows adds a simple coordination layer between jobs. Let’s start with a simple workflow.

The workflow config stanza and live workflow run (being logged into CircleCI required):

workflows:
  version: 2
  blog-demo-1:
    jobs:
      - bundle_dependencies
      - rake_test:
          requires:
            - bundle_dependencies
      - precompile_assets:
          requires:
            - bundle_dependencies
      - deploy:
          requires:
            - rake_test
            - precompile_assets

The blog-demo-1 workflow consists of 4 jobs. The bundle_dependencies job updates and caches dependencies. Then we “fan-out” into two parallel jobs - rake_test and precompile_assets. Each of these will restore dependencies and do their own work. If rake_test and precompile_assets are both successful, we “fan-in” to the deploy job.

Benefits

We could have just as easily made a single job that inlines all of the steps run. What did we gain by introducing Workflows?

Explicit parallelism = faster builds

Things happen faster when they happen in parallel.

The explicit “fan-out” parallelism offered by Workflows can significantly reduce build times, especially as a project grows in complexity over time, and more and more independent parallelizable tasks such as code coverage are introduced.

In the example above, rake_test and precompile_assets benefit from this parallelism.

Each job may run in a different environment

In our example above, the deploy job runs in a “machine” instead of a Docker container. You have the opportunity to specify a different Docker image and resource_class for each job.

In order to reduce costs and minimize build times, a user may want to use a featureful container with beefy resources to run some common precursor steps, then fan-out into many lighter-weight jobs for a fast parallelized build.

Repeatability - rerun from failed

If a job fails in the middle of a workflow due to a transient issue, such as a flaky text or a temporary outage in an external service, you do not have to restart the workflow from the beginning. The “rerun failed jobs” feature allows the workflow to carry on using the failed jobs as a starting point.

Without Workflows, you would always have to rerun the entire build.

Detailed status reporting to your VCS provider

With a workflow, your VCS provider (Github for example) will get a list of statuses–one for each job–this way it’s easier to tell at a glance where the failure happened and you can navigate directly to the job that failed.

Outro

In this blog post, we went through a gentle introduction to the Workflows feature of Circle 2.0. In the next installment, we’ll walk through adding some advanced features including:

• Workspace forwarding
• manual approval jobs
• branch and tag filtering