Editing Talk:04 Deployment & Release Management Procedure (section)

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