Support Guide: GitLab / Daily projects merge schedule

Body

To explain the daily merge schedule managed by the EO Linux team for the most used GitLab projects

The person who initiates the Merge Request is responsible for taking care of change control. That is, if you feel that your code is not ready for the targeted environment — development, test, or production — then do not ask for it to be merged. Failure to ensure your code's readiness can result in blocked changes and fixes for other code, as well as unnecessary downtime to production systems
Readiness of code changes also applies to periods of High Review. The daily merge schedule does not stop during High Review, so the person initiating a Merge Request around this time should take extra precautions to ensure their changes do not result in disruption to production systems and acquire appropriate approval from CAB or the LT prior to merging

The Linux team has responsibility for moving changes through environments each weekday morning around 9:00am, according to the environment branches with GitLab flow in general, and specifically our Puppet workflow. Projects include:
The purpose is to keep code changes moving through our server environment and give a concrete time from merging a branch to Master and the deployment of the code change into Test and Production. The merge schedule is as follows:
- Test –> Production
- Master –> Test
The Linux team will start with a merge of Test to Production, and then merge Master to Test around 9am each weekday. This order is to ensure that changes stay in Test for at least 24 hours before making its way to Production
Emergency changes to Production (less than 48 hours) will be handled on a case-by-case basis, but should be avoided. Contact the Linux Team via the #enterpriseops channel on Slack for help with this
Merges to other branches (Account, Operations, Shared Services, etc.) will be done less frequently, or more as needed
For further information on merge schedules, see the following:
- Puppet
- terraform-aws