DevOps automation

Automate first what is repetitive, error-prone and frequent: builds, tests, deployments and the links between the work and the code.

What to automate first

  • The build and the unit tests on every push.
  • Deployment to test environments.
  • Infrastructure, described as code and versioned.
  • Status updates that people currently copy by hand.

Conventions that make automation work

Automation needs something to hold on to. Naming branches, pull requests and commits with the work item's code — for example PBI-364 — lets every tool connect the code to the work without anyone linking it by hand.

What not to automate

Decisions that carry accountability, such as authorizing a risky change in production, should stay with a named person. Automate the evidence they need, not the decision itself.

How DevGob applies it

Writing an item's code in a branch, pull request, commit or release notes links that GitHub activity to the item in DevGob automatically, and CI results appear on the item they ran for.

Read it in the documentation

Related topics

Continuous delivery Continuous delivery keeps every change ready to release: built, tested and deployable at the push of a button, in small and frequent batches. Continuous testing Continuous testing checks every change as early as possible and keeps the results as evidence for whoever has to authorize the release. DevOps tools A DevOps toolchain covers planning, source control, CI/CD, testing, release governance and monitoring. What matters is how well the pieces connect.

DevOps with governance, on one record

DevGob plans the work and governs every change on its way to production: backlog, sprints, committee authorizations, install evidence and an audit trail.

Request a workspace Documentation