mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-23 10:56:38 +00:00
Refactor README and command documentation to streamline deployment and CI/CD processes. Consolidate deployment strategies and remove obsolete commands related to CI/CD and observability. Enhance task decomposition workflow by adding data model and deployment planning sections, and update directory structures for improved clarity.
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -1,71 +0,0 @@
|
||||
# Deployment Strategy Planning
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components: `@_docs/02_components`
|
||||
- Environment Strategy: `@_docs/00_templates/environment_strategy.md`
|
||||
|
||||
## Role
|
||||
You are a DevOps/Platform engineer
|
||||
|
||||
## Task
|
||||
- Define deployment strategy for each environment
|
||||
- Plan deployment procedures and automation
|
||||
- Define rollback procedures
|
||||
- Establish deployment verification steps
|
||||
- Document manual intervention points
|
||||
|
||||
## Output
|
||||
|
||||
### Deployment Architecture
|
||||
- Infrastructure diagram (where components run)
|
||||
- Network topology
|
||||
- Load balancing strategy
|
||||
- Container/VM configuration
|
||||
|
||||
### Deployment Procedures
|
||||
|
||||
#### Staging Deployment
|
||||
- Trigger conditions
|
||||
- Pre-deployment checks
|
||||
- Deployment steps
|
||||
- Post-deployment verification
|
||||
- Smoke tests to run
|
||||
|
||||
#### Production Deployment
|
||||
- Approval workflow
|
||||
- Deployment window
|
||||
- Pre-deployment checks
|
||||
- Deployment steps (blue-green, rolling, canary)
|
||||
- Post-deployment verification
|
||||
- Smoke tests to run
|
||||
|
||||
### Rollback Procedures
|
||||
- Rollback trigger criteria
|
||||
- Rollback steps per environment
|
||||
- Data rollback considerations
|
||||
- Communication plan during rollback
|
||||
|
||||
### Health Checks
|
||||
- Liveness probe configuration
|
||||
- Readiness probe configuration
|
||||
- Custom health endpoints
|
||||
|
||||
### Deployment Checklist
|
||||
- [ ] All tests pass in CI
|
||||
- [ ] Security scan clean
|
||||
- [ ] Database migrations reviewed
|
||||
- [ ] Feature flags configured
|
||||
- [ ] Monitoring alerts configured
|
||||
- [ ] Rollback plan documented
|
||||
- [ ] Stakeholders notified
|
||||
|
||||
Store output to `_docs/02_components/deployment_strategy.md`
|
||||
|
||||
## Notes
|
||||
- Prefer automated deployments over manual
|
||||
- Zero-downtime deployments for production
|
||||
- Always have a rollback plan
|
||||
- Ask questions about infrastructure constraints
|
||||
@@ -1,64 +0,0 @@
|
||||
# CI/CD Pipeline Validation & Enhancement
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components: `@_docs/02_components`
|
||||
- Environment Strategy: `@_docs/00_templates/environment_strategy.md`
|
||||
|
||||
## Role
|
||||
You are a DevOps engineer
|
||||
|
||||
## Task
|
||||
- Review existing CI/CD pipeline configuration
|
||||
- Validate all stages are working correctly
|
||||
- Optimize pipeline performance (parallelization, caching)
|
||||
- Ensure test coverage gates are enforced
|
||||
- Verify security scanning is properly configured
|
||||
- Add missing quality gates
|
||||
|
||||
## Checklist
|
||||
|
||||
### Pipeline Health
|
||||
- [ ] All stages execute successfully
|
||||
- [ ] Build time is acceptable (<10 min for most projects)
|
||||
- [ ] Caching is properly configured (dependencies, build artifacts)
|
||||
- [ ] Parallel execution where possible
|
||||
|
||||
### Quality Gates
|
||||
- [ ] Code coverage threshold enforced (minimum 75%)
|
||||
- [ ] Linting errors block merge
|
||||
- [ ] Security vulnerabilities block merge (critical/high)
|
||||
- [ ] All tests must pass
|
||||
|
||||
### Environment Deployments
|
||||
- [ ] Staging deployment works on merge to stage branch
|
||||
- [ ] Environment variables properly configured per environment
|
||||
- [ ] Secrets are securely managed (not in code)
|
||||
- [ ] Rollback procedure documented
|
||||
|
||||
### Monitoring
|
||||
- [ ] Build notifications configured (Slack, email, etc.)
|
||||
- [ ] Failed build alerts
|
||||
- [ ] Deployment success/failure notifications
|
||||
|
||||
## Output
|
||||
|
||||
### Pipeline Status Report
|
||||
- Current pipeline configuration summary
|
||||
- Issues found and fixes applied
|
||||
- Performance metrics (build times)
|
||||
|
||||
### Recommended Improvements
|
||||
- Short-term improvements
|
||||
- Long-term optimizations
|
||||
|
||||
### Quality Gate Configuration
|
||||
- Thresholds configured
|
||||
- Enforcement rules
|
||||
|
||||
## Notes
|
||||
- Do not break existing functionality
|
||||
- Test changes in separate branch first
|
||||
- Document any manual steps required
|
||||
@@ -1,122 +0,0 @@
|
||||
# Observability Planning
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components: `@_docs/02_components`
|
||||
- Deployment Strategy: `@_docs/02_components/deployment_strategy.md`
|
||||
|
||||
## Role
|
||||
You are a Site Reliability Engineer (SRE)
|
||||
|
||||
## Task
|
||||
- Define logging strategy across all components
|
||||
- Plan metrics collection and dashboards
|
||||
- Design distributed tracing (if applicable)
|
||||
- Establish alerting rules
|
||||
- Document incident response procedures
|
||||
|
||||
## Output
|
||||
|
||||
### Logging Strategy
|
||||
|
||||
#### Log Levels
|
||||
| Level | Usage | Example |
|
||||
|-------|-------|---------|
|
||||
| ERROR | Exceptions, failures requiring attention | Database connection failed |
|
||||
| WARN | Potential issues, degraded performance | Retry attempt 2/3 |
|
||||
| INFO | Significant business events | User registered, Order placed |
|
||||
| DEBUG | Detailed diagnostic information | Request payload, Query params |
|
||||
|
||||
#### Log Format
|
||||
```json
|
||||
{
|
||||
"timestamp": "ISO8601",
|
||||
"level": "INFO",
|
||||
"service": "service-name",
|
||||
"correlation_id": "uuid",
|
||||
"message": "Event description",
|
||||
"context": {}
|
||||
}
|
||||
```
|
||||
|
||||
#### Log Storage
|
||||
- Development: Console/file
|
||||
- Staging: Centralized (ELK, CloudWatch, etc.)
|
||||
- Production: Centralized with retention policy
|
||||
|
||||
### Metrics
|
||||
|
||||
#### System Metrics
|
||||
- CPU usage
|
||||
- Memory usage
|
||||
- Disk I/O
|
||||
- Network I/O
|
||||
|
||||
#### Application Metrics
|
||||
| Metric | Type | Description |
|
||||
|--------|------|-------------|
|
||||
| request_count | Counter | Total requests |
|
||||
| request_duration | Histogram | Response time |
|
||||
| error_count | Counter | Failed requests |
|
||||
| active_connections | Gauge | Current connections |
|
||||
|
||||
#### Business Metrics
|
||||
- [Define based on acceptance criteria]
|
||||
|
||||
### Distributed Tracing
|
||||
|
||||
#### Trace Context
|
||||
- Correlation ID propagation
|
||||
- Span naming conventions
|
||||
- Sampling strategy
|
||||
|
||||
#### Integration Points
|
||||
- HTTP headers
|
||||
- Message queue metadata
|
||||
- Database query tagging
|
||||
|
||||
### Alerting
|
||||
|
||||
#### Alert Categories
|
||||
| Severity | Response Time | Examples |
|
||||
|----------|---------------|----------|
|
||||
| Critical | 5 min | Service down, Data loss |
|
||||
| High | 30 min | High error rate, Performance degradation |
|
||||
| Medium | 4 hours | Elevated latency, Disk usage high |
|
||||
| Low | Next business day | Non-critical warnings |
|
||||
|
||||
#### Alert Rules
|
||||
```yaml
|
||||
alerts:
|
||||
- name: high_error_rate
|
||||
condition: error_rate > 5%
|
||||
duration: 5m
|
||||
severity: high
|
||||
|
||||
- name: service_down
|
||||
condition: health_check_failed
|
||||
duration: 1m
|
||||
severity: critical
|
||||
```
|
||||
|
||||
### Dashboards
|
||||
|
||||
#### Operations Dashboard
|
||||
- Service health status
|
||||
- Request rate and error rate
|
||||
- Response time percentiles
|
||||
- Resource utilization
|
||||
|
||||
#### Business Dashboard
|
||||
- Key business metrics
|
||||
- User activity
|
||||
- Transaction volumes
|
||||
|
||||
Store output to `_docs/02_components/observability_plan.md`
|
||||
|
||||
## Notes
|
||||
- Follow the principle: "If it's not monitored, it's not in production"
|
||||
- Balance verbosity with cost
|
||||
- Ensure PII is not logged
|
||||
- Plan for log rotation and retention
|
||||
@@ -0,0 +1,54 @@
|
||||
# Implementation Rollback
|
||||
|
||||
## Role
|
||||
You are a DevOps engineer performing a controlled rollback of implementation batches.
|
||||
|
||||
## Input
|
||||
- User specifies a target batch number or commit hash to roll back to
|
||||
- If not specified, present the list of available batch checkpoints and ask
|
||||
|
||||
## Process
|
||||
|
||||
1. Read `_docs/03_implementation/batch_*_report.md` files to identify all batch checkpoints with their commit hashes
|
||||
2. Present batch list to user with: batch number, date, tasks included, commit hash
|
||||
3. Determine which commits need to be reverted (all commits after the target batch)
|
||||
4. For each commit to revert (in reverse chronological order):
|
||||
- Run `git revert <commit-hash> --no-edit`
|
||||
- Verify no merge conflicts; if conflicts occur, ask user for resolution
|
||||
5. Run the full test suite to verify rollback integrity
|
||||
6. If tests fail, report failures and ask user how to proceed
|
||||
7. Reset Jira ticket statuses for all reverted tasks back to "To Do" via Jira MCP
|
||||
8. Commit the revert with message: `[ROLLBACK] Reverted to batch [N]: [task list]`
|
||||
|
||||
## Output
|
||||
|
||||
Write `_docs/03_implementation/rollback_report.md`:
|
||||
|
||||
```markdown
|
||||
# Rollback Report
|
||||
|
||||
**Date**: [YYYY-MM-DD]
|
||||
**Target**: Batch [N] (commit [hash])
|
||||
**Reverted Batches**: [list]
|
||||
|
||||
## Reverted Tasks
|
||||
|
||||
| Task | Batch | Status Before | Status After |
|
||||
|------|-------|--------------|-------------|
|
||||
| [JIRA-ID] | [batch #] | In Testing | To Do |
|
||||
|
||||
## Test Results
|
||||
- [pass/fail count]
|
||||
|
||||
## Jira Updates
|
||||
- [list of ticket transitions]
|
||||
|
||||
## Notes
|
||||
- [any conflicts, manual steps, or issues encountered]
|
||||
```
|
||||
|
||||
## Safety Rules
|
||||
- Never force-push; always use `git revert` to preserve history
|
||||
- Always run tests after rollback
|
||||
- Always update Jira statuses for reverted tasks
|
||||
- If rollback fails midway, stop and report — do not leave the codebase in a partial state
|
||||
Reference in New Issue
Block a user