День 1587. #ЗаметкиНаПолях #DevOps
Создаём Конвейер CI/CD в GitHub Actions
Благодаря CI/CD вы можете значительно сократить объем ручных операций и больше сосредоточиться на создании ПО, обеспечивая более быстрые и надёжные развёртывания.

CI/CD — это метод автоматизации рабочего процесса разработки и развёртывания ПО. Непрерывная интеграция (CI) - это процесс автоматизации синхронизации нового кода с репозиторием. Любые изменения в коде приложения немедленно собираются, тестируются и объединяются. Непрерывная доставка или развёртывание (CD) обеспечивает развёртывание изменений в производственную (или другую) среду.

Если вы используете GitHub, вы можете использовать GitHub Actions, чтобы создавать рабочие процессы сборки и тестирования каждого коммита в вашем репозитории или развёртывания в рабочую среду при создании нового тега.

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

name: Build & Test

on:
  push:
    branches:
    - main

env:
  DOTNET_VERSION: "7.0.x"

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

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

      - name: Install dependencies
        run: dotnet restore WebApi

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

      - name: Test
        run: dotnet test WebApi --configuration Release --no-build

Здесь мы:
- Определяем событие для запуска рабочего процесса (при коммите в ветку main)
- Настраиваем.NET SDK с версией из env.DOTNET_VERSION
- Восстанавливаем зависимости, затем собираем и тестируем проект с помощью команд dotnet CLI

Добавив это действие в свой репозиторий GitHub, вы начнёте получать мгновенную обратную связь после каждого коммита. При сбое выполнения рабочего процесса из-за ошибки сборки или неудачного теста вы получите уведомление на email.

Непрерывная доставка - реальная ценность процесса CI/CD. Вы делаете изменение, и уже через несколько минут ваш код собран, протестирован и выложен в рабочую среду. Вот пример сценария развёртывания:

name: Publish

on:
  push:
    branches:
    - main

env:
  AZURE_WEBAPP_NAME: web-api
  AZURE_WEBAPP_PACKAGE_PATH: "./publish"
  DOTNET_VERSION: "7.0.x"

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

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

      - name: Build and Publish
        run: |
          dotnet restore WebApi
          dotnet build WebApi -c Release --no-restore
          dotnet publish WebApi -c Release --no-build
            --output '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}'

      - name: Deploy to Azure
        uses: azure/webapps-deploy@v2
        with:
          app-name: ${{ env.AZURE_WEBAPP_NAME }}
          publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
          package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}'

Он очень похож на предыдущий, со следующими отличиями:
- Добавление шага публикации и настройка выходного пути
- Использование действия azure/webapps-deploy@v2 для развёртывания в Azure.

Если вам нужно безопасно и надёжно использовать секретные данные в рабочих процессах, вы можете определить секреты GitHub и использовать их в действиях, не добавляя их в систему управления версиями. В примере выше использован secrets.AZURE_PUBLISH_PROFILE для доступа к профилю публикации в экземпляре App Service.

Источник: https://www.milanjovanovic.tech/blog/build-ci-cd-pipeline-with-github-actions-and-dotnet