Skip to main content
Glama

DocAgent

by vinnyfds
release_runbook.md.jinjaโ€ข7.69 kB
# {{ idea.title }} - Release Runbook **Version:** {{ idea.version }} **Date:** {{ idea.created_at.strftime('%Y-%m-%d') }} **Project:** {{ idea.context.project_name }} **Domain:** {{ idea.context.domain }} ## Release Runbook Overview Comprehensive guide for executing {{ idea.context.project_name }} releases with step-by-step procedures, rollback plans, and emergency contacts. ## Release Information ### Release Details - **Release Version:** {{ idea.version }} - **Release Date:** {{ idea.created_at.strftime('%Y-%m-%d') }} - **Release Manager:** [To be assigned] - **Release Type:** [Major/Minor/Patch] ### Release Scope {% for module in idea.modules %} - {{ module }} module updates {% endfor %} - API changes and enhancements - Database schema updates - Infrastructure improvements - Security patches ## Pre-Release Checklist ### Code Quality - [ ] All unit tests passing (โ‰ฅ90% coverage) - [ ] Integration tests completed successfully - [ ] Security scan passed with no critical issues - [ ] Code review completed and approved - [ ] Performance benchmarks met ### Documentation - [ ] API documentation updated - [ ] User guides updated - [ ] Release notes prepared - [ ] Change log updated - [ ] Deployment guide reviewed ### Infrastructure - [ ] Staging environment validated - [ ] Database migrations tested - [ ] Backup procedures verified - [ ] Monitoring alerts configured - [ ] Rollback procedures tested ## Release Timeline ### Pre-Release (Day Before) - **09:00 AM:** Final code review and approval - **10:00 AM:** Staging deployment and validation - **02:00 PM:** Stakeholder approval meeting - **04:00 PM:** Production environment preparation ### Release Day - **08:00 AM:** Team standup and final review - **09:00 AM:** Production deployment initiation - **10:00 AM:** Health checks and validation - **11:00 AM:** User notification and go-live - **02:00 PM:** Post-release monitoring - **05:00 PM:** Release completion review ## Deployment Procedures ### Step 1: Pre-Deployment ```bash # 1. Verify production environment status kubectl get pods -n production kubectl get services -n production # 2. Create backup kubectl exec -n production deployment/database -- pg_dump > backup_$(date +%Y%m%d_%H%M%S).sql # 3. Verify rollback capability kubectl rollout history deployment/app -n production ``` ### Step 2: Database Migration ```bash # 1. Apply database migrations kubectl exec -n production deployment/app -- python manage.py migrate # 2. Verify migration success kubectl exec -n production deployment/app -- python manage.py showmigrations # 3. Run data validation scripts kubectl exec -n production deployment/app -- python scripts/validate_data.py ``` ### Step 3: Application Deployment ```bash # 1. Deploy new application version kubectl set image deployment/app app=app:{{ idea.version }} -n production # 2. Monitor deployment progress kubectl rollout status deployment/app -n production # 3. Verify deployment success kubectl get pods -n production kubectl logs -f deployment/app -n production ``` ### Step 4: Post-Deployment Validation ```bash # 1. Health check endpoints curl -f https://api.{{ idea.context.project_name.lower().replace(' ', '') }}.com/health curl -f https://api.{{ idea.context.project_name.lower().replace(' ', '') }}.com/ready # 2. Smoke tests python scripts/smoke_tests.py --environment=production # 3. Performance validation python scripts/performance_check.py --environment=production ``` ## Rollback Procedures ### Automatic Rollback Triggers - Health check failures (>3 consecutive failures) - Error rate threshold exceeded (>5% for 5 minutes) - Response time degradation (>2x baseline for 5 minutes) - Database connection failures ### Manual Rollback Commands ```bash # 1. Rollback to previous version kubectl rollout undo deployment/app -n production # 2. Monitor rollback progress kubectl rollout status deployment/app -n production # 3. Verify rollback success kubectl get pods -n production kubectl logs -f deployment/app -n production # 4. Database rollback (if needed) kubectl exec -n production deployment/app -- python manage.py migrate {{ idea.version }} ``` ### Rollback Validation - [ ] Application health restored - [ ] Database integrity verified - [ ] User functionality confirmed - [ ] Performance metrics normalized - [ ] Stakeholder notification sent ## Monitoring and Alerting ### Key Metrics to Monitor {% for kpi in idea.kpis %} - {{ kpi }} performance {% endfor %} - Application response time - Error rates and types - Database performance - Infrastructure health ### Alert Thresholds - **Critical:** Application down, database unavailable - **High:** Error rate >10%, response time >5s - **Medium:** Error rate >5%, response time >2s - **Low:** Performance degradation, resource usage ### Monitoring Tools - **Application:** Prometheus, Grafana - **Infrastructure:** CloudWatch, DataDog - **Logs:** ELK Stack, CloudWatch Logs - **Alerts:** PagerDuty, Slack ## Emergency Procedures ### Incident Response 1. **Immediate Action:** Assess impact and notify stakeholders 2. **Investigation:** Gather information and identify root cause 3. **Resolution:** Execute fix or rollback procedure 4. **Communication:** Update stakeholders and users 5. **Post-Incident:** Document lessons learned ### Emergency Contacts - **Release Manager:** [Phone] [Email] - **Technical Lead:** [Phone] [Email] - **DevOps Engineer:** [Phone] [Email] - **Database Administrator:** [Phone] [Email] - **Stakeholder:** [Phone] [Email] ### Escalation Matrix - **Level 1:** On-call engineer (0-30 minutes) - **Level 2:** Technical lead (30-60 minutes) - **Level 3:** Release manager (60-120 minutes) - **Level 4:** Executive stakeholders (120+ minutes) ## Post-Release Activities ### Monitoring Period - **Immediate (0-2 hours):** Continuous monitoring and validation - **Short-term (2-24 hours):** Regular health checks and performance monitoring - **Long-term (1-7 days):** User feedback collection and performance analysis ### Success Criteria - [ ] All health checks passing - [ ] Performance metrics within acceptable ranges - [ ] No critical errors in logs - [ ] User functionality confirmed - [ ] Stakeholder approval received ### Post-Release Tasks - [ ] Update release documentation - [ ] Archive release artifacts - [ ] Schedule post-release review - [ ] Update runbook with lessons learned - [ ] Plan next release cycle ## Communication Plan ### Stakeholder Updates - **Pre-Release:** Release notification and schedule - **During Release:** Progress updates and status - **Post-Release:** Success confirmation and metrics - **Issues:** Incident notification and resolution updates ### User Communication - **Scheduled Maintenance:** 24-hour advance notice - **Release Notes:** Published on release day - **Feature Announcements:** User guide updates - **Issue Notifications:** Status page updates ## Risk Mitigation ### High-Risk Scenarios - **Database Migration Failure:** Automated rollback and manual intervention - **Application Deployment Failure:** Health check monitoring and rollback - **Performance Degradation:** Performance monitoring and scaling - **Security Issues:** Immediate rollback and security review ### Contingency Plans - **Extended Downtime:** Communication plan and user support - **Data Loss:** Backup restoration and data recovery - **Integration Failures:** Fallback systems and manual processes - **Resource Constraints:** Auto-scaling and manual scaling ## Change Log | Date | Version | Change | Author | |------|---------|---------|---------| | {{ idea.created_at.strftime('%Y-%m-%d') }} | {{ idea.version }} | Initial release runbook creation | System |

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vinnyfds/docagent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server