Updating...
Skip to main content
Filter your search by category. Current category:
All
All
Knowledge Base
Service Catalog
Search the client portal
Search
Sign In
Show Applications Menu
IT
Sign In
Search
Help
Services
Knowledge Base
More Applications
Skip to Knowledge Base content
Search
Articles
Blank
Knowledge Base
University Development Environment
GitLab
Support Guide: GitLab / Daily projects merge schedule
Support Guide: GitLab / Daily projects merge schedule
Purpose
To explain the daily merge schedule managed by the EO Linux team for the most used GitLab projects
Users
Application Operations
Myaamia Center
Solution Delivery
University Libraries
Environment
1068805: GitLab (SaaS)
127027: Amazon Web Services (AWS)
711178: Elastic Kubernetes Service (EKS)
Important items to consider
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
Guide
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:
Puppet
terraform-aws
terraform-kubernetes
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
Sign in to leave feedback
0 reviews
Blank
Blank
Blank
Blank
Print Article
Deleting...
×
Share
Recipient(s)
- separate email addresses with a comma
Message
Press Alt + 0 within the editor to access accessibility instructions, or press Alt + F10 to access the menu.
Check out this article I found in the IT knowledge base.<br /><br /><a href="https://miamioh.teamdynamix.com/TDClient/1813/Portal/KB/ArticleDet?ID=150929">https://miamioh.teamdynamix.com/TDClient/1813/Portal/KB/ArticleDet?ID=150929</a><br /><br />Support Guide: GitLab / Daily projects merge schedule