Change Management

This page outlines the principles we apply when making changes to our IT operational environments. Our aim is to make changes safely, effectively, and efficiently, reducing the risk of platform or application instability and increasing the predictability and reproducibility of the change process.

Scope

These principles cover all systems within our environment, including the endpoints and cloud assets used in hosting our service and their subdomains. They do not cover third-party systems that support the business of Risely.

Trust

Our change management is underpinned by trust. We trust ourselves to act responsibly when working in the operational environment and to do everything in our power to safeguard its integrity and maintain its availability and performance. Our highest priority is always the integrity and reliability of the operational environment, which involves appropriate risk evaluation, quantifiable validation and verification, extensive communication, detailed auditing, and a focus on defensive coding.

Version control

All software developed for Risely’s offering is version-controlled, so that the latest version and any previous version are readily available. We use a decentralized version control system such as git, which allows engineers to work on bug fixes, new features, and other independent projects at the same time. Engineers work on local copies created from an appropriate version of the central repository, and all changes are tested before they are deployed to users.

Initiating planned changes

When working on a change, an engineer starts a new feature branch. Because not all requirements of a feature are known at the outset, new branches can be created off the feature branch to develop sub-features as needed. Feature branches often exist only on the local systems of the developers working on them and need not be synced with the central repository right away. When a feature is ready to be used by customers, a pull request is created. Any developer or software engineer can initiate a pull request.

Approving planned changes

A pull request outlines the code differences that the change proposes. All pull requests are reviewed and approved by someone other than the author, ideally someone with expertise in the area being changed. Automated triggers, such as unit tests, are integrated with pull requests, and other checks may include code quality, linting, and style checks; the results of these checks are logged. Before approving and merging a pull request, the reviewer confirms that the relevant prerequisites are met. Depending on the type of change, typical checks include:

• Does the change solve the problem it set out to solve, and are the requirements met or reasonable trade-offs made?
• Are there any unintended consequences to other parts of the system?
• Does the change adversely affect any related or unrelated user experience?
• Are there any algorithmic or logical errors in the change?
• Does the change require changes to the environment itself, such as new production environment variables?
• Could the change create performance issues for itself or other parts of the system?
• Could the change be achieved in a more extensible, robust, or less disruptive way?
• Does the change introduce any security vulnerabilities?

Unplanned changes

Sometimes an unplanned change, such as a hotfix, is needed to maintain Risely’s operational effectiveness, usually to address a situation where the production system is in an undesired state from either a customer-experience standpoint (such as critical bugs or a system outage) or a security standpoint. Depending on the urgency, an unplanned change may skip peer review before deployment and is then peer-reviewed after the fact. Because we use a version control system, emergency changes can be rolled back if they have unintended or undesirable consequences.

Questions

If you have any questions about this policy, contact us at [email protected].