Standalone Service Workflow
Independent pipelines with feature branch validation
The new standalone architecture gives each service its own repository and CI/CD pipeline, enabling fast iteration, immediate feedback, and independent evolution.
Architecture Overview
Service-per-Repository Structure
- Individual Repositories: Each service has its own dedicated repository
- Independent Pipelines: Service-specific GitHub Actions workflows
- Feature Branch CI/CD: Full validation before merging to main
- Manual Release Control: Separate tag cutting for controlled deployments
Key Components
- GitHub Actions: Service-focused workflows with optimized performance
- Container Registry: Stores service-specific Docker images
- ArgoCD: GitOps-based deployment management
- Archetype Inheritance: Templates ensure consistency across services
Workflow Deep Dive
Feature Branch Pipeline (2-6 minutes)
This is the game-changer: full CI/CD validation before code reaches main.
Sequence Diagram: Feature Branch Development
Click to enlarge
Main Branch + Tag Cutting Pipeline
Sequence Diagram: Release Flow
Click to enlarge
Execution Flow
Click to enlarge
Performance Characteristics
Predictable Build Times
- Feature Branch: 2-6 minutes (validation only)
- Main Branch: 2-8 minutes (build + registry push)
- Tag Cutting: 1-2 minutes (tag + manifest update)
- Service-Focused: No cross-service dependencies to slow builds
Pipeline Stages
Feature Branch Validation (2-6 minutes)
- Code Checkout (10-20 seconds)
- Dependency Installation (30-90 seconds)
- Build Process (30-120 seconds)
- Test Execution (60-180 seconds)
- Artifact Validation (10-30 seconds)
Main Branch Pipeline (2-8 minutes)
- Validation (2-6 minutes) - Same as feature branch
- Docker Build (30-90 seconds)
- Registry Push (30-60 seconds)
- Metadata Update (10-20 seconds)
Tag Cutting (1-2 minutes)
- Image Tagging (10-30 seconds)
- Manifest Generation (20-40 seconds)
- GitOps Repository Update (30-60 seconds)
Release Management
Separated Tag Cutting Strategy
Unlike monorepo systems, tag cutting is a dedicated manual action.
Benefits of Manual Tag Cutting
- Release Control: Intentional, deliberate releases
- Quality Gates: Additional validation before production
- Hotfix Management: Tag previous commits for emergency releases
- Environment Promotion: Controlled progression dev → staging → production
Tag Cutting Process
- Feature Complete: All features merged to main branch
- Build Artifacts: Untagged images available in registry
- Release Decision: Team decides when to cut a release
- Manual Action: Trigger tag cutting workflow with semantic version
- Image Tagging: Existing registry image tagged with version
- Deployment: GitOps picks up tagged image for deployment
Version Strategy
v1.2.3
├── 1: Major version (breaking changes)
├── 2: Minor version (new features)
└── 3: Patch version (bug fixes)
Advantages
Development Velocity
- Fast Feedback: Issues caught in minutes, not after merge
- Parallel Development: Multiple features validated simultaneously
- Independent Evolution: Each service evolves at its own pace
- Reduced Rollbacks: Failed builds never reach main branch
Operational Benefits
- Predictable Performance: Consistent build times
- Simplified Debugging: Service-focused error investigation
- Independent Scaling: Scale pipeline resources per service
- Flexible Releases: Release when ready, not when coordinated
Team Benefits
- Team Autonomy: Each team controls their service pipeline
- Reduced Coordination: Less cross-team synchronization needed
- Technology Choice: Teams can evolve their tech stack independently
- Clear Ownership: Service-specific responsibility and accountability
Challenges
Service Coordination
- Cross-Service Dependencies: Must coordinate breaking changes
- Version Compatibility: Ensure services work together
- Integration Testing: Requires separate integration test strategy
- Data Migration: Coordinate database changes across services
Operational Overhead
- Multiple Pipelines: More pipelines to maintain and monitor
- Consistency: Ensuring standards across independent services
- Monitoring: Distributed observability across services
- Documentation: Keeping service documentation up to date
Best Practices
Feature Branch Development
- Keep Branches Small: Focus on single features or changes
- Fast Iteration: Use quick feedback for rapid iteration
- PR Reviews: Leverage pre-merge validation for quality
- Clean History: Squash commits before merging
Release Management
- Semantic Versioning: Use consistent versioning strategy
- Release Notes: Document changes for each release
- Environment Testing: Test in staging before production
- Rollback Planning: Always have a rollback strategy
Service Independence
- API Contracts: Define and maintain stable interfaces
- Backward Compatibility: Avoid breaking changes when possible
- Service Discovery: Use service discovery for dynamic environments
- Health Checks: Implement comprehensive health endpoints
When to Use Standalone Workflow
Ideal Scenarios
- Fast Iteration: Teams that need rapid development cycles
- Service Independence: Services with minimal interdependencies
- Team Autonomy: Teams that prefer independent decision-making
- Microservices: Service-oriented or microservices architectures
Team Structure
- Service Teams: Each team owns one or more related services
- Platform Team: Provides shared infrastructure and tooling
- DevOps Support: Helps teams optimize their individual pipelines
Technical Fit
- Well-Defined APIs: Services communicate through stable APIs
- Independent Data: Services manage their own data stores
- Bounded Contexts: Clear service boundaries and responsibilities
- Event-Driven: Asynchronous communication patterns
📖 Related Guides
- Troubleshooting Guide: Debug standalone pipeline issues
- NX-Based Workflow: Compare with the monorepo approach
This workflow is ideal for teams that value fast iteration, independence, and predictable performance.