Doug, If all your git repositories are local filestores, that's probably a pretty reasonable workflow. However, most people use some form of dedicated service as their git origins, that reside external to the local systems - GitHub, Bit Bucket, Git Lab, etc. If you are using one of those systems, or you can migrate to it, you can then improve your code flow by using pull requests to review changes and merge them into the branch at the upstream. These services would also be able to fire a web hook, an event sent to your puppet master as an http/https payload, that can trigger r10k to deploy the updated code.
That might sound complicated, but I promise you, it's not. It's just using some peculiar terminology you're not familiar with. For learning git and services like GitHub, there are countless tutorials out there; I recommend https://github.com/commitmas/12-days-of-commitmas. That will introduce you to git, GitHub, Pull Requests (PRs), and code review processes. I wrote an article on using r10k with a webhook at https://rnelson0.com/2015/05/03/configuring-an-r10k-webhook-on-your-puppet-master/, and I and others have tons of articles about using r10k. With this in place, your process would be a little simpler: git commit -am 'Something I want to push to test' git push origin test_change <open a PR from test_change to test, merge> The webhook fires, r10k starts deploying code, and in a few seconds to minutes, your test environment has been updated to incorporate those changes. You'd then use PRs to promote code from test -> dev -> qa -> uat -> production. This has other impacts to your workflow, of course, and you may actually be able to remove a level of environments (feature -> qa -> uat -> production). You could later add some continuous integration tests to your code, that are automatically run by GitHub/GitLab/Jenkins/etc, which could lead to removing the qa level as well. But that's down the road a bit. There is a lot of room for improvement here as you have time to focus on your pipeline. Rob Nelson rnels...@gmail.com On Wed, May 18, 2016 at 9:02 PM, dkoleary <dkole...@olearycomputers.com> wrote: > Hey; > > To put this in perspective, I'm a sysadmin, not a developer. While I've > used git for a couple of years, until today, I could easily count the > number of times I issued a 'git branch' command. > > I'm practicing setting up a new puppet 4 server and, after some research, > I've got various environments under git management and have successfully > 'promoted code' from test through production. It's a wee bit tedious but > I'm sure I could get used to it. > > What I'm hoping is to have someone more familiar the process verify I'm > doing it somewhat close to right and/or make suggestions on an > improvements. I have heard of r10k; however, I'm one of those that has to > know what's going on under the covers. Up until now, r10k has been of of > those 'developer' things. Once I run through this a few times, *then* I'll > start playing with r10k. > > So, bit of a build up. Here's what I have: > > one git repo covering all puppet environments thusly:: > > # git branch -r > origin/HEAD -> origin/master > origin/dev > origin/master > origin/prod > origin/qa > origin/test > origin/uat > > On a different system, one pulls the test system, develops code, commits, > pushes, etc. In the test environment, the admin pulls the updated work and > tests > > # pwd > /etc/puppetlabs/code/environments/test > # git branch > * test > > once the tests are complete, a responsible admin accesses the dev > environment and executes: > > git checkout test > git pull # if necessary > git checkout dev > git merge test > > Process iterates through the environments to prod. > > # git log --oneline > e298de7 prod.rst: mved from uat > 07f3ab1 uat: merged from qa > a20a85c qa: mved from dev > 2f644f2 dev: renamed from test > c8c067b test: added > a432124 puppet production environment initial check in > > Thanks for any hints/tips/suggestion. > > Doug O'Leary > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/729cd1f2-2828-4d46-b008-2e0033fed34d%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/729cd1f2-2828-4d46-b008-2e0033fed34d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAC76iT_LczDuGm1kdJ-bmm11sM2ib%2BNbaHSvqqUOc34jj5C%2BTQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
