Versioning Real Automation Artifacts: Rendered Templates and NetBox Snapshots

Two artifacts this curriculum already knows how to produce

Output, not production

This lesson does not render a Jinja2 template (Phase 2.9) or query NetBox (Phase 3.7) -- both are treated as already-known, already-verified capabilities. What's new here is committing their OUTPUT to a real repository, so that output has a history.

artifact 1 -- a rendered config, the exact shape Jinja2 rendering already produces

rendered_config = (
  "hostname SW2\n"
  "interface Ethernet1\n"
  " description mgmt-uplink\n"
  "vlan 10\n"
  " name USERS\n"
)
with open("repo2/rendered_sw2.cfg", "w") as f:
  f.write(rendered_config)

repo.index.add(["rendered_sw2.cfg"])
commit1 = repo.index.commit("Commit rendered SW2 config")

rendered_config here is written directly, standing in for whatever Phase 2.9's Jinja2 rendering already produced -- this lesson picks up after rendering, not during it.

Quick checkConcept check

Does this lesson use Jinja2 to produce rendered_config?

Yes, a template is rendered here for the first timeNo -- rendered_config represents output Phase 2.9's Jinja2 rendering already knows how to produce. This lesson commits that output; it doesn't re-teach or re-invoke the rendering stepYes, but with a different templating engineThis lesson doesn't work with configuration files at all

A NetBox-style snapshot: a static, clearly-labeled fixture

Not Phase 3.7's mock server, reinvoked

Phase 3.7 built a real, local mock NetBox REST backend and queried it live with pynetbox. This lesson does neither -- netbox_snapshot below is a plain, static JSON fixture, explicitly labeled as a stand-in for what a real NetBox export would look like. The subject here is versioning that snapshot, not querying NetBox again.

artifact 2 -- a static, labeled snapshot fixture

netbox_snapshot = {
  "_source": "NetBox export snapshot (static fixture, not a live query)",
  "devices": [
      {"name": "SW1", "site": "hq", "platform": "cisco_ios"},
      {"name": "SW2", "site": "hq", "platform": "arista_eos"},
  ],
}
with open("repo2/netbox_snapshot.json", "w") as f:
  json.dump(netbox_snapshot, f, indent=2)

repo.index.add(["netbox_snapshot.json"])
commit2 = repo.index.commit("Commit NetBox inventory snapshot")

The _source field states plainly what this is -- a fixture, not a live NetBox response. Real, verified commit, executed against a real local repo.

output — real, verified

commit1: 60aaa6b3 'Commit rendered SW2 config'
commit2: bc2170be 'Commit NetBox inventory snapshot'

Real, verified output. Two commits, two different artifact types, in the same repository.

Quick checkIdentify the correct code

Why does netbox_snapshot include an explicit _source field?

It's required by NetBox's real APITo label the fixture honestly as a static stand-in, not a live query result -- consistent with this module's locked instruction to never reintroduce Phase 3.7's mock server hereGit requires a _source field on every JSON fileIt has no purpose

Diffing a source-of-truth change over time

real, executed -- a device added to the snapshot, the same growth demonstrated live in Phase 3.7

snapshot["devices"].append(
  {"name": "SW3", "site": "branch1", "platform": "cisco_ios"}
)
with open("repo2/netbox_snapshot.json", "w") as f:
  json.dump(snapshot, f, indent=2)

print(repo.git.diff("netbox_snapshot.json"))

Phase 3.7's own capstone proved live that adding a NetBox device record changes what Nornir loads. This lesson shows the other half: that same change, now captured permanently in history.

output — real, verified

diff --git a/netbox_snapshot.json b/netbox_snapshot.json
index b08e2ae..6889e50 100644
--- a/netbox_snapshot.json
+++ b/netbox_snapshot.json
@@ -10,6 +10,11 @@
     "name": "SW2",
     "site": "hq",
     "platform": "arista_eos"
+    },
+    {
+      "name": "SW3",
+      "site": "branch1",
+      "platform": "cisco_ios"
   }
 ]
}
\ No newline at end of file

Real, verified output, shown exactly as produced -- including git's own trailing 'no newline at end of file' marker line, a genuine artifact of how the JSON was written, not edited out.

Quick checkPredict output

What does this diff prove that Phase 3.7's own live demonstration (adding a device, re-running InitNornir()) didn't?

Nothing new -- it's the same demonstrationThat the change is now permanently recorded -- Phase 3.7 showed the inventory growing live, in memory, for one run; this diff shows that exact kind of change captured as a real, permanent, reviewable commit in historyThat NetBox itself was contacted againThat the snapshot format is different from Phase 3.7's real data

Quick checkScenario

A learner claims this lesson 'tested NetBox integration.' Is that an honest description?

Yes -- committing the snapshot is equivalent to testing NetBoxNo -- this lesson genuinely verified committing and diffing a static, labeled fixture in Git. It did not query NetBox, real or mocked, at any point -- that verification belongs to Phase 3.7, not hereYes, since the fixture contains real NetBox field namesNo, because Git itself was never actually tested either

Key takeaways

This lesson versions output already known how to produce (Phase 2.9's rendering, Phase 3.7's NetBox data) -- it doesn't re-teach producing either.
The NetBox snapshot is a static, explicitly-labeled fixture -- Phase 3.7's real mock server was deliberately not reinvoked.
Two real commits, two different artifact types, verified in the same repository.
A real diff showed a source-of-truth change over time -- the permanent-record complement to Phase 3.7's own live dynamic-inventory demonstration.

What you'll learn

Two artifacts this curriculum already knows how to produce

A NetBox-style snapshot: a static, clearly-labeled fixture

Diffing a source-of-truth change over time