Uniform Build
A build in a Developer Workspace should provide the same results as the Integration Build.
Different Environments, Same Results
An Integration Build inevitably differs from the build in a Developer Workspace:
- A human or an IDE executes the Developer Workspace build commands; the Integration Build uses a pipeline tool such as Github Actions, Jenkins, Bitbucket, Circle CI, etc
- The Integration Build always runs the same steps in the same sequence, but a developer might want to run specific steps at different stages, for example, compile and test after each edit and “lint” only when ready to commit a change.
Even though one purpose of the Integration Build is to be a backstop to catch skipped steps or inconsistencies between the Developer Workspace and the CI environment, it can be frustrating and wasteful to push changes to a Task Branch and discover an unexpected failure in the Integration Build, and we want an opportunity to minimize the change of those errors.
Even though you want to be able to have a 100% likelihood of a change to a Task Branch passing CI, there may still be some checks that can run only in CI because of infrastructure of licensing requirements, for example, certain compliance scans. Some steps, such as artifact publication, are to happen exclusively in the CI Environment.
Some errors may still creep in because of minor environmental differences; if these are easily fixed, a few such issues are tolerable. We don’t want the quest for a perfect process to slow us down, either.
Once a Developer Workspace is set up with all the appropriate tools, the developer should be able to execute the same build and test commands that are run in the CI environment. While elements of a build pipeline are difficult to emulate in a local environment, the CI system should leverage mechanisms available to developers. Rather than copying build logic into Jenkins File or Github Actions Workflow, those mechanisms can run make build or a similar command that a developer can run locally.
Provide a Uniform Build process that developers can run in their workspace, which executes all the required steps to build an artifact .
Make the steps involved in setting up a build as similar as possible to those in the CI script. For example, if you use Make, there should be a makefile target that can be executed in either environment.
A developer can run that command as part of their pre-commit process. For example, you might have a command:
make build
Which could run:
- formating
- lint
- build
- test
If you want to separate these steps into separate CI stages, you can have the CI script run each sub-command separately, but be careful not to have the targets diverge.