In this article we cover:
-
Submitting a Change Request
-
Reviewing a Change Request
-
Approval & Deferral of Change Tickets
-
Implementing a Change Request (Release Management)
-
Releasing and Closing a Change Request
-
Rolling Back a Change Request
Submitting a Change Request
Change requests are to be submitted via a Salesforce feedback ticket by the requester of the change. The requester must specifically answer:
- What is the expected change scope?
- What is the product area impact?
- What is the expected additional testing requirement?
- What is the expected time scale?
- What is the urgency?
- What are the security implications?
- Is there an impact on Personally Identifiable Information (PII)?
Submitted change requests are considered change tickets and assigned an identifiable number for simple tracking and management.
Prior to operating on any change ticket, a thorough review must be conducted by a senior Visor staff member.
Reviewing a Change Request
New change tickets are reviewed daily by a senior Visor staff member, known as the reviewer. The reviewer must ensure the accuracy of the change ticket and dependencies involved. Change tickets that are agreed to by a reviewer are motioned for approval and prioritization.
Approval & Deferral of Change Tickets
Authorization of a change ticket occurs after a successful review. Approval and change timing is mandated by the following table:
| Change Ticket Type | Description | Approval Required? |
|---|---|---|
|
Standard
|
This change occurs regularly, and considered routine to Visor operating procedures. The change scope is pre-defined according to a template.
|
No. These changes bypass the approval process as all dependencies are tested. These processes are critical to Visor development and maintenance.
|
|
Minor
|
This change occurs infrequently, and is usually in response to a feature request. Depending on the change scope, minor change tickets can be escalated for quick implementation.
|
Yes. All implemented changes must be tested and reviewed prior to deployment.
|
|
Urgent
|
This change is usually in response to a production failure, or security vulnerability that must be resolved to continue effective business operation. Depending on the change scope, urgent change tickets can be escalated for quick implementation.
|
Yes. A follow up Post-Mortem meeting is mandated once the Change Ticket is resolved to ensure all processes were followed.
|
Change tickets that are not approved according to the table above should not be implemented until a successful review and approval. Tickets that are not approved should only remain so for a maximum of 1 week. If the ticket cannot be approved in that time, it is deferred.
Implementing a Change Request (Release Management)
Approved change tickets are implemented according to the change scope and implementation requirements. Change tickets are assigned to an implementer, who is responsible for seeing the changes through to completion. All changes must be tested and reviewed as defined in the table below:
| Implementation Review Process | Description | Acceptance Criteria |
|---|---|---|
|
Code Review
|
A thorough review of the specific changes is conducted by someone other than the implementer.
|
Code is successfully reviewed and approved within Visor’s Source Code Management system. All code testing requirements are met. All code changes pass Visor’s automated CI/CD pipeline requirements.
|
|
Quality Assurance and Stability Review
|
An end-to-end product review is conducted in a pre-production environment by someone other than the implementer.
|
Product stability and integrity is maintained. The change is successfully implemented according to the acceptance criteria of the original change ticket. All changes pass Visor’s automated CI/CD pipeline requirements.
|
|
Security Review
|
A thorough review of the potential vulnerabilities resulting from the change is conducted by a member of the VSC.
|
Product security is maintained.
|
Once all implementation reviews are met, the change ticket becomes part of a production release candidate build.
Releasing and Closing a Change Request
Change tickets should only be deployed to production environments as part of a production release candidate build. Production release candidate builds are marked with a unique identification hash for simple reference and audit purposes. All change tickets involved are listed in the description of the production release candidate build. Production release candidate builds must receive approval from the VSC prior to deployment, and must follow Visor’s automated CI/CD pipeline to get to production system. Corresponding change tickets are closed once the production release candidate build tests successfully on production systems.
Rolling Back a Change Request
Change tickets can only be rolled back if it is closed and already deployed in production. Rolling back procedures are outlined in below:
- Revert Procedure
- Rolling back the change ticket is as simple as rolling back the latest production release candidate build. Since all candidate builds are uniquely hashed, production environments revert to the previous candidate build hash.
- Approval is required. A member of the VSC must approve the production system rollback.
- A Post-Mortem meeting must be scheduled.
- Revert and Redeploy Procedure
- Rolling back the change ticket involves creating a new release candidate without the change ticket in question. This process involves rebuilding a new production release candidate build, which must follow all previously identified procedures, including testing, QA, and security requirements.
- Approval is required. All peer review processes must be followed.
- A Post-Mortem meeting must be scheduled.