This change management policy intends to ensure changes made to application code and relevant systems are subject to necessary and appropriate controls. Its purpose is threefold:
This policy covers:
The following roles are defined:
GitHub repositories containing application code, as defined in Scope Item 1, must use GitHub’s “Branch Protection” feature to mark the repository’s base branch, and any other branches to be released for end-user consumption, as protected. These protected branches prevent direct, unreviewed modification by engineers.
As a result, any changes to protected branches must first be submitted for review through GitHub’s “Pull Request” system. Each pull request must be approved by another engineer before it can be merged into a protected branch.
When reviewing code, engineers should consider:
In emergency situations, on a case-by-case basis, a repository administrator may elect to bypass the usual pull request review process. Such cases shall be reported to the Information Security Manager for further review.
GitHub and CodeCommit repositories containing “Infrastructure as Code”, as defined in Scope Item 2, must similarly have one or more protected branches preventing users from directly making changes.
Changes to these repositories must also be submitted for review through the repository “Pull Request” system. These changes must be reviewed by at least one other Team Member before being merged into a protected branch.
However, to promote expediency of changes, a Cloud Architect may short-circuit the review process and deploy changes in an unprotected, submitted-for-review branch.
Infrastructure as Code changes may be deployed using the unprotected, submitted-for-review branch if one of the following conditions is met:
Otherwise, the change must be submitted for review, approved by another Cloud Architect, then merged into the relevant protected branch for deployment.
For clarity, this situation requires review before deployment, as per the above rules:
Any changes short-circuiting review before deployment must eventually be reviewed and merged into the relevant protected branch of the repository. This review, though often cursory for changes, still meets the objectives of promoting change awareness and providing a record of change.
Changes to Breezy ATS environment configurations for production systems should typically be driven by a specific customer (internal or external) or a customer support request.
Application and infrastructure code, i.e. Scope Items 1 and 2, cover the majority of changes relevant to the proper operation of Breezy systems.
Scope Item 3 is broad. It is intended to cover both manual changes to systems normally controlled by “Infrastructure as Code” definitions, like Amazon Web Services (AWS) changes, as well as changes to supporting systems like third-party status pages, monitoring systems, etc.
Generally speaking, Breezy strives to define infrastructure and applications in code whenever reasonable, using the longevity and severity of systems and changes as guides. However, for some systems, particularly third-party systems, it’s simply most realistic to manually set up or change them.
In these cases, intended to be covered by Scope Item 3, we use the following guidelines when making changes:
If there is reasonable chance a change may directly affect customer or production systems or data, the change should be supervised by at least one other employee of Breezy HR. This supervising employee should have the knowledge and context necessary to understand and evaluate the change in question, or the employee should refuse to sign off on the change without first acquiring the knowledge and context. This supervision might take the form of watching over someone’s shoulder, viewing a screen-share on a remote call, describing the change through instant messaging, or even approving a pull request prior to the change’s deployment, as the situation warrants.
When in doubt, employees should err toward having another person sign off on their changes.