Skip to main content

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)

  1. Code Checkout (10-20 seconds)
  2. Dependency Installation (30-90 seconds)
  3. Build Process (30-120 seconds)
  4. Test Execution (60-180 seconds)
  5. Artifact Validation (10-30 seconds)

Main Branch Pipeline (2-8 minutes)

  1. Validation (2-6 minutes) - Same as feature branch
  2. Docker Build (30-90 seconds)
  3. Registry Push (30-60 seconds)
  4. Metadata Update (10-20 seconds)

Tag Cutting (1-2 minutes)

  1. Image Tagging (10-30 seconds)
  2. Manifest Generation (20-40 seconds)
  3. 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

  1. Feature Complete: All features merged to main branch
  2. Build Artifacts: Untagged images available in registry
  3. Release Decision: Team decides when to cut a release
  4. Manual Action: Trigger tag cutting workflow with semantic version
  5. Image Tagging: Existing registry image tagged with version
  6. 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

  1. Keep Branches Small: Focus on single features or changes
  2. Fast Iteration: Use quick feedback for rapid iteration
  3. PR Reviews: Leverage pre-merge validation for quality
  4. 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


This workflow is ideal for teams that value fast iteration, independence, and predictable performance.