How do people organize their Puppet manifests and modules in your source code repository? I am not seeing any obvious way to implement changes in Puppet in a phased manner on a single Puppet master.
How are other people managing this? One master server instance per server group/SDLC phase? I would very much like to use the same Puppet modules in each phase and just use subversion to change what version of the Puppet modules gets applied to each server group/SDLC phase so I can roll changes out in a phased approach. I'm looking for a way to leverage the same modules and avoid accidents and variation due to duplicate modules.
I have a slew of servers I am looking at using puppet to manage, with several SDLC (software development life cycle) phases to cover. Disaster recovery, Production, Staging, User Acceptance Testing, Test, Development, Training
Edit to clarify 2nd part:
And how do you maintain your branches in your source repo? For example, with dev and test branches, and a file that defines where I get my patches from.
Do you edit:
repo:/dev/patchessource.txt to contain "patchserver/dev"
repo:/test/patchessource.txt to contain "patchserver/test"
and have those files different, and have to maintain that difference with merging and everything from dev to test or do people have a different file for each environment and migrate them over as a whole:
repo:/dev/devpatchsource.txt to contain "patchserver/dev"
repo:/dev/testpatchsource.txt to contain "patchserver/test"
that way when you merge your dev repo to your test repo you don't have to worry about the dev specific setting overwriting your test specific settings?
I don't see an obvious solution to make it simple for follow-on administrators who may not be well versed in source code management tools.
Any tips would be greatly appreciated.