Ballpark's software development methodology is one of continuous delivery, whereby changes in the service are released to production incrementally and often. As such, change management must be realised in such a way as to support this methodology.
The primary tool used to record and manage changes shall be Github, where these changes take the form of pull requests. Any exceptions, such as non-code changes that can only be made manually, must be recorded and managed in JIRA, Ballpark's ticketing system.
Types of Change
The changes made to Ballpark's service must be categorised as one of the following.
These are changes that are deployed on a daily basis and are subject to standard rollback
procedures that allow engineers to revert a change instantly if there is an issue
Bug fix: a change that fixes behaviour
Feature: any change that is not a bug fix
Refactor: a change to internal structure that does not modify external behaviour
Chore: any change that doesn't involve modification of software e.g. README updates.
- Major change: any change that alters a significant part of the system and requires robust
planning with rollback procedures. This must be a scheduled change if affecting customer
SLAs with regard to potential maintenance on the system. These changes shall only be
carried out outside of business hours and at the weekend. Examples of this are
- Database migration
- Infrastructure change (network, load balancer, firewall)
Emergency changes: Any change that is unplanned and is due to an unscheduled outage
(server crash or infrastructure failure). As such any changes implemented to solve the
issue shall be logged retrospectively.
Breaking and Deprecated Changes
In the event that a feature on our API is due to be removed it will initially be marked as
deprecated. The period of deprecation of the feature will be monitored unto such time as the
feature is no longer in use via our customers and they have been notified of its removal and they
have moved to an alternative means of using the feature.
Every pull request or similar proposed manual change must document the following in the appropriate tool (see Tools above) before it is reviewed.
- Has the change been appropriately categorised (see Types of Change above)?
- Summarise the change.
- Describe the changes made in more detail.
- Illustrate the changes visually, if appropriate (typically front end changes).
- How will the changes be tested?
- What is the assessed risk of this change?
Proposed changes must undergo peer review by at least one other suitably qualified and experienced engineer before being submitted for Quality Assurance (QA).
For a bug, feature and main application change the authority to deploy a reviewed and QA’d change shall be limited to QA Engineers or, in the case of an emergency, a Senior Engineer.
For operational, infrastructure and security changes deployment of a reviewed and approved change will be conducted by the Security and Operations team.
In the event of an issue due to the release of a bug, release, refactored change the rollback procedures will be to revert the change on the codebase and initiate a rollback release. Rollback procedures can be operated by the QA Engineer or Senior Engineer who initiated the deployment.
Rollback plans for major outages must be prepared and available at the point of implementing the change. In the event of a problem with the major outage rollback procedures must be enacted by the Engineer responsible.
Ballpark's CTO, Brendan Moore, has overall responsibility for this change management policy and for ensuring that it remains up to date and relevant.
All staff who author, review or deploy changes to Ballpark's applications, systems or service are responsible for following this change management policy.
Author: Kelsey Traher, COO
Date of change: May 2022
Summary of changes: Reviewed for accuracy
Author: Davie Quinlan, Security Consultant
Date of change: Mar 2020
Summary of changes: Initial formalised policy document