Hi, I would like to know how your workflow looks like when you''re writing manifests. Currently we have the following construct: * 1 git repository with all modules * 3 git branches: dev, staging, prod * 3 puppet environments: dev, staging, prod The modulepath of each environment is a checkout of the corresponding branch. Writing/Editing manifests only happens in dev. If you''re done you commit your work to a central repo. If dev is somewhat stable it is merged into staging (fast-forward-merge) etc. This comes with a few problems: * If all your systems are running prod and you change something big (e.g. new filesystem layout) you only have too options: Change all your machines to follow the new standard or take the machines you cannot change out of puppet control. * There are changes I make in dev that I want to take immediate effect. Example: Deploy the SSH-Key of a new employee to all machines. I can add the key in dev and then cherry-pick the commit in the other branches but I''m not yet sure if that is really a good idea. So how do you use environments and branches? One Repository for each module or one repository for all modules? Do you use git tag to tag certain revisions? Do you run your servers agains different "releases" of your manifests or do you just have one "prod" environment? -Stefan
We have a single master branch and then check various branches out into dev. I wrote up an article about how our env works a few months back. It may be useful to look at. https://cwebber.ucr.edu/2011/03/multiple-environments-in-puppet/ My guess is that eventually we will have multiple dev environments to allow different things to go on at once. --cwebber On 5/3/11 9:16 AM, "Stefan Schulte" <stefan.schulte@taunusstein.net> wrote:>Hi, > >I would like to know how your workflow looks like when you''re writing >manifests. Currently we have the following construct: > >* 1 git repository with all modules >* 3 git branches: dev, staging, prod >* 3 puppet environments: dev, staging, prod > >The modulepath of each environment is a checkout of the corresponding >branch. Writing/Editing manifests only happens in dev. If you''re done >you commit your work to a central repo. If dev is somewhat stable >it is merged into staging (fast-forward-merge) etc. > >This comes with a few problems: >* If all your systems are running prod and you change something big > (e.g. new filesystem layout) you only have too options: Change all your > machines to follow the new standard or take the machines you cannot > change out of puppet control. >* There are changes I make in dev that I want to take immediate effect. > Example: Deploy the SSH-Key of a new employee to all machines. I can > add the key in dev and then cherry-pick the commit in the other > branches but I''m not yet sure if that is really a good idea. > >So how do you use environments and branches? One Repository for each >module or one repository for all modules? Do you use git tag to tag >certain revisions? Do you run your servers agains different "releases" of >your manifests or do you just have one "prod" environment? > >-Stefan-- 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 05/03/2011 09:16 AM, Stefan Schulte wrote:> Hi, > > I would like to know how your workflow looks like when you''re writing > manifests. Currently we have the following construct: > > * 1 git repository with all modules > * 3 git branches: dev, staging, prod > * 3 puppet environments: dev, staging, prod > > The modulepath of each environment is a checkout of the corresponding > branch. Writing/Editing manifests only happens in dev. If you''re done > you commit your work to a central repo. If dev is somewhat stable > it is merged into staging (fast-forward-merge) etc. > > This comes with a few problems: > * If all your systems are running prod and you change something big > (e.g. new filesystem layout) you only have too options: Change all your > machines to follow the new standard or take the machines you cannot > change out of puppet control. > * There are changes I make in dev that I want to take immediate effect. > Example: Deploy the SSH-Key of a new employee to all machines. I can > add the key in dev and then cherry-pick the commit in the other > branches but I''m not yet sure if that is really a good idea. > > So how do you use environments and branches? One Repository for each > module or one repository for all modules? Do you use git tag to tag > certain revisions? Do you run your servers agains different "releases" of > your manifests or do you just have one "prod" environment? >I''d recommend one repository per module. I don''t use tags at all. Changes are introduced into the development branch and get merged into the production branch. Differences between servers are typically handled within the module classes (i.e. subclass/conditionals/selectors) rather than having them run against different versions of the module. I can''t see how you could keep a sane environment otherwise. -- Russell A Jackson <raj@csub.edu> Network Analyst California State University, Bakersfield -- 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 Tue, May 3, 2011 at 9:46 PM, Stefan Schulte < stefan.schulte@taunusstein.net> wrote:> So how do you use environments and branches? >It should be worth looking at http://hunnur.com/blog/2010/10/dynamic-git-branch-puppet-environments/ . Very flexible and useful approach. -- 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.