This repository demonstrates Solution #2 from the DEV.to article "Implementing Continuous Delivery for GitHub Monorepos and Microservices with GitHub Actions". This approach uses git diff
to intelligently detect which microservices have changed and deploy only those services.
root/
βββ .github/
β βββ workflows/
β βββ deploy.yml # Smart deployment workflow
βββ package.json # Root workspace configuration
βββ README.md # This file
βββ services/
βββ service-a/ # User Management Service (Port 3001)
βββ service-b/ # Order Processing Service (Port 3002)
βββ service-c/ # Notification Service (Port 3003)
- Change Detection: Uses
git diff
to identify which service directories have been modified - Conditional Deployment: Only deploys services that actually changed
- Parallel Processing: Multiple changed services deploy simultaneously
- Efficiency: Avoids unnecessary deployments, saving time and resources
Service | Purpose | Port | Endpoints |
---|---|---|---|
service-a | User Management | 3001 | / , /health , /users |
service-b | Order Processing | 3002 | / , /health , /orders |
service-c | Notification Service | 3003 | / , /health , /notifications |
- Node.js 20+
- Docker (optional, for containerization)
- Git
-
Clone the repository:
git clone https://github.com/octodemo/monorepo-cd-demo-russel.git cd monorepo-cd-demo-russel
-
Install dependencies:
npm install
-
Start all services:
npm run start:all
-
Or start individual services:
npm run start:service-a npm run start:service-b npm run start:service-c
- Service A: http://localhost:3001
- Service B: http://localhost:3002
- Service C: http://localhost:3003
Health checks available at /health
endpoint for each service.
The GitHub Actions workflow (.github/workflows/deploy.yml
) implements the following logic:
# Simplified workflow logic:
1. Checkout code with full history
2. Detect changed services using git diff
3. Create deployment matrix for changed services only
4. Deploy services in parallel
5. Report deployment status
- Automatic: Push to
main
branch - Manual: Use "Run workflow" button in GitHub Actions
-
Modify a single service:
echo "console.log('Updated!');" >> services/service-a/index.js git add . && git commit -m "Update service-a" git push
-
Check Actions tab - Only service-a should deploy!
-
Modify multiple services:
echo "// Updated" >> services/service-a/index.js echo "// Updated" >> services/service-b/index.js git add . && git commit -m "Update service-a and service-b" git push
-
Check Actions tab - Both services should deploy in parallel!
Each service includes a Dockerfile optimized for production:
# Build specific service
docker build -t service-a ./services/service-a
# Run service
docker run -p 3001:3001 service-a
All services include health check endpoints:
# Check service health
curl http://localhost:3001/health
curl http://localhost:3002/health
curl http://localhost:3003/health
Response format:
{
"status": "healthy",
"service": "service-a",
"version": "1.0.0",
"timestamp": "2024-01-01T00:00:00.000Z"
}
-
Create service directory:
mkdir services/service-d
-
Add package.json, index.js, Dockerfile, README.md (follow existing patterns)
-
Update root package.json with new scripts
-
The workflow automatically detects new services - no changes needed!
- β Efficient: Only deploys what changed
- β Fast: Parallel deployment of multiple services
- β Scalable: Easy to add new services
- β Reliable: Git-based change detection
- β Transparent: Clear logging of what's being deployed
-
No services detected as changed:
- Ensure changes are in
services/
directory - Check git history is available (fetch-depth: 0)
- Ensure changes are in
-
Service won't start:
- Check port conflicts
- Verify dependencies are installed
- Check service logs
-
Docker build fails:
- Ensure Dockerfile syntax is correct
- Check base image availability
# Check which services would be detected as changed
git diff --name-only HEAD~1 HEAD | grep '^services/' | cut -d'/' -f2 | sort | uniq
# Test individual service
cd services/service-a
npm start
# Check service health
curl -f http://localhost:3001/health || echo "Service not healthy"
- Fork the repository
- Create a feature branch
- Make your changes
- Test the change detection works correctly
- Submit a pull request
Happy coding! π This demo shows how Solution #2 makes monorepo CI/CD efficient and scalable.