Change & Release Management | Overview.

An Overview of Change & Release Management

Focus:

• Tailored for SRE, DevOps, Cloud, and DevSecOps Engineers

Breakdown:

• Intro,
• Change Management,
• Key aspects include of Change Management,
• Release Management,
• Key aspects include Release Management,
• The Relationship between Change & Release Management,
• Definition & Focus,
• Key Differences,
• How They Work Together,
• Backup procedures before a new Release,
• Best Practices for Backups Before Releases.

Intro:

• Change & Release Management are two distinct but closely related IT Service Management (ITSM) practices. 
• Change & Release Management both ensure new or modified services are delivered to users with minimal disruption to business operations.

Change Management

• Change management is the process of justifying what changes  should happen, why they should happen, and when they should be implemented, to minimize risk to the business. 
• It acts as a gatekeeper to protect the production environment and involves assessing, prioritizing, scheduling, and authorizing all modifications to a managed IT environment.

Key aspects include:

Scope:

•  Concerned with the entire service portfolio and all configuration items (hardware, software, network, documentation).

Purpose: 

• To manage and reduce the risk associated with changes, preventing unintended consequences or service interruptions.

Process: 

• Often involves a Change Advisory Board (CAB) that reviews and approves change requests.

Types of Changes: 

• Can be classified as normal, standard, or emergency changes, each with different approval procedures.

Release Management

• Release management focuses on the logistics and execution (how) of deploying approved changes into the live production environment. 
• Release management is the process that gets completed code or a service from development to the customer, ensuring it is built, tested, and implemented in a coordinated and efficient manner.
• Change Management = "Should we make this change?"... Justify.
• Release Management = "How do we safely deploy this change?"... Execute.

Key aspects include:

Scope:

•  Deals primarily with the specific software or service components being updated or deployed.

Purpose:

•  To plan, schedule, and control the movement of releases to testing and live environments, making sure all components work together as expected.

Process:

•  Includes planning the release schedule, building and testing the release package, and coordinating the actual deployment.

Coordination:

•  Ensures alignment among development, operations, and business stakeholders during execution. 

The Relationship between Change & Release Management

• While distinct, change and release management are highly integrated and support each other. 
• A release usually contains one or more changes, and every change that touches the live environment must go through the change management process for authorization.
• Change management is the 'governance' and 'strategy' (justification) for what is approved to go live.
• Release management is the 'operations' and 'delivery' of that approved content.
• By working in sync, organizations can move quickly without constant firefighting, reducing downtime, improving efficiency, and ensuring operational stability.
• Understanding the difference between Change Management and Release Management,  is crucial for ensuring smooth deployments, minimizing risk, and maintaining system reliability. Here’s how they differ:

1. Definition & Focus

• Change Management focuses on evaluating, approving, and controlling changes in the IT environment to minimize risks and disruptions.
• Release Management is about planning, scheduling, and deploying software or infrastructure changes in a controlled manner.

Aspect		Change Management	Release Management
Purpose	Ensure changes are reviewed, approved, and documented to minimize risks.		Ensure new software, features, or updates are successfully deployed to production.
Scope	Covers any IT change (code, infrastructure, configuration, security policies, etc.).		Covers software, application, and infrastructure releases as part of the SDLC.
Process	Request → Review → Approval → Implementation → Monitoring		Planning → Build → Testing → Deployment → Validation
Key Activities	Risk assessment, impact analysis, rollback planning, documentation, approvals.		Packaging, testing, deployment, rollback strategies, version control.
Owner	Change Advisory Board (CAB), ITSM teams, SREs, DevOps Engineers.		DevOps, Release Engineers, SREs, QA teams.
Frequency	Happens for each change request (can be daily or weekly).		Follows a fixed release cycle (e.g., weekly, bi-weekly, continuous delivery).
Governance	Often follows ITIL, SOC2, ISO 27001 for compliance and audit requirements.		Aligned with DevOps practices (CI/CD, Agile, GitOps) for automation & efficiency.

2. Key Differences

A,  Change Management = Decision Making & Risk Mitigation

• Ensures changes (e.g., code updates, infrastructure modifications, security patches) are reviewed, tested, and approved before implementation.
• Uses frameworks like ITIL (Information Technology Infrastructure Library) for structured governance.
• Example: A database schema change needs CAB approval before implementation.

B,  Release Management = Deployment & Delivery Process

• Focuses on safely deploying updates into production using automation (CI/CD pipelines).
• Ensures smooth rollouts with feature flags, blue-green deployments, and canary releases.
• Example: A new feature rollout happens via phased deployment using a release pipeline.

3. How They Work Together

• Change Management approves changes, while Release Management executes them.
• A change request (RFC - Request for Change) may trigger a release cycle.
• Release Management follows the Change Management approval process to ensure safe deployments.

Example Workflow:

A.     Change Management:

• A DevOps team proposes an infrastructure change (e.g., upgrading Kubernetes from v1.24 to v1.26).
• A Change Request (RFC) is submitted and reviewed for impact and risk.
• After approval, it's scheduled for release.

B.     Release Management:

• The update is packaged into a deployment pipeline.
• A canary release is used to test in production with real traffic.
• If successful, the update is fully rolled out and monitored for issues.

4. When to Use Each

 Use Change Management when:

• The change has a high risk (e.g., firewall rule updates, database schema changes).
• Compliance or security approvals are required.
• A rollback plan needs to be documented.

 Use Release Management when:

• twtech is delivering features, patches, or infrastructure changes via an automated pipeline.
• twtech needs to coordinate deployments across multiple environments (Dev,QA, Staging(Pre-Prod), Prod).
• twtwch is following CI/CD or Agile methodologies.

twtech  insights:

Backup procedures before a new release (to prevent data loss, system failures, or security risks)

1. Database Backups (Most Critical )

• Always back up databases (SQL & NoSQL) before any deployment that might alter schema, data, or stored procedures.
• Use point-in-time recovery (PITR) and snapshots for rapid rollback.
• For cloud-based DBs (AWS RDS, Azure SQL, etc.), enable automated backups and store copies in a separate region.

2. Configuration Files & Environment Variables

• Backup application config files, environment variables, and feature flags (e.g., .env, Kubernetes ConfigMaps/Secrets).
• In Kubernetes, backup Helm values, kubectl get all -o yaml, and etcd data before changes.
• Store backups in version control (Git, S3, or secure vaults like HashiCorp Vault/AWS SSM).

3. Infrastructure-as-Code (IaC) State

• Backup Terraform state files (terraform.tfstate) if using Terraform.
• Store state in remote backends (S3,) with versioning enabled.
• If using CloudFormation, take stack exports before modifications.

4. Application Artifacts & Binaries

• Retain a stable version of the application (Docker images, JAR/WAR files, etc.) in an artifact repository (ECR, DockerHub, Nexus, Artifactory).
• Ensure rollback versions are always accessible in case of a bad deployment.

5. Logs & Monitoring Data

• Back up system logs (e.g., /var/log/), application logs, and cloud provider logs.
• Store logs in long-term storage (AWS S3, ELK, Loki, Datadog, etc.) for post-mortem analysis if rollback is needed.

6. Security Certificates & Access Policies

• Backup SSL/TLS certificates, API keys, IAM policies, security groups, and firewall rules.
• Ensure access permissions are versioned and auditable in case of accidental misconfiguration.

7. Persistent Storage & File Systems

• For applications storing user uploads, reports, and critical documents, backup mounted volumes (EBS, EFS, NFS, Ceph, etc.).
• Use cloud snapshots (AWS EBS snapshots, Azure Managed Disk snapshots) before changes.

8. Kubernetes Cluster State & Resources

• Take a backup of Kubernetes manifests (kubectl get all -o yaml > backup.yaml).
• Use Kasten k10 to backup cluster state and persistent volumes.
• Ensure Helm releases can be rolled back (helm rollback <release> <revision>).

9. CI/CD Pipeline Configurations

• Backup Jenkins jobs, GitHub Actions workflows, GitLab CI/CD YAML, ArgoCD configs before modifying pipelines.
• Keep a version-controlled history of all changes to prevent CI/CD failures.

10. Load Balancer & DNS Records

• Backup load balancer configurations, ingress rules, and DNS records (Route 53, Cloudflare, etc.).
• Misconfigurations can cause service outages, so having snapshots ensures quick recovery.

Best Practices for Backups Before Releases

• Automate Backups using cron jobs, scripts, or backup services (AWS Backup, Velero, etc.).
• Store Backups in a Separate Location (Multi-region, Multi-cloud).
• Encrypt & Protect Backups with IAM roles, KMS encryption, or HashiCorp Vault.
• Test Restore Procedures regularly—a backup is useless if it can’t be restored.