We use a similar workflow except that our stage and prod branches are separate branches, and are never merged into each other. We reduce the code duplication from this by using a separate puppet module repo where we store all puppet code not specific to a single environment.
On Saturday, December 23, 2017 at 3:05:25 PM UTC-8, Lupin Deterd wrote: > > Hi, > > What is the work-flow of you Control-repo? We are using single repo with > multiple(DEV, QA, PROD) branches which r10k map to Puppet environment. > Below is our workflow process: > > 1) A team member creates a feature branch from Prod. > 2) After completing their changes they will then merge it into Dev branch. > 3) Dev branch undergoes testing and then deployment. > 4) After some time, changes in Dev eventually promoted to QA, PROD. > > 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. > > Lupin > -- 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/db662ea3-9864-4912-bf94-b16a2cb93324%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
