Puppet environments vs Git branches

Learning Puppet and Git at the same time does make for a lot of confusion most of the time. But a video I watched the other day finally made something “click” in my head about how to manage our multiple environments with Puppet. I had been struggling with the belief that, since we have 3 environments — Dev, Test, Production — we were going to need to maintain 2 long-lived branches (“dev” and “test”) for modules and Puppet code to track changes we’re making, and then deal with using pull requests/etc to migrate the changes from Dev to Test to Production.

That seemed like it was all wrong. And I think it is.

Instead, a branch for a module/whatever will be used for testing something, and deployed as a dynamic environment via r10k to target server(s) for testing, and then we will issue a pull request/code review to merge that change back into the “master” branch once testing is complete. So all “real” servers in Dev, Test, and Production will always get “master” code deployed to them, with environment-specific differences managed via Hiera. The deployment will be controlled via something like Jenkins to ensure that once a change has been merged back into “master” it does not go right to Production with the next puppet agent run. Tags or something will need to be used to mark “master” as ready to go to Prod. Or else it would just be changes to the r10k control repository, and set eligibile versions there. Maintaining long-lived separate instances of a single control repo for each environment is not as daunting as maintaining three branches of everything all the time.

Anyway. Just tracking my current state of mind on this problem. When I think on it for a while, it seems clear in my head, but then I forget it by the next time I need to use it. So I’m leaving this here as a memory jog next time I get stuck.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.