1. Purpose
This process defines how significant code changes are reviewed, approved, and deployed within Vertuna to reduce the risk of defects, security issues, or unintended impact on production systems.
2. Scope
This process applies to all significant code changes affecting:
Production systems
Security-related functionality
Data handling, authentication, authorization, or encryption
Infrastructure-as-code or deployment logic
Public APIs or customer-facing behavior
Minor or low-risk changes (e.g., documentation updates, non-functional refactoring) may follow a simplified review path at the discretion of the Engineering Lead.
3. Definition of “Significant Code Change”
A code change is considered significant if it meets any of the following criteria:
Impacts production behavior or availability
Modifies security controls, authentication, authorization, or encryption
Changes how customer or sensitive data is processed or stored
Introduces new dependencies or major version upgrades
Alters API contracts or externally visible behavior
Requires database schema changes or data migration
Addresses a high or critical vulnerability
4. Roles & Responsibilities
Change Author
Prepares the code change
Ensures adequate testing
Documents the intent, scope, and risk of the change
Reviewer (Peer Engineer)
Reviews the code for correctness, security, and maintainability
Confirms tests and scans have passed
Provides approval or requests changes
Engineering Lead
Provides final approval for significant or high-risk changes
Ensures process compliance
Authorizes production deployment when required
5. Process Steps
Step 1: Change Preparation
Code is developed in a non-production environment
Automated checks are executed, including:
Build validation
Unit/integration tests (where applicable)
Static analysis and dependency scanning
The change author prepares a pull request (PR) describing:
Purpose of the change
Impacted components
Risk level (low / medium / high)
Rollback considerations (if applicable)
Step 2: Peer Review
At least one qualified peer engineer must review the change
Review must cover:
Code quality and correctness
Security implications
Compliance with internal standards
Test coverage adequacy
Review feedback must be addressed before approval
Step 3: Approval
Medium-risk changes require:
Peer approval
Significant or high-risk changes require:
Peer approval and
Explicit approval from the Engineering Lead
Approvals are recorded via the version control system (e.g., pull request approval)
Step 4: Deployment
Approved changes are deployed using controlled deployment mechanisms
Only authorized personnel may deploy to production
Deployment should follow established release procedures
Step 5: Post-Deployment Validation
Production systems are monitored after deployment
Any unexpected behavior is investigated immediately
Rollback procedures are executed if required
6. Emergency Changes
In case of urgent security fixes or production incidents:
Changes may be fast-tracked with Engineering Lead approval
Peer review may occur after deployment if time-critical
Emergency changes must be documented and retrospectively reviewed
7. Evidence & Record Keeping
The following artifacts serve as evidence of compliance:
Pull request descriptions
Code review comments and approvals
Automated test and scan results
Deployment logs (where available)
8. Review & Maintenance
This process is reviewed:
At least annually, or
Following a significant incident or system change
9. Ownership
Process Owner: Engineering Lead
Approved By: Company Leadership
Version: 1.0
- Last review: