production-like environments are formal lanes of code that an organization can expect to retrieve and get a stable code set for individual Puppet agents. When I work with organizations setting these up for the first time, I often describe them as, any environment you may be called in to work on if it goes down on nights or weekends. An organization may have a dev environment, but if it requires support from an infrastructure team to maintain, that environment should be treated like a production environment. Any environment meant to be used daily by another group in an organization should be controlled more tightly than non-production-like environments.

A few key points on managing production-like branches are as follows:

• If you're strong in CI/CD and deploying code to production often, deploy your modules by branch
• If you're deploying updates in regular cycles (such as quarterly), deploy your modules by tag, as a version number
• Make these branches protected branches in your Git repository
• Decide on an organizational RBAC and governance policy

More information on deploying modules via tags and branches will be covered in the Puppetfile section of this chapter. 

If you're using a hosted Git solution, such as Bitbucket, GitLab, or GitHub, enable protected branches on production-like branches in the control repository. Protected branches ensure that only elevated administrator accounts can push directly to the branch or approve merge requests generated from other branches. This ensures that code is peer reviewed before being accepted into these controlled environments.

An organization should decide on an RBAC and governance policy surrounding these protected branches, and should select technical people to review code and formally accept code into these production-like environments. Like an open source project, this allows any member of an organization to recommend a change to a controlled environment via Git, but requires a trusted individual to accept this code into the controlled code base.

non-production-like environments, on the other hand, require significantly less management, and can be used to test new features before merging code into environments that support direct business needs.