Each Rapid project has workflows that define the actions to perform during the
release process. Workflow actions can be performed serially or in parallel, and a
workflow can launch other workflows. Rapid dispatches work requests to tasks run‐
ning as a Borg job on our production servers. Because Rapid uses our production
infrastructure, it can handle thousands of release requests simultaneously.
A typical release process proceeds as follows:
- Rapid uses the requested integration revision number (often obtained automati‐
cally from our continuous test system) to create a release branch.
- Rapid uses Blaze to compile all the binaries and execute the unit tests, often per‐
forming these two steps in parallel. Compilation and testing occur in environ‐
ments dedicated to those specific tasks, as opposed to taking place in the Borg job
where the Rapid workflow is executing. This separation allows us to parallelize
- Build artifacts are then available for system testing and canary deployments. A
typical canary deployment involves starting a few jobs in our production envi‐
ronment after the completion of system tests.
- The results of each step of the process are logged. A report of all changes since
the last release is created.
Rapid allows us to manage our release branches and cherry picks; individual cherry
pick requests can be approved or rejected for inclusion in a release.