I''m currently trying to work out the best way structure my Puppet environments and VCS structure. At the moment I''mk working on something like this: Three Git repositories (one for modules, one for Hiera, one for node manifests) Multiple branches (each branch representing an environment, e.g. production, dev, testing etc.) When changes to modules/Hiera are made, the changes will be made to a testing branch, and then merged up the branches until it hits production (with the appropriate testing of course). So something like this: unstable > dev > testing > production What system do you guys use? Any suggestions about the above workflow? Thanks! Andy -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 repository goes through gerrit and all commits are automatically check checked for syntax or lint errors by jenkins before they are merged. All modules updates might also require a visual code-review, don''t know yet. Different environments (development, staging, etc) are represented using an extra hiera lookup level and are also reflected in the node to modules mapping thats in place. This is what works for us. Jos On Monday, May 28, 2012 3:14:54 PM UTC+2, Andy Taylor wrote:> > I''m currently trying to work out the best way structure my Puppet > environments and VCS structure. At the moment I''mk working on > something like this: > > Three Git repositories (one for modules, one for Hiera, one for node > manifests) > Multiple branches (each branch representing an environment, e.g. > production, dev, testing etc.) > > When changes to modules/Hiera are made, the changes will be made to a > testing branch, and then merged up the branches until it hits > production (with the appropriate testing of course). So something like > this: > > unstable > dev > testing > production > > What system do you guys use? Any suggestions about the above workflow? > > Thanks! > > Andy > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/03LLU2p-mvMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 node type - And the rest of Puppet modules Carlos. El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió:> > I''m currently trying to work out the best way structure my Puppet > environments and VCS structure. At the moment I''mk working on > something like this: > > Three Git repositories (one for modules, one for Hiera, one for node > manifests) > Multiple branches (each branch representing an environment, e.g. > production, dev, testing etc.) > > When changes to modules/Hiera are made, the changes will be made to a > testing branch, and then merged up the branches until it hits > production (with the appropriate testing of course). So something like > this: > > unstable > dev > testing > production > > What system do you guys use? Any suggestions about the above workflow? > > Thanks! > > Andy > >El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió:> > I''m currently trying to work out the best way structure my Puppet > environments and VCS structure. At the moment I''mk working on > something like this: > > Three Git repositories (one for modules, one for Hiera, one for node > manifests) > Multiple branches (each branch representing an environment, e.g. > production, dev, testing etc.) > > When changes to modules/Hiera are made, the changes will be made to a > testing branch, and then merged up the branches until it hits > production (with the appropriate testing of course). So something like > this: > > unstable > dev > testing > production > > What system do you guys use? Any suggestions about the above workflow? > > Thanks! > > Andy > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/CGaw2HKh4hMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 once I''ve done step 4, all four branches will be identical. Between each step I''ll be doing extensive testing. I''m also a bit worried about how I''m sacrificing agility with this workflow, unless I''m confident enough with a change that I''ll merge dev/testing/ production with unstable in one go. On May 29, 12:48 pm, Carlos Rico <crico.a...@gmail.com> wrote:> 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 node type > > - And the rest of Puppet modules > > Carlos. > > El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió: > > > > > > > > > > > I''m currently trying to work out the best way structure my Puppet > > environments and VCS structure. At the moment I''mk working on > > something like this: > > > Three Git repositories (one for modules, one for Hiera, one for node > > manifests) > > Multiple branches (each branch representing an environment, e.g. > > production, dev, testing etc.) > > > When changes to modules/Hiera are made, the changes will be made to a > > testing branch, and then merged up the branches until it hits > > production (with the appropriate testing of course). So something like > > this: > > > unstable > dev > testing > production > > > What system do you guys use? Any suggestions about the above workflow? > > > Thanks! > > > Andy > > El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió: > > > > > > > > > > > I''m currently trying to work out the best way structure my Puppet > > environments and VCS structure. At the moment I''mk working on > > something like this: > > > Three Git repositories (one for modules, one for Hiera, one for node > > manifests) > > Multiple branches (each branch representing an environment, e.g. > > production, dev, testing etc.) > > > When changes to modules/Hiera are made, the changes will be made to a > > testing branch, and then merged up the branches until it hits > > production (with the appropriate testing of course). So something like > > this: > > > unstable > dev > testing > production > > > What system do you guys use? Any suggestions about the above workflow? > > > Thanks! > > > Andy-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, May 28, 2012 at 6:14 AM, Andy Taylor <andytayloruk@gmail.com> wrote:> I''m currently trying to work out the best way structure my Puppet > environments and VCS structure. At the moment I''mk working on > something like this: > > Three Git repositories (one for modules, one for Hiera, one for node > manifests) > Multiple branches (each branch representing an environment, e.g. > production, dev, testing etc.) > > When changes to modules/Hiera are made, the changes will be made to a > testing branch, and then merged up the branches until it hits > production (with the appropriate testing of course). So something like > this: > > unstable > dev > testing > production >Do you need a distinction between "unstable" and "dev" ? I''ve often found that I don''t need those to be separate stages.> > What system do you guys use? Any suggestions about the above workflow? > > Thanks! > > Andy > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- Nigel Kersten | http://puppetlabs.com | @nigelkersten Schedule Meetings at: http://tungle.me/nigelkersten -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:> On Mon, May 28, 2012 at 6:14 AM, Andy Taylor <andytaylo...@gmail.com> wrote: > > I''m currently trying to work out the best way structure my Puppet > > environments and VCS structure. At the moment I''mk working on > > something like this: > > > Three Git repositories (one for modules, one for Hiera, one for node > > manifests) > > Multiple branches (each branch representing an environment, e.g. > > production, dev, testing etc.) > > > When changes to modules/Hiera are made, the changes will be made to a > > testing branch, and then merged up the branches until it hits > > production (with the appropriate testing of course). So something like > > this: > > > unstable > dev > testing > production > > Do you need a distinction between "unstable" and "dev" ? I''ve often found > that I don''t need those to be separate stages. > > > > > > > > > > > > > What system do you guys use? Any suggestions about the above workflow? > > > Thanks! > > > Andy > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/puppet-users?hl=en. > > -- > Nigel Kersten |http://puppetlabs.com| @nigelkersten > Schedule Meetings at:http://tungle.me/nigelkersten-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 and pushed. At which point we check for lint or syntax errors as a precaution. Bigger changes are ussually hidden in if/else constructs that allows us to roll them out gradually. this works for us, because: - The development/staging and live environment have a big overlap. - We accept that there might be a few mistakes. It is a tradeoff between rigorous testing and development speed. Jos On Tue, May 29, 2012 at 10:34 PM, Andy Taylor <andytayloruk@gmail.com> wrote:> 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 pm, Nigel Kersten <ni...@puppetlabs.com> wrote: >> On Mon, May 28, 2012 at 6:14 AM, Andy Taylor <andytaylo...@gmail.com> wrote: >> > I''m currently trying to work out the best way structure my Puppet >> > environments and VCS structure. At the moment I''mk working on >> > something like this: >> >> > Three Git repositories (one for modules, one for Hiera, one for node >> > manifests) >> > Multiple branches (each branch representing an environment, e.g. >> > production, dev, testing etc.) >> >> > When changes to modules/Hiera are made, the changes will be made to a >> > testing branch, and then merged up the branches until it hits >> > production (with the appropriate testing of course). So something like >> > this: >> >> > unstable > dev > testing > production >> >> Do you need a distinction between "unstable" and "dev" ? I''ve often found >> that I don''t need those to be separate stages. >> >> >> >> >> >> >> >> >> >> >> >> > What system do you guys use? Any suggestions about the above workflow? >> >> > Thanks! >> >> > Andy >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Puppet Users" group. >> > To post to this group, send email to puppet-users@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-users+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> >http://groups.google.com/group/puppet-users?hl=en. >> >> -- >> Nigel Kersten |http://puppetlabs.com| @nigelkersten >> Schedule Meetings at:http://tungle.me/nigelkersten > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.