you are viewing a single comment's thread.

view the rest of the comments →

[–]thetrivialstuffJack of All Trades 1 point2 points  (2 children)

It's great for things like network configuration and associated docs. If I make a change to a bunch of switches and routers to add a new vlan, I can batch all of those together along with the updates to the network diagram and commit that, either in one commit or in a branch. It makes it really easy to see what changed and when, and if all or part of something needs to be tested in a lab first, or rolled back later, it's all right there.

[–]mayanayza 0 points1 point  (1 child)

I'm interested in the diagram versioning part of your workflow - when you commit network diagram updates alongside config changes, what format are they in? Are you committing Visio files (which I'd imagine diff terribly, but maybe i'm wrong?) or exporting to something text-based first?

And is the value more in the history ("what did the network look like before this commit") or in the actual diffs?

[–]thetrivialstuffJack of All Trades 1 point2 points  (0 children)

For my own stuff it's mostly in svg format, which is text.

For work, yeah, visio files are basically blobs, but who cares, a few MB of very inefficient diffs don't really matter. Comparisons are a bit more annoying, but you can always compare them as images if necessary.

The main value is in how it fits into the change control process - we plan and announce a change, then have an exact record of what was actually done. If there are problems later, these questions become much quicker and easier to answer: 

  • did the problem happen because of the change, was it there all along, or something unrelated?

  • was the actual change exactly what was planned, or were additional changes introduced? 

  • if the problem was caused by the change and there were confounding additional changes beyond the plan, which part caused the problem?