Что использовал для deploy?

Практики и инструменты для деплоя в C# Backend проектах

В своей практике я использовал различные подходы и инструменты для деплоя, которые эволюционировали вместе с развитием экосистемы .NET и облачных технологий.

Основные стратегии деплоя

1. Традиционный IIS деплой (для legacy-проектов):

<!-- Пример конфигурации web.config для IIS -->
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" 
           path="*" 
           verb="*" 
           modules="AspNetCoreModuleV2" 
           resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" 
                arguments=".\MyApp.dll" 
                stdoutLogEnabled="true" 
                stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

2. Контейнеризация с Docker:

# Пример Dockerfile для ASP.NET Core приложения
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 8080
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyApp/MyApp.csproj", "MyApp/"]
RUN dotnet restore "MyApp/MyApp.csproj"
COPY . .
RUN dotnet build "MyApp/MyApp.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "MyApp/MyApp.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

CI/CD пайплайны

Azure DevOps:

# azure-pipelines.yml пример
trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    projects: '**/*Tests/*.csproj'

- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: true
    arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'

GitHub Actions:

# .github/workflows/deploy.yml
name: Deploy to Azure

on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    
    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: '8.0.x'
        
    - name: Restore dependencies
      run: dotnet restore
      
    - name: Build
      run: dotnet build --configuration Release --no-restore
      
    - name: Publish
      run: dotnet publish -c Release -o ./publish
      
    - name: Deploy to Azure Web App
      uses: azure/webapps-deploy@v2
      with:
        app-name: 'my-aspnet-app'
        publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
        package: './publish'

Оркестрация и управление инфраструктурой

Kubernetes манифесты:

# deployment.yaml для Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:latest
        ports:
        - containerPort: 80
        env:
        - name: "ConnectionStrings__DefaultConnection"
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: connection-string
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80
  type: LoadBalancer

Инструменты инфраструктуры как кода (IaC)

• Terraform для провайдеров Azure/AWS/GCP
• Bicep для Azure Resource Manager
• Ansible для конфигурации серверов

Мониторинг и логирование после деплоя

Стек для наблюдения за приложением:

• Application Insights для телеметрии и APM
• Seq или ELK-стек для централизованного логирования
• Grafana + Prometheus для метрик
• Health Checks для мониторинга состояния сервисов

Особенности для различных типов приложений

Для микросервисной архитектуры:

• Сервисная сеть (Istio/Linkerd)
• GitOps подход с ArgoCD/Flux
• Canary-деплой и feature flags

Для serverless-решений:

• Azure Functions с ZIP-деплоем
• AWS Lambda через контейнеры или сборки
• Интеграция с API Gateway

Ключевые практики, которые я всегда применяю:

• Blue-Green деплой для минимизации downtime
• Автоматическое тестирование в пайплайне
• Роллбек-стратегии на случай проблем
• Версионирование артефактов через семантическое версионирование
• Использование секретов из Key Vault/Secret Manager

Эволюция подходов к деплою показывает переход от ручных операций на физических серверах к полностью автоматизированным GitOps-практикам, где каждый коммит может автоматически разворачиваться в продакшн через проверенные пайплайны с полным контролем качества и откатом изменений при необходимости.