Change Management

What you need to know

• Access to GitHub is limited, by roles, to appropriate Zendesk Personnel.

• GitHub functions as a repository for all source code changes, and includes documentation for each change, including a date stamp and indication of the engineer responsible for making the change. 

• Separate environments (branches) have been created within GitHub such that code is not modified directly in production.

• All engineers branch code using pull requests. Each pull request requires an authorization in the form of a +1 in order to merge the branch back into the Master. This authorization, and other development and requirements comments, are stored within GitHub.

• All deploys, regardless of their frequency, or team, must successfully undergo automated testing prior to being merged to staging or production. 

• The majority of code is pushed to production through a weekly deploy (release train). Additionally, emergency hot fixes, patches, or minor changes are deployed in between the scheduled weekly deploys, as necessary. 

• Deploys are accomplished by pushing the deploy from the deploy tool, Samson, only after a peer-approval or a “buddy” has also approved that the deploy be pushed to production.  Bypassing the buddy approval is possible, only in cases of an emergency bug fix, and a post approval is required within 1 business day.

• Emergency changes require that there is clear documentation that designates these changes as emergency changes by the use of the capitalized term EMERGENCY CHANGE in the GitHub comment log.

• Avoid using customer data to perform testing.