Skip to content

Azure DevOps Integration

This document explains how the Factory and templates integrate with Azure DevOps (Repos, Pipelines, Boards, Artifacts). It is written for engineers, architects, and DevOps teams who need to understand how ConnectSoft systems interact with Azure DevOps.

The Factory uses Azure DevOps as its primary integration point for code generation, CI/CD, work management, and artifact distribution. All generated code is committed to Azure DevOps repositories, with pipelines, work items, and packages managed through Azure DevOps services.

Important

Azure DevOps is a required dependency for the Factory. All generated code is committed to Azure DevOps repositories, and CI/CD pipelines are configured through Azure DevOps Pipelines.

What We Use Azure DevOps For

ConnectSoft uses Azure DevOps for:

  • Source Control - Git repositories for generated code
  • CI/CD - Build, test, and deployment pipelines
  • Work Management - Epics, Features, Tasks, and work item tracking
  • Artifacts - NuGet packages for ConnectSoft.Extensions.* libraries
  • Project Management - Project organization and team collaboration

Repos and Branching

Repository Creation

The Factory creates repositories in Azure DevOps:

  • One Repository Per Microservice - Each generated microservice gets its own repository
  • Standard Naming - Repositories follow naming conventions (e.g., {ProductName}.{ServiceName})
  • Initial Commit - Factory commits generated code to the default branch (typically main)

Branching Strategy

The Factory follows ConnectSoft's branching strategy:

  • Default Branch - main (or master if configured)
  • Feature Branches - feature/{feature-name} for new features
  • Factory Branches - factory/{run-id} for Factory-generated code
  • Release Branches - release/{version} for release preparation (if used)

See: Branching & Git Strategy for detailed branching guidelines.

Branch Naming Conventions

Branch Type Pattern Example Purpose
Default main or master main Production-ready code
Feature feature/{name} feature/user-authentication New features
Factory factory/{run-id} factory/run-20260101-001 Factory-generated code
Hotfix hotfix/{name} hotfix/security-patch Critical fixes
Release release/{version} release/v1.2.0 Release preparation

Pipelines and Templates

Pipeline Generation

The Factory generates CI/CD pipeline definitions:

  • YAML Pipelines - Azure Pipelines YAML files
  • Standard Stages - Build, test, quality gates, deploy
  • Template Usage - Reusable pipeline templates
  • Environment Configuration - Dev, staging, production environments

Pipeline Structure

Generated pipelines follow this structure:

flowchart LR
    A[Source Code] --> B[Build Stage]
    B --> C[Test Stage]
    C --> D[Quality Gates]
    D --> E{Pass?}
    E -->|Yes| F[Package Stage]
    E -->|No| G[Fail]
    F --> H[Deploy Stage]
    H --> I[Production]

    style A fill:#e1f5ff
    style B fill:#fff4e1
    style C fill:#e8f5e9
    style D fill:#fff4e1
    style F fill:#e8f5e9
    style H fill:#f3e5f5
Hold "Alt" / "Option" to enable pan & zoom

See: CI/CD Guidelines for detailed pipeline patterns.

Pipeline Templates

Microservice templates include standard pipeline templates:

  • Build Template - Standard build steps
  • Test Template - Test execution and coverage
  • Deploy Template - Deployment to Azure environments
  • Quality Gates - Code quality, security scanning, compliance checks

Boards and Work Items

Work Item Creation

The Factory creates work items in Azure DevOps Boards:

  • Epics - High-level product features
  • Features - Detailed feature specifications
  • Tasks - Implementation tasks
  • Bugs - Defects found during QA

Work Item Linking

The Factory links code to work items:

  • Commits - Git commits reference work items (#123)
  • Pull Requests - PRs link to work items
  • Branches - Branch names reference work items
  • Builds - Builds associate with work items

Work Item Structure

Work Item Type Created By Purpose Example
Epic Vision & Planning Agents High-level product features "User Authentication System"
Feature Architect Agents Detailed features "OAuth2 Authorization Flow"
Task Engineering Agents Implementation tasks "Implement Token Endpoint"
Bug QA Agents Defects and issues "Token validation fails for expired tokens"

Artifacts and Packages

NuGet Packages

ConnectSoft libraries are distributed via Azure DevOps Artifacts:

  • ConnectSoft.Extensions.* - Core libraries
  • Version Management - Semantic versioning
  • Package Feeds - Organization-scoped feeds
  • Dependency Resolution - NuGet package restore

Package Usage

Generated microservices reference ConnectSoft packages:

  • Package References - Standard NuGet package references
  • Version Pinning - Specific versions for stability
  • Package Restore - Automatic restore during build
  • Private Feeds - Access to ConnectSoft private feeds

Tip

Best Practices: - Use specific package versions (avoid wildcards) - Reference packages from ConnectSoft feeds - Keep package versions consistent across services - Update packages through controlled processes

Common Patterns and Best Practices

Repository Organization

  • One Repo Per Microservice - Isolated repositories for each service
  • Monorepo Alternative - Consider monorepo for related services (advanced)
  • Clear Naming - Use consistent naming conventions

Pipeline Patterns

  • Template Reuse - Use pipeline templates for consistency
  • Environment Gates - Require approvals for production deployments
  • Quality Gates - Enforce code quality and test coverage
  • Parallel Execution - Run tests and builds in parallel

Work Item Patterns

  • Link Everything - Link commits, PRs, and builds to work items
  • Clear Titles - Use descriptive work item titles
  • Acceptance Criteria - Define clear acceptance criteria
  • Epic Hierarchy - Organize work items in epic hierarchies

Package Management

  • Version Strategy - Use semantic versioning
  • Feed Organization - Organize packages by namespace
  • Access Control - Control who can publish packages
  • Dependency Updates - Regular dependency updates

Tip

Common Patterns: 1. One Repo Per Microservice - Simplifies CI/CD and access control 1. Template for Pipeline Naming - Consistent pipeline names ({service}-build, {service}-deploy) 1. Linking PRs to Work Items - Use #123 syntax in PR descriptions 1. Version Pinning - Pin package versions in .csproj files 1. Quality Gates - Require code coverage and quality checks before merge