ChangeManagementPolicy

Change Management Policy

Last updated: January 20, 2023

Introduction

This policy outlines the principles we apply to handle any changes regarding software changes, and production environment changes, with the aim of doing so safely, effectively and efficiently. In other words, these guidelines help us reduce the risk of experiencing platform or application instability and increase the predictability and reproducibility of the change management process.

This policy covers all systems within Zora Communications production environment. The production environment includes all endpoints and cloud assets used in hosting Zora Communications and its subdomains. This doesn't include third-party systems that support in the scope systems of Zora Communications

Our change management is underpinned by trust: we trust ourselves to act responsibly when working in the operational environment and do everything in our power to safeguard its integrity and maintain its availability and performance. To that end, we must develop a practice that allows for safe changes. Our highest priority is always the integrity and reliability of the operational environment, which entails appropriate risk evaluation, quantifiable validation and verification, extensive communication, detailed auditing, and a focus on defensive coding.

All software developed in the service of Zora Communications, or any subdomain of Zora Communications Limited should be version controlled i.e the latest version of our software as well as any previous version of our software are readily available. We use a decentralized version control system like Git. This allows engineers to work on bug fixes, new feature development and other independent projects simultaneously. Before synchronising with the central repository, it is recommended that engineers work on local branches created from an appropriate version of the central repository. All changes must be tested locally before the changes are deployed to users.

While developing new features in Zora Communications, it is recommended to start a new feature branch in Git. All requirements and specifications of a feature may not be known at the beginning of the development of the feature. One can create new branches off the feature branch to develop sub-features as necessary. Most feature branches exist on the local systems of developers working on the feature. They need not be synced with the central, company-wide, repository. However, when a feature is considered ready to be used by customers, a pull request is created. Any developer or software engineer can initiate a pull request.

A pull request outlines the differences in code that this feature proposes. A pull request must be reviewed by other peer developers or managers. All pull requests should be reviewed and approved by someone who is not the author of the changes. It is recommended (but not necessary) that a pull request be reviewed by someone who has expertise in the area where the changes are proposed. Some automated triggers, like tests, can be integrated with pull requests. That is, a pull request might automatically prompt an automated set of tests to run on the changed code, indicating whether it passes some basic safety checks. Other such checks might include code-quality, code linting, or code style checks or even manual testing. Results of such checks are recommended to be logged by the change management system. Before approving and merging a pull-request, the reviewer checks that all prerequisites are met. Typical checks that the reviewer is encouraged to perform are listed below. Not all items in the list are necessary (depending on the type of change), nor is the list exhaustive. Please use your judgement to determine what is necessary, depending on the change at hand:

Does the proposed change solve the problem it set out to solve?
Are all requirements of solving the problem met?
If not, were reasonable trade-offs made?
Are there any unintended consequences of this change to other parts of the system?
Does the change adversely affect any related or unrelated user experience?
Does the proposed change require changes in the environment itself (like adding production environment variables etc).
Could the change create performance issues for itself (or other parts of the system)?
Could the proposed change be achieved in a more extensible, robust, or less disruptive way?

Sometimes, it becomes necessary to apply unplanned changes, like hotfixes, to the production system in order to maintain Zora Communication's operational effectiveness. This is usually done to address a situation where the production system is in an undesired state - either from a customer-experience standpoint (like critical bugs, system-down etc) or from a security standpoint.
In such cases, we can create changes in a new branch. For all such cases, the commit and/or pull-request messages should detail the nature of the issue being fixed as a result of this change. Unplanned changes follow the same process as planned changes (at least one review or approval from someone who is not the author of the change). Since we use a version control system, emergency changes can be rolled back if it has unintended or undesirable consequences.

Compliance with this policy will be verified through various methods, including but not limited to, automated reporting, audits, and feedback to the policy owner.
Any staff member found to be in violation of this policy may be subject to disciplinary action, up to and including termination of employment, or contractual agreement. The action will depend on the extent, intent, and repercussions of the specific violation(s).