codewithmukesh/dotnet-claude-kit

ci-cd

CI/CD pipelines for .NET applications.

Ver código-fonte
Documento original do Skill

Renderizado do repositório de origem, preservando títulos, exemplos, código, tabelas, links e imagens.

CI/CD

Core Principles

  1. Pipeline as code — YAML pipelines committed to the repo. No click-ops in the UI.
  2. Fast feedback — Build and test on every push. Cache NuGet packages. Fail fast.
  3. Build once, deploy many — Build the artifact once, promote it through environments (dev → staging → production).
  4. Never skip tests — Tests gate the pipeline. No deployment without passing tests.

Patterns

GitHub Actions — Build + Test

yaml
# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  DOTNET_VERSION: '10.0.x'
  DOTNET_NOLOGO: true
  DOTNET_CLI_TELEMETRY_OPTOUT: true

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:18
        env:
          POSTGRES_DB: testdb
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    steps:
      - uses: actions/checkout@v5

      - name: Setup .NET
        uses: actions/setup-dotnet@v5
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }}

      - name: Restore
        run: dotnet restore

      - name: Build
        run: dotnet build --no-restore --configuration Release

      - name: Format check
        run: dotnet format --verify-no-changes --no-restore

      - name: Test
        run: dotnet test --no-build --configuration Release --logger trx --results-directory TestResults
        env:
          ConnectionStrings__Default: "Host=localhost;Database=testdb;Username=postgres;Password=postgres"

      - name: Publish test results
        uses: actions/upload-artifact@v5
        if: always()
        with:
          name: test-results
          path: TestResults/*.trx

GitHub Actions — Build + Publish Docker Image

yaml
# .github/workflows/publish.yml
name: Publish

on:
  push:
    tags: ['v*']

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v5

      - name: Login to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract version from tag
        id: version
        run: echo "VERSION=${GITHUB_REF#refs/tags/v}" >> $GITHUB_OUTPUT

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            ghcr.io/${{ github.repository }}:${{ steps.version.outputs.VERSION }}
            ghcr.io/${{ github.repository }}:latest

Azure DevOps — Build + Test

Same restore → build → format → test flow as GitHub Actions. Key differences:

yaml
# azure-pipelines.yml
trigger:
  branches:
    include: [main]
  paths:
    exclude: ['*.md', docs/]

pool:
  vmImage: 'ubuntu-latest'          # vs runs-on: ubuntu-latest

variables:
  dotnetVersion: '10.0.x'

# Key task differences from GitHub Actions:
#   Setup .NET:  task: UseDotNet@2  (inputs: version: $(dotnetVersion))
#   Test results: task: PublishTestResults@2  (testResultsFormat: VSTest)
#   Steps use `script:` + `displayName:` instead of `- name:` + `run:`
#   Services (e.g., Postgres) require a separate Docker task or pipeline service connection

NuGet Package Publishing

yaml
# Part of GitHub Actions workflow
- name: Pack
  run: dotnet pack src/MyLibrary -c Release -o ./nupkg --no-build

- name: Push to NuGet
  run: dotnet nuget push ./nupkg/*.nupkg --api-key ${{ secrets.NUGET_API_KEY }} --source https://api.nuget.org/v3/index.json

Anti-patterns

Don't Build Different Artifacts per Environment

yaml
# BAD — building separately for each environment
- script: dotnet publish -c Debug   # for dev
- script: dotnet publish -c Release # for prod

# GOOD — build once, deploy everywhere
- script: dotnet publish -c Release -o ./publish
# Then deploy the same ./publish artifact to dev, staging, prod

Don't Skip Format Checks in CI

yaml
# BAD — no format enforcement
steps:
  - run: dotnet build
  - run: dotnet test

# GOOD — format check catches style issues early
steps:
  - run: dotnet build
  - run: dotnet format --verify-no-changes
  - run: dotnet test

Don't Hardcode Secrets in Pipelines

yaml
# BAD — secret in pipeline YAML
env:
  DB_PASSWORD: "my-secret-password"

# GOOD — use pipeline secrets
env:
  DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

Decision Guide

ScenarioRecommendation
Open source projectGitHub Actions
Enterprise with AzureAzure DevOps Pipelines
Docker deploymentMulti-stage build in CI, push to container registry
NuGet libraryBuild → Test → Pack → Push on tag
Database migrationsRun in CI test stage, script for production
Environment promotionSame artifact, different configuration
do mesmo repositório

Mais Skills

Todos os Skills
codewithmukesh
Comunidade

api-versioning

API versioning strategies for ASP.NET Core. Covers Asp.Versioning library, URL segment, header, and query string strategies, version deprecation, and OpenAPI integration. Load this skill when adding versioning to an API, evolving an API with breaking changes, or when the user mentions "API version", "versioning", "v1/v2", "Asp.Versioning", "deprecation", "breaking change", or "backward compatibility".

instalações
2
GitHub Stars
692
Atualizado
7 de ago.
codewithmukesh
Comunidade

arch-check

Architecture conformance check: verifies an existing codebase against its declared architecture (VSA, Clean Architecture, DDD, Modular Monolith) — dependency direction, layer violations, module boundary leaks, and cycles — using token-cheap Roslyn MCP analysis. Invoke when: "check architecture", "architecture violations", "layer violations", "dependency direction", "module boundaries", "arch check", "is my architecture clean", "enforce architecture", "conformance check". For CHOOSING an architecture, use architecture-advisor instead.

instalações
2
GitHub Stars
692
Atualizado
7 de ago.
codewithmukesh
Comunidade

architecture-advisor

Architecture selection advisor for .NET applications. Asks structured questions about domain complexity, team size, system lifetime, compliance, and integration needs, then recommends the best-fit architecture: Vertical Slice, Clean Architecture, DDD + Clean Architecture, or Modular Monolith. Load this skill when the user asks "which architecture", "choose architecture", "set up project", "new project", "architecture decision", "restructure", or "how should I organize". Always load BEFORE any architecture-specific skill.

instalações
2
GitHub Stars
692
Atualizado
7 de ago.
codewithmukesh
Comunidade

aspire

.NET Aspire for cloud-native orchestration. Covers AppHost configuration, service defaults, resource configuration, service discovery, and the Aspire dashboard. Load this skill when setting up local development orchestration, service discovery, or Aspire-managed infrastructure, or when the user mentions "Aspire", "AppHost", "service defaults", "service discovery", "orchestration", "Aspire dashboard", "AddProject", "WithReference", or "cloud-native .NET".

instalações
2
GitHub Stars
692
Atualizado
7 de ago.