On 12/24/2017 12:05 AM, Lupin Deterd wrote: > This works initially when it was only one team doing the work/changes > but after opening the work to other teams (apps) it becomes unwieldy. > The pain point happens in #2, #3 where some changes have to wait for a > schedule before it's get promoted to PROD. Some people have urgent > changes which mean there is a long list of changes in DEV which are not > in PROD. > > > I really interested to learn your environment work and if there's a > documentation you can point, it would be greatly appreciated.
Hi I recently ran into the same problem when working for a customer. So far Puppet was only used in the platform team which delivered a base profile and some basic roles. The dev->nonprod->prod release life-cycle is guided by a weekly review board in which ops has the final word on what merge requests get trough and rolled out how fast to what environments. So this would be a huge blocker for the applications guys if they had to go trough the same procedure and would become a mess for ops as well. To solve this we did something I call environment overlay. Each application can onboard their own control repo (we obviously automated this with Puppet ) and have their own release life-cycle. The deploy script on the Puppet Master will then deploy them into environments with the convention dev_<appid>, nonprod_<appid> and prod_<appid>. The trick is then to also add the "base" environment dev/nonprod/prod modules in the environment.conf to the modulepath which then includes (for dev): modulepath=/etc/puppetlabs/code/environments/dev/modules:/etc/puppetlabs/code/environments/dev_myapp/modules Also the default manifest then makes sure the base profile is always included. Then there is a custom ENC indirector (although a normal script would probably work as well) which checks for each node what original base enviornment it has and which appid and then if there is a valid enivironment for that combination it will overwrite the environment with that appid-env. Example: The node has env "dev" and appid "myapp". If there is an environment dev_myapp on the puppetmaster it will set the environment to dev_myapp, if not to dev. This also has the additional benefit that the stuff the "myapp" dudes are rolling out to their environments have no impact on stuff the "thatotherapp" dudes are doing, since their code is only used by their nodes and not visible from other apps. Maybe there are some other, better ways to do this. But so far I have not seen anyone doing anything similar and write about it. Regards Andreas -- 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/6db5da44-0f2f-26f3-6cb4-d24daea01f6f%40puzzle.ch. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
