As said we handle this a little different.
One branch for development, staging and live.
Development of the puppet code base is done using in puppet
environments, which can be used to test a change across systems in any
of the environments.
Once people consider the change working it is committed a
The git branches/Puppet environments actually mirror the
infrastructure. So we have groups of servers. Unstable is just for
nodes which I test new functionality on, dev is for web developers. So
it seemed to make sense to mirror the environments in the git
repository with branches.
On May 29, 9:28
Thanks guys, very interesting. I guess the main thing I'm concerned
about with my workflow is that I'll be doing a lot of merging, and I'm
not sure how sustainable that is. For example:
1. Add new feature to unstable
2. Merge to dev
3. Merge to testing
4. Merge to production
The idea being that o
We work only with one Git repository for Puppet, and it contains:
- 1 directory for hiera-data -> structured environments. For instance:
hiera-data
|--common
| |- us
|--master
| |- us
|--production
(etc)
- 1 directory for all nodes, and 1 manifests file (xx.pp) for each
I am setting up a new workflow myself, it will be as follows:
One git repo for modules and manifests, a second for hiera. Branches are
for features and personal development branches.
I might install forge repositories in a different modulepath to force
working with the community.
The git reposi
