It was great speaking with Jim Rose, CEO of CircleCI, about how teams using Workflows will now be able to control each stage of their development process to match their ideal process from start to finish.

CircleCI 2.0 (currently in beta) recognizes Build-Test-Deploy as individual jobs with the release of Workflows. Users have complete flexibility and control over how each step in their process is executed.   

On CircleCI 1.0, users were constrained by the execution of jobs in a locked-step fashion. When tests failed, users were required to re-run builds from step 1, resulting in wasted time. Workflows gives developers control and flexibility by allowing them to designate exactly when, if, and how each job is run.

Why Workflows?

The ability to separate and orchestrate jobs has been a top-requested feature from users. Every team’s ideal process from code to production is different. Workflows gives teams the ability to mirror their ideal process in the configuration of their jobs, so that the way changes move from commit to testing to staging or deploy is fully in your control. Turning code into software is not a one-size-fits-all process, and each team should have their own software development workflows they can define for their individual needs. You may have seen similar concepts referred to as “pipelines” or “build stages.”

What Can I Do With Workflows?

Workflows support a number of configurations that you can start using today:

• Sequential job execution: Run build, test, and deploy sequentially as individual jobs and get faster feedback from each job. CircleCI 1.0 runs your build-test-deploy jobs in sequential lock-step.

• Parallel job execution (also includes build matrices): For granular build orchestration, faster builds, ability to run multiple jobs in parallel, and a way to resolve all relevant dependencies before you deploy. Parallel job execution also enables build matrices, which allow you to do tasks like build against multiple versions of a language at the same time for faster feedback.

• Fan-in/fan-out in a repo: Ideal for a more complex build orchestration. Allows you to run multiple jobs in parallel that lead up to a singular job (and vice versa from a singular job to multiple jobs).

• Branch-level filtering for job execution: Allows you to deploy your code off specific branches.

• Job execution from failed and job execution from start: Choose where and how your build re-runs to save repeating unnecessary jobs. This allows you to start your workflows from a failed job, as opposed to re-running your whole workflow.