Achas que é correto combinar a compilação, os testes e a publicação da imagem num único workflow, bem como adicionar etapas para o deployment em diferentes ambientes?

Isto nem sempre é ótimo. Embora tal abordagem possa ser conveniente para projetos pequenos ou compilações de teste locais, combinar todas as etapas num único fluxo de trabalho tem desvantagens:

• Redução da flexibilidade: O deployment em diferentes ambientes (dev, staging, produção) requer parâmetros diferentes e muitas vezes diferentes permissões de acesso. A união complica a gestão dessas diferenças.
• Dependência do ambiente: Se o deployment numa das ambientes falhar, toda a build é considerada falhada, mesmo que a criação da imagem e o seu teste tenham sido bem-sucedidos.
• Dificuldade de rollback: Reverter o deployment torna-se menos trivial, pois é necessário reverter todo o workflow.
• Aumento do tempo de execução: Todo o pipeline leva mais tempo, o que desacelera o feedback para os desenvolvedores.
• Menor escalabilidade: À medida que o projeto cresce e aumenta o número de ambientes de deployment, esse workflow torna-se pesado e difícil de gerir.

Uma prática mais comum e flexível é dividir essas etapas:

1. Pipeline de Build & Test: Responsável por compilar o código, testar, criar a imagem e colocá-la no registro de artefatos (por exemplo, Docker Registry, Nexus). Este workflow é iniciado por cada commit ou pull request.
2. Pipeline de Deployment: Workflows separados para deployment em cada ambiente. Eles usam a imagem já construída e testada do registro de artefatos e a deployam no ambiente alvo. Esses workflows podem ser iniciados manualmente, por agendamento ou automaticamente após a conclusão bem-sucedida da etapa anterior (por exemplo, deployment bem-sucedido em staging).

Isso permite:

• Obter feedback mais rápido sobre a qualidade do código (build & test).
• Deploy em diferentes ambientes de forma independente.
• Gerir de forma mais flexível os parâmetros de deployment para cada ambiente.
• Simplificar o processo de rollback.

Uma exceção pode ser projetos pequenos ou aplicações monolíticas com um processo de deployment simples, onde os custos de dividir superam os benefícios. No entanto, na maioria dos ambientes corporativos, dividir o workflow é uma melhor prática.