File tree Expand file tree Collapse file tree
Expand file tree Collapse file tree Original file line number Diff line number Diff line change 1+ ## Branching Strategy
2+
3+ This project follows a structured Git branching model:
4+
5+ - ` main ` → Production environment
6+ - ` develop ` → Staging / integration environment
7+ - ` feature/* ` → Feature development branches
8+
9+ ### Workflow
10+
11+ 1 . Developer creates a feature branch from ` develop `
12+ 2 . Feature is implemented and pushed
13+ 3 . Pull Request is created to ` develop `
14+ 4 . CI pipeline validates build and container health
15+ 5 . After approval, feature is merged into ` develop `
16+ 6 . Release Pull Request is created from ` develop ` to ` main `
17+ 7 . On merge to ` main ` , production deployment is triggered
18+
19+ ### Conflict Resolution Approach
20+
21+ Before merging, the feature branch is rebased or merged with latest ` develop ` branch.
22+ Conflicts are resolved locally, tested again, and then pushed.
23+
24+ ### Branch Protection Strategy
25+
26+ Even though GitHub free plan does not enforce strict protection:
27+
28+ - Direct push to ` main ` is avoided
29+ - Pull Request approval is required
30+ - CI pipeline must pass before merge
31+ - Feature branches are short-lived
Original file line number Diff line number Diff line change 1+ ## CI/CD Pipeline Flow
2+
3+ CI/CD is implemented using GitHub Actions.
4+
5+ ### CI Flow
6+
7+ - Pipeline triggers on Pull Requests to ` develop ` and ` main `
8+ - Dependencies are installed
9+ - Syntax validation is performed
10+ - Docker image build is tested
11+ - Container health endpoint is validated
12+
13+ If any step fails, the PR cannot be safely merged.
14+
15+ ### CD Flow
16+
17+ - Push to ` develop ` triggers staging deployment
18+ - Push to ` main ` triggers production deployment
19+ - Deployment happens via SSH into Azure VM
20+ - Docker container is rebuilt and restarted
21+
22+ This ensures continuous delivery with minimal manual intervention.
Original file line number Diff line number Diff line change 1+ ## Production Deployment Failure Debugging Approach
2+
3+ If production deployment fails after merge:
4+
5+ 1 . Check GitHub Actions logs to identify failing stage
6+ 2 . SSH into Azure VM
7+ 3 . Verify Docker container status using ` docker ps `
8+ 4 . Check container logs using ` docker logs `
9+ 5 . Validate environment variables and port bindings
10+ 6 . Test application health endpoint locally inside VM
11+ 7 . Rollback to last working commit using ` git revert `
12+ 8 . Rebuild Docker image and restart container
13+ 9 . Monitor logs after redeployment
14+
15+ This structured approach minimizes downtime and ensures faster recovery.
Original file line number Diff line number Diff line change 1+ ## Deployment Architecture
2+
3+ Application is deployed on an Azure Virtual Machine using Docker.
4+
5+ Two environments are maintained on the same VM:
6+
7+ - Staging → Container running on port 8001 (develop branch)
8+ - Production → Container running on port 8000 (main branch)
9+
10+ Nginx reverse proxy routes traffic to appropriate containers.
11+
12+ ### Environment Variable Management
13+
14+ Sensitive values are not stored in the repository.
15+
16+ They are managed using:
17+
18+ - GitHub Secrets for CI/CD authentication
19+ - Environment variables inside Docker runtime
20+ - Azure Key Vault can be used in real production
21+
22+ ### Rollback Strategy
23+
24+ If deployment fails:
25+
26+ - Previous commit can be reverted
27+ - Older Docker image can be redeployed
28+ - Container can be restarted with previous tag
29+ - GitHub Actions workflow can be re-run
Original file line number Diff line number Diff line change 1+ ## Monitoring and Infrastructure Strategy
2+
3+ ### Logging
4+
5+ - Application logs are collected via ` docker logs `
6+ - Nginx access logs help identify traffic patterns
7+ - Azure Monitor / ELK stack can be integrated for centralized logging
8+
9+ ### Downtime Handling
10+
11+ - Docker container restart policies improve resilience
12+ - Healthcheck endpoint ensures service availability
13+ - Load balancer can be added for redundancy
14+
15+ ### Scaling Strategy
16+
17+ - Horizontal scaling using multiple containers
18+ - VM Scale Sets or Kubernetes for auto-scaling
19+ - Stateless architecture to allow scaling
20+
21+ ### API Credit Monitoring
22+
23+ - Middleware can track API usage
24+ - Threshold alerts can notify via email or Slack
25+
26+ ### Cost Optimization
27+
28+ - Use smaller VM size for staging
29+ - Schedule non-production shutdown during low usage
30+ - Use autoscaling to match demand
31+
32+ ### Secrets Management
33+
34+ - GitHub Secrets
35+ - Azure Key Vault
36+ - Avoid storing secrets in codebase
You can’t perform that action at this time.
0 commit comments