Padrões de CI/CD com o Workflow Orchestration Manager

Importante

A partir de 1 de janeiro de 2026, já não poderá criar novas instâncias Airflow usando o Workflow Orchestration Manager do ADF. Recomendamos que migre todas as cargas de trabalho do Workflow Orchestration Manager (Apache Airflow no Azure Data Factory) para trabalhos Apache Airflow no Microsoft Fabric antes de 31 de dezembro de 2025.

Para mais informações ou apoio durante a sua migração para o Apache Airflow no Microsoft Fabric, contacte o Suporte da Microsoft.

O Workflow Orchestration Manager fornece uma maneira simples e eficiente de criar e gerenciar ambientes Apache Airflow. O serviço permite que você execute pipelines de dados em escala com facilidade. Há dois métodos principais para executar DAGs no Workflow Orchestration Manager. Você pode carregar os arquivos DAG em seu armazenamento de blob e vinculá-los ao ambiente Airflow. Como alternativa, você pode usar o recurso Git-sync para sincronizar automaticamente seu repositório Git com o ambiente Airflow.

Trabalhar com pipelines de dados no Airflow exige que você crie ou atualize seus DAGs, plug-ins e arquivos de requisitos com frequência, com base em suas necessidades de fluxo de trabalho. Embora os desenvolvedores possam carregar ou editar manualmente arquivos DAG no armazenamento de blobs, muitas organizações preferem usar uma abordagem de integração contínua e entrega contínua (CI/CD) para implantação de código. Este artigo orienta você pelos padrões de implantação recomendados para integrar e implantar perfeitamente seus DAGs Apache Airflow com o Workflow Orchestration Manager.

Compreender CI/CD (Integração Contínua/Desdobramento Contínuo)

Integração contínua

A integração contínua é uma prática de desenvolvimento de software que enfatiza a integração frequente e automatizada de alterações de código em um repositório compartilhado. Ele envolve desenvolvedores confirmando regularmente seu código e, após cada confirmação, um pipeline de CI automatizado cria o código, executa testes e executa verificações de validação. Os principais objetivos são detetar e resolver problemas de integração no início do processo de desenvolvimento e fornecer feedback rápido aos desenvolvedores.

A CI garante que a base de código permaneça em um estado constantemente testável e implantável. Essa prática leva a uma melhor qualidade do código, colaboração e a capacidade de detetar e corrigir bugs antes que eles se tornem problemas significativos.

Entrega contínua

A entrega contínua é uma extensão da IC que leva a automação um passo adiante. Enquanto o CI se concentra em automatizar as fases de integração e teste, o CD automatiza a implantação de alterações de código em ambientes de produção ou outros ambientes de destino. Essa prática ajuda as organizações a lançar atualizações de software de forma rápida e confiável. Ele reduz erros na implantação manual e garante que as alterações de código aprovadas sejam entregues aos usuários rapidamente.

Fluxo de trabalho de CI/CD no Workflow Orchestration Manager

Captura de tela que mostra o padrão CI/CD que pode ser usado no Workflow Orchestration Manager.

Sincronização do Git com o tempo de execução da integração Dev/QA

Mapeie seu ambiente do Workflow Orchestration Manager com a ramificação de desenvolvimento/QA do repositório Git.

Pipeline de CI com runtime de integração Dev/QA

Quando um pull request (PR) é feito de uma ramificação de funcionalidade para a ramificação de desenvolvimento, ele dispara um pipeline de PR. Este pipeline foi projetado para executar com eficiência verificações de qualidade nas suas ramificações de funcionalidades, garantindo a integridade e a confiabilidade do código. Você pode incluir os seguintes tipos de verificações no pipeline:

  • Teste de dependências do Python: Esses testes instalam e verificam a correção das dependências do Python para garantir que as dependências do projeto estejam configuradas corretamente.
  • Análise de código e linting: Ferramentas para análise estática de código e linting são utilizadas para avaliar a qualidade do código e a conformidade com os padrões de codificação.
  • Testes DAG de fluxo de ar: Esses testes executam testes de validação, incluindo testes para a definição de DAG e testes de unidade projetados para DAGs de fluxo de ar.
  • Testes de unidade para operadores, ganchos, sensores e gatilhos personalizados do Airflow

Se qualquer uma dessas verificações falhar, o pipeline será encerrado. Em seguida, você precisa resolver os problemas identificados.

Sincronização do Git com o runtime de integração de produção

Mapeie seu ambiente do Workflow Orchestration Manager com a ramificação de produção do repositório Git.

Pipeline de PR com runtime de integração de produção

Uma prática recomendada é manter um ambiente de produção separado para evitar que todos os recursos de desenvolvimento se tornem acessíveis ao público.

Depois de a ramificação de funcionalidade ser mesclada com êxito na ramificação de desenvolvimento, pode criar um pull request para a ramificação de produção para tornar o seu recurso recém-mesclado público. Essa pull request aciona o pipeline de PR que executa verificações rápidas de qualidade no ramo de desenvolvimento. As verificações de qualidade garantem que todos os recursos foram integrados corretamente e que não há erros no ambiente de produção.

Benefícios do uso do fluxo de trabalho de CI/CD no Workflow Orchestration Manager

  • Abordagem fail-fast: Sem a integração do processo de CI/CD, é provável que a primeira vez que se tome consciência de que o DAG contém erros seja quando ele é enviado por push para o GitHub, sincronizado com o Workflow Orchestration Manager e lança um Import Error. Enquanto isso, outro desenvolvedor pode, sem saber, extrair o código defeituoso do repositório, o que potencialmente leva a ineficiências no futuro.
  • Melhoria da qualidade do código: Se você negligenciar verificações fundamentais, como verificação de sintaxe, importações necessárias e verificações de outras práticas recomendadas de codificação, aumentará a probabilidade de fornecer código abaixo do par.

Padrões de implantação no Workflow Orchestration Manager

Recomendamos dois padrões de implantação.

Padrão 1: Desenvolver pipelines de dados diretamente no Workflow Orchestration Manager

Você pode desenvolver pipelines de dados diretamente no Workflow Orchestration Manager ao usar o padrão 1.

Pré-requisitos

  • Se não tiver uma subscrição do Azure, crie uma conta gratuita antes de começar. Crie ou selecione uma instância existente do Data Factory na região onde a visualização do Workflow Orchestration Manager é suportada.
  • Você precisa acessar um repositório GitHub.

Vantagens

  • Não é necessário um ambiente de desenvolvimento local: O Workflow Orchestration Manager lida com a infraestrutura subjacente, atualizações e manutenção, reduzindo a sobrecarga operacional do gerenciamento de clusters de fluxo de ar. O serviço permite que você se concentre na criação e gerenciamento de fluxos de trabalho em vez de gerenciar a infraestrutura.
  • Escalabilidade: O Workflow Orchestration Manager fornece capacidade de dimensionamento automático para dimensionar recursos conforme necessário, garantindo que seus pipelines de dados possam lidar com cargas de trabalho crescentes ou picos de atividade sem intervenção manual.
  • Monitorização e registo: O Workflow Orchestration Manager inclui logs de diagnóstico e monitoramento para ajudá-lo a acompanhar a execução de seus fluxos de trabalho, diagnosticar problemas, configurar alertas e otimizar o desempenho.

Workflow

  1. Use o recurso Git-sync.

    Neste fluxo de trabalho, não há nenhum requisito para estabelecer seu próprio ambiente local. Em vez disso, você pode começar usando o recurso de sincronização Git oferecido pelo Workflow Orchestration Manager. Esse recurso sincroniza automaticamente seus arquivos DAG com servidores web, agendadores e trabalhadores do Airflow. Agora você pode desenvolver, testar e executar seus pipelines de dados diretamente por meio da interface do usuário do Workflow Orchestration Manager.

    Saiba mais sobre como usar o recurso Git-sync do Workflow Orchestration Manager.

  2. Crie ambientes de ramos de funcionalidade individuais.

    Você pode escolher a ramificação do repositório para sincronizar com o Workflow Orchestration Manager. Este recurso permite criar um ambiente Airflow individual para cada ramificação de funcionalidades. Dessa forma, os desenvolvedores podem trabalhar em tarefas específicas para pipelines de dados.

  3. Crie uma solicitação pull.

    Prossiga para enviar um pull request para o runtime de integração do ambiente de desenvolvimento do Airflow após desenvolver e testar completamente as suas funcionalidades no seu ambiente Airflow dedicado.

Padrão 2: Desenvolver DAGs localmente e implantar no Workflow Orchestration Manager

Você pode desenvolver DAGs localmente e implantá-los no Workflow Orchestration Manager ao usar o padrão 2.

Pré-requisitos

  • Você precisa acessar um repositório GitHub.
  • Certifique-se de que pelo menos uma única ramificação do repositório de código esteja sincronizada com o Workflow Orchestration Manager para ver as alterações de código no serviço.

Vantagens

Pode limitar o acesso aos recursos do Azure apenas a administradores.

Workflow

  1. Configure um ambiente local.

    Comece configurando um ambiente de desenvolvimento local para o Apache Airflow em sua máquina de desenvolvimento. Nesse ambiente, você pode desenvolver e testar seu código Airflow, incluindo DAGs e tarefas. Essa abordagem permite que você desenvolva pipelines sem depender do acesso direto aos recursos do Azure.

  2. Use o recurso Git-sync.

    Sincronize a ramificação do repositório GitHub com o Workflow Orchestration Manager.

    Saiba mais sobre como usar o recurso Git-sync do Workflow Orchestration Manager.

  3. Use o Workflow Orchestration Manager como um ambiente de produção.

    Depois de desenvolveres e testares com êxito pipelines de dados na tua configuração local, podes gerar um pull request para a ramificação sincronizada com o Workflow Orchestration Manager. Depois que a ramificação for mesclada, use os recursos do Workflow Orchestration Manager, como dimensionamento automático, monitoramento e registro em log no nível de produção.

Exemplo de pipeline de CI/CD

Para obter mais informações, consulte:

  1. Copie o código de um DAG implantado no runtime de integração do Workflow Orchestration Manager usando o recurso Git-sync.

    from datetime import datetime
from airflow import DAG
from airflow.operators.bash import BashOperator

with DAG(
    dag_id="airflow-ci-cd-tutorial",
    start_date=datetime(2023, 8, 15),
    schedule="0 0 * * *",
    tags=["tutorial", "CI/CD"]
) as dag:
    # Tasks are represented as operators
    task1 = BashOperator(task_id="task1", bash_command="echo task1")
    task2 = BashOperator(task_id="task2", bash_command="echo task2")
    task3 = BashOperator(task_id="task3", bash_command="echo task3")
    task4 = BashOperator(task_id="task4", bash_command="echo task4")

    # Set dependencies between tasks
    task1 >> task2 >> task3 >> task4

  2. Crie um pipeline de CI/CD. Você tem duas opções: ações do Azure DevOps ou GitHub.

    1. Opção Azure DevOps: crie o arquivo azure-devops-ci-cd.yaml e copie o código a seguir. O pipeline é acionado em uma solicitação pull ou push request para a ramificação de desenvolvimento:

      trigger:
- dev

pr:
- dev

pool:
  vmImage: ubuntu-latest
strategy:
  matrix:
    Python3.11:
      python.version: '3.11.5'

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '$(python.version)'
  displayName: 'Use Python $(python.version)'

- script: |
    python -m pip install --upgrade pip
    pip install -r requirements.txt
  displayName: 'Install dependencies'

- script: |
    airflow webserver &
    airflow db init
    airflow scheduler &
    pytest
  displayName: 'Pytest'

      Para obter mais informações, consulte Azure Pipelines.

    2. Opção de ações do GitHub: crie um .github/workflows diretório no repositório do GitHub.

      1. .github/workflows No diretório, crie um arquivo chamado github-actions-ci-cd.yml.

      2. Copie o código a seguir. O pipeline é acionado sempre que há um pedido de pull request ou push para o ramo de desenvolvimento.

        name: GitHub Actions CI/CD

on:
  pull_request:
    branches:
      - "dev"
  push:
    branches:
      - "dev"

jobs:
  flake8:
    strategy:
      matrix:
        python-version: [3.11.5]
    runs-on: ubuntu-latest
    steps:
      - name: Check out source repository
        uses: actions/checkout@v4
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: ${{matrix.python-version}}
      - name: flake8 Lint
        uses: py-actions/flake8@v1
        with:
          max-line-length: 120
  tests:
    strategy:
      matrix:
        python-version: [3.11.5]
    runs-on: ubuntu-latest
    needs: [flake8]
    steps:
      - uses: actions/checkout@v4
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: ${{matrix.python-version}}
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
      - name: Pytest
        run: |
          airflow webserver &
          airflow db init
          airflow scheduler &
          pytest tests/

  3. Na pasta de testes, crie os testes para DAGs do Airflow. Eis alguns exemplos:

    1. No mínimo, é crucial realizar testes iniciais usando import_errors para garantir a integridade e a correção do DAG. Este teste garante:

      • Seu DAG não contém ciclicidade: A ciclicidade, onde uma tarefa forma um loop ou dependência circular dentro do fluxo de trabalho, pode levar a loops de execução inesperados e infinitos.

      • Não há erros de importação: Erros de importação podem surgir devido a problemas como dependências ausentes, caminhos de módulo incorretos ou erros de codificação.  

      • As tarefas são definidas corretamente: Confirme se as tarefas no DAG estão definidas corretamente.

        @pytest.fixture()

def dagbag():
    return DagBag(dag_folder="dags")

def test_no_import_errors(dagbag):
    """
    Test Dags to contain no import errors.
    """
    assert not dagbag.import_errors

    2. Teste para garantir que IDs de DAG específicas estejam presentes em sua ramificação de recurso antes de mesclá-las na ramificação de desenvolvimento.

      def test_expected_dags(dagbag):
    """
    Test whether expected dag Ids are present.
    """
    expected_dag_ids = ["airflow-ci-cd-tutorial"]

    for dag_id in expected_dag_ids:
        dag = dagbag.get_dag(dag_id)

        assert dag is not None
        assert dag_id == dag.dag_id

    3. Teste para garantir que apenas tags aprovadas estejam associadas aos seus DAGs. Esse teste ajuda a impor o uso da tag aprovada.

      def test_requires_approved_tag(dagbag):
    """
    Test if DAGS contain one or more tags from list of approved tags only.
    """
    Expected_tags = {"tutorial", "CI/CD"}
    dagIds = dagbag.dag_ids

    for id in dagIds:
        dag = dagbag.get_dag(id)
        assert dag.tags
        if Expected_tags:
            assert not set(dag.tags) - Expected_tags

  4. Agora, quando fazes um pull request para o branch de desenvolvimento, podes ver que as ações do GitHub disparam o pipeline CI para executar todos os testes.

Conteúdo relacionado

  • Last updated on