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 habits that can eliminate that source of technical debt and the associated developer burnout.

Pain Points

  • “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

Benefits

  • 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

Assessment

  • You have an automated development pipeline from environment spin up and configuration through deployment and regression testing (Major Boost)
  • 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 (Significant Boost)
  • You don’t have continuous integration (build, deploy & test) or automated build capabilities but are working to introduce the capability (Significant Setback)
  • You don’t have continuous integration (build, deploy & test) or automated build capabilities (Disaster)

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

First steps to create this habit:

Setup

  1. Set an achievable goal. Possibly something as simple as automating a build after check in using a CI tool such as Jenkins
  2. Gain agreement within the team on the goal
  3. Ensure stakeholders understand the value of automation

Trial

  1. Automate your repetitive manual work
  2. Ensure you’ve done a good job of dealing with exceptions or handling potential problems that may arise.
  3. Commit to the trial and don’t back out at the first issue you couldn’t anticipate.

Evaluate Feedback

  1. How did you do? Is this an item for continuous review?
  2. How often can you carve out time for more adoption experiments that move the needle further toward full automation?
  3. 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

Warning Signs

  • 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 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→

Find Out More...

Follow @growsmethod in the Fediverse, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.