In our last post, we covered parallel and sequential job orchestrations, and why teams might choose one or the other. In this post, we’ll be diving into multi-executor workflows.
What do we mean by multi-executor?
We sometimes refer to multi-platform support, meaning you can have the flexibility to run your jobs on different platforms such as Linux or macOS. Workflows provide teams the same modularity to run different languages within the same workflow. Additionally, they allow you to select from multiple resource classes to suit your job.
What are resource classes?
Resource classes gives you the ability to configure your CPU and RAM for each job. This means you can choose the amount of power that you need. We’ve often heard from customers that memory constraints can cause their tests to fail or would cause their build process to become extremely slow or max out their RAM, causing a browser crash. With resource classes, you can elect a large container where you need one, and a small one where you don’t.
Example 1: Facebook React
See Facebook’s config.yml here.
Facebook React’s dashboard is an example of a workflow running jobs across multiple platforms. After checking out code, they are running tests on Android, iOS, tvOS, and running end-to-end tests. This helps the team to get feedback from different platforms at the same time. For context, in CircleCI 1.0, you had to run each of these as different builds, but now with the combination of workflows and enabling different platforms within the jobs, you can push once and test on multiple platforms. If your team is building applications that span across multiple platforms, this would be a good option for you.
Special note for Android developers: Facebook React is running their jobs on a larger machine size to account for the fact that Android development often comes with more memory requirements. This job is running on a bigger box than their other jobs.
Example 2: Envoy Proxy
See Envoy Proxy’s config.yml here.
Envoy Proxy is another example of how teams are leveraging multi-platform workflows to get feedback from different languages across different platforms. With a single push, they are testing across multiple platforms (macOS and Linux). They use large and small resource classes and test across different environments to see if things are working as expected across platforms. Using CircleCI resource classes, you can run on a large box and a small box simultaneously– because using a large box for all jobs is not always the smartest option. In this example, Envoy Proxy is using XL resources for all their Linux jobs, while one of their less compute-intensive jobs are using a small resource class. Now using this multi-platform workflow, they can push once, and build on two platforms simultaneously, while also testing across all their jobs.
We’ve now looked at a few examples of how teams are running across multiple languages, operating systems, and also taking advantage of various resource classes to suit the particular job.
In our next post, we’ll be exploring flow control: different ways to use filtering and approval in your workflows.
