Azure Fundamentals · Урок

Сквозной рабочий процесс разработчика

«Сквозной рабочий процесс разработчика» — бесплатный урок Azure Fundamentals на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Azure Fundamentals, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Azure Fundamentals содержит 4 уроков всего.

Современный цикл разработки в Azure

Современный рабочий процесс разработчика в Azure объединяет управление исходным кодом, CI/CD, контейнерную инфраструктуру и наблюдаемость в бесшовный внутренний цикл — от фиксации кода до наблюдаемого рабочего окружения. Основные компоненты: GitHub (исходный код), GitHub Actions (конвейер сборки и развёртывания), Azure Container Registry (хранилище образов), Azure Container Apps (среда выполнения) и Application Insights (наблюдаемость). Каждое изменение автоматически проходит путь от компьютера разработчика до рабочего окружения за считаные минуты, а на каждом этапе действуют проверки качества.

Шаг 1: управление исходным кодом и стратегия ветвления

Организуйте код в репозитории GitHub, используя разработку на основе основной ветки или стратегию ветвления GitFlow. Для большинства микросервисов разработка на основе основной ветки (короткоживущие функциональные ветки, ежедневно объединяемые с main) уменьшает количество конфликтов интеграции и упрощает конвейер. Настройте правила защиты ветки для main, чтобы перед объединением требовались проверки запросов на слияние и успешное прохождение проверок CI. Файл CODEOWNERS гарантирует, что изменения в критически важных службах должны быть одобрены старшими инженерами соответствующей команды.

# Example .github/CODEOWNERS
# Require payments-team review for any changes under /src/payments/
/src/payments/ @payments-team
/infrastructure/   @platform-team

Шаг 2: CI с GitHub Actions

Конвейер CI запускается для каждого запроса на слияние. Типичный рабочий процесс: получить код → восстановить зависимости → запустить модульные тесты → запустить интеграционные тесты → собрать образ Docker → отправить его в Azure Container Registry. Образу присваивается тег с SHA фиксации Git для отслеживания. Используйте аутентификацию на основе OIDC из GitHub Actions в Azure (через федеративное удостоверение), чтобы не хранить секреты субъектов-служб Azure в GitHub — это эквивалент управляемого удостоверения для конвейеров CI.

# .github/workflows/ci.yml (abbreviated)
name: CI
on: [pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login to ACR
        uses: azure/docker-login@v1
        with:
          login-server: myacr.azurecr.io
          username: ${{ secrets.AZURE_CLIENT_ID }}
          password: ${{ secrets.AZURE_CLIENT_SECRET }}
      - name: Build and push image
        run: |
          docker build -t myacr.azurecr.io/myapi:${{ github.sha }} .
          docker push myacr.azurecr.io/myapi:${{ github.sha }}

Шаг 3: CD в промежуточную среду

После успешного выполнения конвейера CI при объединении с main конвейер CD автоматически развёртывает приложение в промежуточной среде. Конвейер обновляет тег образа приложения Container App до только что созданного SHA, ожидает, пока новая ревизия станет работоспособной, и запускает дымовые тесты для URL промежуточной среды. Дымовые тесты проверяют, что критически важные конечные точки API возвращают ожидаемые ответы. Если дымовые тесты завершаются с ошибкой, конвейер выполняет откат, переключая входящий трафик обратно на предыдущую ревизию без ручного вмешательства.

# CD stage: update Container App to new image
- name: Deploy to staging
  uses: azure/cli@v2
  with:
    azcliversion: latest
    inlineScript: |
      az containerapp update \
        --name myapi-staging \
        --resource-group myRG \
        --image myacr.azurecr.io/myapi:${{ github.sha }}

- name: Run smoke tests
  run: |
    STAGING_URL=$(az containerapp show --name myapi-staging \
      --resource-group myRG \
      --query 'properties.configuration.ingress.fqdn' -o tsv)
    curl -f https://$STAGING_URL/health || exit 1

Шаг 4: этап утверждения для рабочего окружения

После проверки в промежуточной среде конвейер CD приостанавливается на этапе утверждения. Защита сред GitHub Actions позволяет настроить обязательных проверяющих для среды production. Конвейер отправляет уведомление в Slack дежурному инженеру, который перед утверждением проверяет результаты тестов в промежуточной среде, различия и все открытые инциденты. Только после утверждения конвейер продолжает развёртывание того же образа с этим SHA в рабочее окружение. Этот этап с участием человека особенно важен для высоконагруженных или регулируемых служб.

# In GitHub: create 'production' environment with required reviewers
# .github/workflows/cd.yml (abbreviated)
jobs:
  deploy-production:
    environment:
      name: production
      url: https://myapi.contoso.com
    needs: deploy-staging
    steps:
      - name: Deploy to production
        uses: azure/cli@v2
        with:
          inlineScript: |
            az containerapp update \
              --name myapi \
              --resource-group myRG \
              --image myacr.azurecr.io/myapi:${{ github.sha }}

Шаг 5: наблюдаемость рабочего окружения

После развёртывания в рабочем окружении Application Insights предоставляет данные в реальном времени. Пакет SDK App Insights (или автоматическая инструментализация для поддерживаемых сред выполнения) отслеживает: частоту запросов, частоту сбоев и задержку (три основных сигнала), вызовы зависимостей (баз данных, Service Bus и других API), а также исключения с полными трассировками стека. Карта приложения визуализирует взаимодействие служб и показывает, какие зависимости вносят наибольший вклад в сбои или задержку.

# Python: Add Application Insights SDK
from opencensus.ext.azure.log_exporter import AzureLogHandler
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.trace.samplers import ProbabilitySampler
from opencensus.trace.tracer import Tracer

tracer = Tracer(
  exporter=AzureExporter(connection_string='InstrumentationKey=<key>'),
  sampler=ProbabilitySampler(1.0)
)

Связывание развёртываний с трассировками

Используйте аннотации Application Insights, чтобы отмечать события развёртывания на графиках метрик. После создания аннотации выпуска (через действие GitHub Actions azure/appinsights-annotation) она отображается в виде вертикальной линии на всех графиках метрик App Insights. Благодаря этому сразу видно, связаны ли скачок задержки или рост частоты ошибок с недавним развёртыванием, что значительно сокращает среднее время диагностики (MTTD) во время инцидентов.

# Create a release annotation in Application Insights
- name: Annotate release in App Insights
  uses: azure/appinsights-annotation@v1
  with:
    appInsightsResourceName: myAppInsights
    resourceGroupName: myRG
    releaseName: '${{ github.run_id }}-${{ github.sha }}'

Автоматический откат при скачке частоты ошибок

Для наиболее отказоустойчивых конвейеров реализуйте автоматический откат. После развёртывания в рабочем окружении конвейер ожидает 10 минут и запрашивает в Application Insights частоту ошибок. Если частота ошибок превышает настраиваемый порог (например, >5%), конвейер автоматически выполняет откат, направляя 100% входящего трафика Container App на предыдущую ревизию. Этот шаблон постепенной поставки уменьшает радиус поражения неудачного развёртывания и позволяет командам уверенно развёртывать даже сложные или чувствительные изменения.

# Query App Insights error rate via REST (abbreviated)
QUERY='requests | where timestamp > ago(10m) | summarize failed = countif(success == false), total = count() | extend errorRate = round(100.0 * failed / total, 2)'
RESULT=$(az monitor app-insights query \
  --apps myAppInsights \
  --resource-group myRG \
  --analytics-query "$QUERY" \
  --query 'tables[0].rows[0][2]' -o tsv)
if [ $(echo '$RESULT > 5' | bc -l) -eq 1 ]; then
  echo 'Error rate $RESULT% - rolling back!'
  az containerapp ingress traffic set --name myapi --resource-group myRG --revision-weight stable=100
fi

Производительность разработчиков: локальная разработка с эмуляторами

Разработчики должны иметь возможность локально запускать и тестировать весь стек без подключения к рабочим ресурсам Azure. Используйте эмулятор Azure Storage (Azurite) для локального блочного и очередного хранилища, эмулятор Cosmos DB для локального тестирования базы данных и эмулятор Service Bus для локального обмена сообщениями. Переменная среды AZURE_ENVIRONMENT=local может переключить DefaultAzureCredential на строки подключения к эмуляторам, тогда как тот же код в Azure использует управляемое удостоверение. Docker Compose координирует все локальные зависимости с помощью одной команды docker compose up.

# docker-compose.yml for local development
services:
  azurite:
    image: mcr.microsoft.com/azure-storage/azurite
    ports:
      - '10000:10000'
      - '10001:10001'
  cosmos-emulator:
    image: mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator
    ports:
      - '8081:8081'

Безопасность в рабочем процессе разработчика

Интегрируйте безопасность на каждом этапе рабочего процесса разработчика: Dependabot проверяет зависимости на наличие уязвимостей в запросах на слияние; GitHub Advanced Security (сканирование кода с помощью CodeQL) обнаруживает такие уязвимости, как внедрение SQL и жёстко заданные секреты; Microsoft Defender for DevOps интегрируется с GitHub и отображает рекомендации по безопасности Azure вместе с изменениями кода; а сканирование уязвимостей ACR Defender проверяет образы контейнеров на наличие CVE в ОС и на уровне приложений после каждой отправки. Результаты проверок безопасности появляются в комментариях к запросам на слияние, поэтому их можно устранить до объединения изменений.

Объединение всех компонентов

Полный рабочий процесс разработчика представляет собой непрерывный цикл обратной связи: разработчик фиксирует код, CI собирает и тестирует образ контейнера, образ отправляется в ACR с SHA фиксации в качестве тега, CD развёртывает его в промежуточной среде и запускает дымовые тесты, человек утверждает развёртывание в рабочем окружении, конвейер развёртывает образ и создаёт аннотацию выпуска, а Application Insights отслеживает частоту ошибок и выполняет автоматический откат при превышении порогов. Инфраструктура как код (Bicep или Terraform) в том же репозитории обеспечивает версионный контроль конвейера, Container App и конфигурации мониторинга вместе с кодом приложения.

Быстрая проверка

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900), рассмотренных в этом уроке.

Итоги урока

В этом уроке вы узнали, что сквозной рабочий процесс разработчика объединяет управление исходным кодом в GitHub, CI/CD в GitHub Actions, Azure Container Registry, Container Apps и Application Insights; аннотации выпусков связывают развёртывания с изменениями метрик для более быстрой диагностики инцидентов; а автоматический откат на основе запросов о частоте ошибок уменьшает радиус поражения неудачных развёртываний. Далее мы перейдём к подготовке к экзамену и всестороннему повторению облачных концепций и архитектуры Azure.

Часто задаваемые вопросы

Урок «Сквозной рабочий процесс разработчика» бесплатный?

Да — полный текст урока «Сквозной рабочий процесс разработчика» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Azure Fundamentals, подпишись на CoddyKit PRO. Курс Azure Fundamentals содержит 4 уроков всего.

Чему я научусь в уроке «Сквозной рабочий процесс разработчика»?

Объедините GitHub Actions CI/CD, Azure Container Registry, Container Apps и Application Insights в полный внутренний цикл разработки — от фиксации изменений до наблюдаемой рабочей среды. Ты практикуешь Azure Fundamentals с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Azure Fundamentals?

Предыдущий опыт не требуется. Azure Fundamentals на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.

Сколько времени занимает урок «Сквозной рабочий процесс разработчика»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Azure Fundamentals?

Да. Каждый урок Azure Fundamentals включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

Управляемое удостоверение для аутентификации без паролей
Azure Service Bus для слабосвязанного обмена сообщениями
Azure Container Apps
Сквозной рабочий процесс разработчика

← Назад к Azure Fundamentals