Automate Build Pipelines
Teams build, test and deploy their code using consistent, automatic processes. Any required manual processes contribute significantly to technical debt. Manual build processes can be a major source of frustration and developer burnout, contributing significantly to turnover in teams. This is one of several critical practices that can eliminate that source of technical debt and the associated developer burnout.
- “But it works on my machine”
- Code is deployed through complicated manual processes that are brittle and error prone
- Unit tests or regression tests are performed manually
- Spinning up a new developer or test environment (for example, to test an experiment or demo a feature) requires significant manual involvement
- Business users rely on complicated or elaborate spreadsheets for reporting that require significant manual input
- Significant labor savings as defined tasks take no time away from development or operations tasks to complete
- Greatly shortened time to complete a task through automation such as regression testing, new machine spin up, etc.
- Reduced developer turnover as a result of automating deployment processes
- Perfect consistency across machines
- You have an automated development pipeline from environment spin up and configuration through deployment and regression testing (200pts)
- You’ve automated your build, deploy and testing processes as well as promotion of code to production and are working toward containers and automation of environment spin up (100pts)
- You don’t have continuous integration (build, deploy & test) or automated build capabilities but are working to introduce the capability (-100pts)
- You don’t have continuous integration (build, deploy & test) or automated build capabilities (-1000pts)
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
- Set an achievable goal. Possibly something as simple as automating a build after check in using a CI tool such as Jenkins
- Gain agreement within the team on the goal
- Ensure stakeholders understand the value of automation
- Automate your manual practice
- Ensure you’ve done a good job of dealing with exceptions or handling potential problems that may arise.
- Commit to the trial and don’t back out at the first issue you couldn’t anticipate.
- How did you do? Is this an item for continuous review?
- How often can you carve out time for more adoption experiments that move the needle further toward full automation?
- Is there another approach you want to try to automate more things to free more time for business capability development?
What Does it Look like?
In addition to having tasks automated, it’s critical that the automation components are checked in to a source code management system and trigger builds as components are changed. This enables the team to have immediate feedback of all changes and alerts teams as early as possible should a problem arise.
Early detection leads to early, cheaper fixes
- Team members are struggling to complete testing
- Deployment of code is unpredictable and difficult due to manual or poorly documented processes
- Only one team member knows how to build the application
- Teams complain about the amount of time they wait for a new environment or resource to become available for use in building business capabilities
How to Fail Spectacularly
- Rely on manual build, deploy and test practices for everything
- Don’t take advantage of the great leaps in DevOps made during the last decade
- Ignore team pain points around time consuming manual tasks
←Prev (Throw Out Before Add)(Tracer Bullet Development) Next→