Artha.kadamb@heinfricke.team at 11:19, 22 December 2025

2025-12-22T11:19:33Z

Artha.kadamb@heinfricke.team: /* Deployment Execution: */

2025-12-22T10:18:51Z

Deployment Execution:

Artha.kadamb@heinfricke.team: Created page with "=== 1 Introduction === ==== '''Purpose''': ==== * Create a clear, repeatable process for deploying and releasing software to production, ensuring teams can follow it. ==== '''Scope''': ==== * Covers all software projects (web, mobile, backend) across development, staging, and production environments in the company. ==== '''Key Terms''': ==== * Release: A versioned set of changes (e.g., v1.2.3). * Deployment: Moving a release to an environment. * Rollback: Rever..."

2025-12-22T10:10:31Z

Created page with "=== 1 Introduction === ==== '''Purpose''': ==== * Create a clear, repeatable process for deploying and releasing software to production, ensuring teams can follow it. ==== '''Scope''': ==== * Covers all software projects (web, mobile, backend) across development, staging, and production environments in the company. ==== '''Key Terms''': ==== * Release: A versioned set of changes (e.g., v1.2.3). * Deployment: Moving a release to an environment. * Rollback: Rever..."

New page

=== 1 Introduction ===

==== '''Purpose''': ====

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

==== '''Scope''': ====

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

==== '''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''' ===

==== '''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.

==== '''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.

==== '''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).

==== '''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''' ===

==== '''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.

==== '''SDLC Fit''': ====

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

==== '''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.

==== '''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.

==== '''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''' ===

==== '''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.

==== '''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.

==== '''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.

==== '''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.

==== '''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.

==== '''Dependencies''': ====

* List external dependencies if any in Jira.

* Check dependency versions in staging before prod.

=== '''5. Deployment Process''' ===

==== '''Pre-Deployment Activities''': ====

===== Environment Setup: =====

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

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

* Validate SSL certificates are active.

==== '''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.

==== '''Checklist''': ====

* Confirm prod backups are complete.

* Verify network connectivity.

* Check disk space on prod servers.

* Ensure rollback artifacts are available in Artifactory.

==== '''Backups''': ====

* Create database backups.

* Backup configuration files.

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

==== '''Deployment Execution''': ====

===== Checklist: =====

* Verify artifact version matches Git tag.

* Check dependencies are installed.

==== '''Execution''' ====

* Run deployment script or manual deployment.

==== '''Monitoring''': ====

* Watch server logs.

* Monitor CPU, memory, and response times.

==== '''Post-Deployment Activities''': ====

===== '''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.

===== '''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.

===== '''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.

===== '''Documentation''': =====

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

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

Talk:04 Deployment & Release Management Procedure - Revision history

Artha.kadamb@heinfricke.team at 11:19, 22 December 2025

Artha.kadamb@heinfricke.team: /* Deployment Execution: */