Software Development Lifecycle

Continuous Delivery

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.

Tools

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.

Continuous delivery

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.

Planned changes

• 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)

Unplanned changes

• 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.

Proposed change

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?

Change Review

Proposed changes must undergo peer review by at least one other suitably qualified and experienced engineer before being submitted for Quality Assurance (QA).

Deployment Authority

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.

Rollback Procedures

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.

Responsibilities

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.

Revision History