Production Automation

Why Production Rollout Needs More Than Dry-Run and Review

Advanced11 min read

What you'll learn

What's already solved: validation, review, and single-device safety primitives
The one gap none of that closes: staged, gated exposure across a fleet
That this module starts from 'already reviewed and approved,' not before
What this module reuses, and what it does not re-teach

🎓 Teach This Lesson

Listen to a guided explanation of this lesson.

Spoken narration isn't supported in this browser.

Everything up to "approved" is already solved

This module starts after the checkmarks, not before them

By this point in the curriculum, a change has already been dry-run and pre/post-checked (Reliable Automation), tested without real devices (Advanced Python Automation), diffed and reviewed on a branch before merging (Git / NetDevOps). This module assumes all of that already happened. The question it asks is different: the change is approved -- now what actually happens while it goes out to a real fleet?

Already solved -- reused, not re-taught

Dry-run / pre-check / post-checkReliable Automation
Tested without real devicesAdvanced Python Automation
Reviewed on a branch, diffed, mergedGit / NetDevOps
All of this validates the change is CORRECT

The gap -- this module

The change is correct. Now what?nothing yet governs the rollout itself
Every prior task ran against a fleet in one shotall at once, or a filtered subset -- never staged
Staged exposure, with a gate between stages

Quick checkConcept check

What does this module assume has already happened, before its own content even starts?

Nothing -- this module re-teaches dry-run and review from scratchThe change has already been dry-run/pre-post-checked (Reliable Automation) and reviewed/merged (Git/NetDevOps) -- this module starts from 'already approved,' not before itThe change has already been deployed to productionThis module doesn't require any prior validation at all

The precise, narrow gap

Not a new safety primitive -- a new control-flow shape

Retry (Reliable Automation), rollback (NAPALM), and per-device failure isolation (Multi-vendor Automation) are all real, already-taught safety mechanisms. None of them ask whether stage 1 of a rollout went well enough to justify exposing stage 2. That specific question -- and the decision it produces -- is what this module adds.

Quick checkScenario

A learner already knows retry policies, rollback, and per-device failure isolation. What genuinely new capability does this module still need to add?

A faster retry mechanismA staged rollout with an explicit gate between stages -- deciding whether a small subset's results justify expanding to the rest of the fleet, something none of those prior mechanisms do on their ownA way to avoid ever needing rollbackNothing -- those three mechanisms already solve staged rollout

What this module reuses, explicitly

Referenced, never re-explained

nr.filter() (Nornir), napalm_configure()/napalm_get() (nornir_napalm), and rollback() (NAPALM) are all used in this module's own capstone -- exactly as already taught, with zero new mechanics. Git's branch/diff/merge review process is referenced conceptually only ("already reviewed and approved") -- this module does not use GitPython or re-teach Git.

Quick checkScenario

Does this module use GitPython or re-teach Git branching/diffing?

Yes, extensively, as the primary mechanismNo -- Git/NetDevOps's review workflow is referenced only as a precondition ('the change is already reviewed and approved'); this module's own mechanics are entirely about Nornir/NAPALM staged executionYes, but only in the capstoneThis module replaces Git with a different review tool

Quick checkPredict output

Given this module's stated scope, which of these would you expect its capstone to demonstrate?

A real deployment to a hosted GitHub repositoryA staged rollout against NAPALM's real mock driver -- a small canary subset first, a gate decision, then either expansion or an automatic rollback -- entirely local, never a real production fleetA real CI/CD pipeline triggering on a Git pushA new database tracking rollout history

Key takeaways

This module starts from 'the change is already validated and reviewed' -- dry-run, pre/post-check, and review-before-merge are prerequisites, not re-taught here.
The precise gap: nothing yet stages a rollout into phases with a gate deciding whether to expand or stop.
Retry, rollback, and per-device failure isolation are real, already-taught primitives this module composes -- it does not reinvent them.
Git/NetDevOps is referenced conceptually only ('already reviewed and approved') -- this module never uses GitPython or re-teaches Git mechanics.

Done with this lesson?

Next lesson

Staging the Blast Radius: nr.filter() as a Canary Gate

Ready to practice?

Explore hands-on exercises and assessments for this module

Practice this module