Skip to content

Commit de94165

Browse files
Merge pull request #1 from codicecustode/develop
PR from develop to main
2 parents 5448a20 + 7354150 commit de94165

5 files changed

Lines changed: 133 additions & 0 deletions

File tree

docs/branching.md

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
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

docs/cicd.md

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
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.

docs/debugging.md

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
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.

docs/deployment.md

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
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

docs/monitoring.md

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
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

0 commit comments

Comments
 (0)