1) Review Step Outputs
Review each step’s output to ensure it is completing as expected. This is important because steps can silently fail or not work as intended. For example, if a caching key is not found in the restore_cache step it will not fail.
2) Review Step Placement
Review each step to see if it makes sense to have that step in the job. A job typically has a singular purpose and steps may fit better in their own job or in a different order. For example, if linting and unit tests are being done in the same job it may be a good idea to move the unit tests to a separate job. Especially if setting up dependencies for those tests are quick.
Having separation between various aspects of the pipeline allows those jobs to be run in parallel, reducing overall duration. The separation also provides clearer feedback when a pipeline fails.
3) Record Reusable Config Opportunities
Note any steps, groups of steps, executors, parameters, or jobs that are repeated in the config. Creating reusable config keys allows those keys to be more easily maintained. For example, if a job uses environment variables for credentials and those variables change they only need to be updated in one place.
Parameterizing jobs can be a great way to make the config easier to maintain. Steps can be conditional to allow for multiple situations, for example a staging environment vs production. Jobs can be conditional and have pre or post steps added to them which expands how parameterized jobs can be used.
If any of these reusable config keys are used in other projects, consider creating an orb to allow those keys to be used cross project and be maintained in one place.
Next Step: Review Each Job for Improvement Opportunities: Execution Environment Opportunities
Comments
Article is closed for comments.