GitHub Actions no Azure

GitHub Actions é a plataforma integrada de CI/CD e automação do GitHub. Os fluxos de trabalho são definidos em arquivos YAML armazenados no diretório .github/workflows/ do seu repositório e acionados por eventos do GitHub — envios, solicitações de pull, versões e muito mais. O GitHub Actions é profundamente integrado ao ecossistema do GitHub (problemas, PRs, pacotes e verificação de segurança) e oferece um amplo marketplace de ações da comunidade para tarefas como compilação, testes e implantação no Azure.

Um arquivo de fluxo de trabalho do GitHub Actions tem três seções de nível superior. on define os eventos de acionamento. env define as variáveis de ambiente globais. jobs define um ou mais trabalhos, cada um executado em um runner (hospedado pelo GitHub ou auto-hospedado). Cada trabalho tem etapas — run (script de shell) ou uses (uma ação pré-criada). Por padrão, os trabalhos são executados em paralelo; use needs para criar dependências sequenciais.

A forma recomendada de autenticar o GitHub Actions no Azure é o OpenID Connect (OIDC) — ele emite tokens de curta duração sem armazenar segredos de longa duração no GitHub. Configure uma credencial de identidade federada em um registro de aplicativo do Azure ou em uma identidade gerenciada, concedendo confiança ao seu repositório e à sua ramificação do GitHub. Use a ação azure/login@v2 para trocar o token OIDC do GitHub por um token de acesso do Azure — não são necessários segredos do cliente nos GitHub Secrets.

A ação azure/webapps-deploy@v3 implanta código ou uma imagem de contêiner no Azure App Service. Ela gerencia a implantação em slots, a implantação baseada em pacote e a implantação de imagens do Docker. Combine-a com azure/login@v2 para autenticação. Você pode direcioná-la a um slot de preparo, executar testes de fumaça e depois fazer a troca com a ação azure/CLI@v2, que executa o comando de troca de slots — reproduzindo inteiramente no GitHub Actions o padrão de implantação azul-verde do Azure Pipelines.

Faça a implantação no AKS a partir do GitHub Actions usando a ação azure/k8s-deploy@v5. Essa ação usa kubectl apply para implantar manifestos, realiza a substituição da imagem (trocando a etiqueta da imagem pela etiqueta da compilação atual) e monitora a integridade da implantação. A ação azure/aks-set-context@v4 configura as credenciais do kubectl obtendo o kubeconfig do cluster por meio da sessão autenticada do Azure.

Armazene valores confidenciais nos GitHub Secrets — valores criptografados acessíveis como ${{ secrets.SECRET_NAME }} nos fluxos de trabalho. A configuração não confidencial deve ser armazenada nas GitHub Variables — acessíveis como ${{ vars.VARIABLE_NAME }}. Ambos podem ter escopo de repositório, ambiente ou organização. Use ambientes no GitHub Actions para adicionar regras de proteção (revisores obrigatórios e ramificações de implantação), de forma semelhante aos Environments do Azure DevOps.

Os Environments do GitHub Actions (configurados em Settings → Environments do repositório) adicionam portões de implantação semelhantes aos ambientes do Azure DevOps. Você pode exigir revisores obrigatórios, que devem aprovar antes da execução de um trabalho direcionado ao ambiente; restringir as implantações a ramificações específicas (somente main pode implantar em Production); e adicionar temporizadores de espera para atrasar as implantações. Os trabalhos direcionados a um ambiente protegido ficam pausados até que todas as regras de proteção sejam atendidas.

Evite duplicar a lógica de CI/CD entre repositórios usando dois recursos do GitHub Actions. Os fluxos de trabalho reutilizáveis permitem definir um fluxo de trabalho em um repositório e chamá-lo a partir de fluxos de trabalho em outros repositórios usando uses: myorg/shared-workflows/.github/workflows/deploy.yml@main. As ações compostas agrupam várias etapas em uma única ação armazenada em um repositório, reutilizável com uses: myorg/my-actions/deploy@v1. Ambas promovem os princípios DRY nos pipelines de CI/CD da sua organização.

Escolha o GitHub Actions quando: seu código estiver hospedado no GitHub, sua equipe preferir a interface do GitHub, você quiser uma integração estreita com as verificações de PR e a análise de código do GitHub ou estiver desenvolvendo projetos de código aberto (com muitos minutos gratuitos). Escolha o Azure Pipelines quando: precisar de integração com o Azure Boards, de testes avançados com o Azure Test Plans, do gerenciamento de feeds do Azure Artifacts, seu código estiver no Azure Repos ou você precisar de um gerenciamento complexo de versões em várias etapas, com portões em muitos ambientes. Ambos oferecem suporte igualmente bom à implantação no Azure.

O GitHub Actions Marketplace reúne milhares de ações da comunidade e oficiais para tarefas comuns. A Microsoft publica ações oficiais do Azure: azure/login, azure/webapps-deploy, azure/aks-set-context, azure/k8s-deploy, azure/CLI, azure/arm-deploy e muitas outras. Sempre fixe as ações em uma etiqueta de versão específica (por exemplo, @v3) ou em um SHA de confirmação, para evitar ataques à cadeia de fornecimento causados pela atualização de uma ação comprometida com código malicioso.

Os runners hospedados pelo GitHub têm acesso somente à Internet pública — eles não conseguem alcançar recursos privados do Azure (bancos de dados SQL e APIs internas) sem expor esses recursos publicamente. Use runners auto-hospedados em VMs do Azure dentro da sua VNet para implantações em recursos privados. Registre um runner baixando o agente de runner do GitHub Actions, configurando-o com a URL do seu repositório e o token de registro e executando-o como um serviço. Dimensione os runners auto-hospedados com Azure Container Apps para criar conjuntos elásticos de runners.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) apresentados nesta lição.

Nesta lição, você aprendeu que os fluxos de trabalho do GitHub Actions são arquivos YAML em .github/workflows/, acionados por eventos do GitHub e executados em runners; as credenciais federadas OIDC permitem a autenticação no Azure a partir do GitHub Actions sem segredos; e os GitHub Environments com regras de proteção adicionam portões de aprovação às implantações em produção. Isso conclui o curso de Azure DevOps — a seguir, veremos o Azure Monitor e o Log Analytics.