Talk:04 Deployment & Release Management Procedure

1 Introduction

1.1 Purpose

Create a clear, repeatable process for deploying and releasing software to production, ensuring teams can follow it.

1.2 Scope

Covers all software projects (web, mobile, backend) across development, staging, and production environments in the company.

1.3 Key Terms

• Release: A versioned set of changes (e.g., v1.2.3).

• Deployment: Moving a release to an environment.

• Rollback: Reverting to the previous working version.

• Artifact: A compiled, versioned package (e.g., .jar, .zip).

• Environment: Dev, staging, or prod setups.

2. Roles and Responsibilities

2.1 Key Roles

• Release Manager: Plans and tracks releases, coordinates approvals.

• Deployment Engineer: Runs deployments, checks environments.

• QA Lead: Verifies test results before deployment.

• Product Owner: Approves release scope and timing.

2.2 Deployment Team Tasks

• Set up and validate servers or cloud environments (e.g., AWS, Azure).

• Run deployment scripts and monitor logs.

• Execute rollback if deployment fails.

2.3 Release Management Team Tasks

• Schedule releases in Calendar.

• Collect acceptance from QA and Product Owners.

• Update release notes in a shared repo (e.g., GitHub Wiki).

2.4 Team Collaboration

• Developers push code to Git; QA tests in staging; Ops confirms prod readiness.

• Daily standups or Slack channels for updates.

• Escalation Contacts: List names, contacts and emails for Release Manager, Lead, and Product owner for urgent issues.

3. Deployment & Release Management Process Overview

3.1 Core Steps

• Create a release plan in Jira with scope, timeline, and dependencies.

• Deploy features in staging for QA verification.

• Fix bugs in relative branches.

• Complete integration testing.

• Deploy and demo on Test environment for stakeholders' acceptance.

• On formal acceptance and product owners' approval, prepare for Production deployment.

• Verify functionality, and rollback if issues arise.

• Document every step in Jira  

• Close Jira ticket with logs and release notes.

3.2 SDLC Fit

• Agile: Deploy after each sprint (e.g., every 2 weeks); link to sprint tickets in Jira.

3.3 Change Tracking

• Log all code changes in Git with commit messages (e.g., “Fix #123: login bug”).

• Link commits to Jira tickets for traceability (e.g., JIRA-456).

• Use Git tags (e.g., v1.2.3) for release versioning.

3.4 Exceptions

• Emergency releases: Skip staging, deploy hotfix directly to prod with CTO approval via Slack.

• Tag emergency tickets in Jira with “HOTFIX” prefix and log justification.

• Notify all teams via Slack #releases within 1 hour of emergency deployment.

3.5 Version Control

• Use Git branches: main for prod, develop for dev, release/v1.2.3 for releases.

• Require pull requests (PRs) with at least 1 reviewer in GitHub

• Include commit messages with Jira ticket IDs (e.g., “JIRA-456: Add payment API”).

• Tag releases in Git (e.g., git tag v1.2.3) and push to repo.

4. Release Planning

4.1 Release Types

• Major: Big major features scheduled quarterly.

• Minor: Small enhancements or Bug fixes scheduled sprint wise.

• Emergency: Critical fixes deployed same or next day.

4.2 Scheduling and communication

• Create a release calendar in Google Calendar or Jira, shared with all teams.

• Avoid deployments during peak usage (e.g., 9 AM–5 PM weekdays for e-commerce apps).

• Set maintenance windows (e.g., Sunday 2 AM–4 AM) for major releases if required.

• Notify teams via email and communication 24 hours before employment.

• Update internal Confluence page with release details  

• Include version number, release date, and Jira ticket IDs.

• Notify stakeholders via email about potential user-facing changes.

4.3 Release Criteria

• Code passes 90%-unit test coverage.

• Zero critical or high-severity bugs in QA tests, tracked in Jira.

• Performance tests (e.g., JMeter) meet thresholds and latencies.

• Documentation for the deliverable is updated and reviewed.

4.4 Risk Checks

• Verify database migrations won’t break existing data (e.g., run in staging first).

• Test rollback scripts in staging to ensure they work.

• Confirm no conflicts with other scheduled deployments or maintenance.

4.5 Approvals

• Product Owner approves release scope in Jira ticket (e.g., REL-789).

• QA Lead signs off on tests via Jira comment or email.

• Tech lead approves emergency releases via Email or Teams  

• Log all approvals in Jira with timestamps and usernames.

4.6 Dependencies

• List external dependencies if any in Jira.

• Check dependency versions in staging before prod.

5. Deployment Process

5.1 Pre-Deployment Activities:

5.1.1 Environment Setup

• Check server health (CPU <80%, memory <70%).

• Verify database connectivity (e.g., MySQL, PostgreSQL) with test queries.

• Validate SSL certificates are active.

5.1.2 Build and Packaging

• Run build scripts to create artifacts.

• Create database migration release script.

• Push artifacts to Artifactory with version tags.

• Tag build in Git (e.g., git tag v1.2.3) and push to repo.

5.1.3 Checklist

• Confirm prod backups are complete.

• Verify network connectivity.

• Check disk space on prod servers.

• Ensure rollback artifacts are available in Artifactory.

5.1.4 Backups

• Create database backups.

• Backup configuration files.

• Test and validate restore process in staging to confirm backups are usable.

5.2 Deployment Execution:

5.2.1 Checklist

• Verify artifact version matches Git tag.

• Check dependencies are installed.

5.2.2 Execution

• Run deployment script or manual deployment.

5.2.3 Monitoring

• Watch server logs.

• Monitor CPU, memory, and response times.

5.3 Post-Deployment Activities:

5.3.1 Verification

• Run smoke tests (e.g., login, API health check) in prod within 10 minutes.

• Check performance (e.g., <200ms response time) manually or in Grafana dashboards.

• Confirm key features work via manual checks or automated scripts.

5.3.2 Rollback

• Revert to previous artifact in Artifactory (e.g., app-v1.2.2.jar).

• Restore database from last backup.

• Test rollback in staging first if time permits.

• Notify teams if rollback occurs.

5.3.3 Notifications

• Email clients with release notes for major releases (e.g., new UI features).

• Email specific stakeholders for hotfix.

• Notify stakeholders of any user-facing changes via email.

5.3.4 Documentation

• Update release notes in GitHub Wiki with features, fixes, and issues.

• Record new environment settings (e.g., updated API keys) in Confluence.