Lançamento e visualização de pipelines ao configurar o GitLab CI / CD para vários projetos.
A Integração Contínua (IC) é a prática de automatizar a montagem e o teste do código antes que ele seja mesclado à ramificação principal. Ele permite que os desenvolvedores injetem código com bastante frequência e cedo, reduzindo o risco de introduzir novos erros no repositório principal de código-fonte.
Embora o IC verifique se o novo código não será quebrado quando integrado a outro código no mesmo repositório, passar todos os testes nesse repositório é apenas a primeira etapa. Após executar o IC no código, é importante implantar e executar testes em um ambiente real. A transição do IC para Entrega e Implantação Contínua (CD) é o próximo passo para os DevOps “adultos”. A implantação e o novo teste subsequente permitem testar o código de um projeto, juntamente com outros componentes e serviços que podem ser gerenciados por outros projetos.
Por que preciso garantir que meu código funcione com outros componentes?
Um bom exemplo é a arquitetura de microsserviços. Normalmente, os microsserviços são gerenciados em diferentes projetos , onde cada microsserviço tem seu próprio repositório com um pipeline. Além disso, muitas vezes cada equipe de desenvolvimento é responsável por microsserviços e configurações de pipeline individuais. Como programador, convém garantir que as alterações no seu código não violem a funcionalidade de seus microsserviços. Portanto, você pode executar testes neles, além de testes para o seu projeto.
Projeto Pipeline Cross
Ao iniciar um pipeline de projeto, você também precisará executar o pipeline entre projetos, que acabará por implantar e testar a versão mais recente de todos os microsserviços dependentes. Para conseguir isso, você precisa de uma maneira simples, flexível e conveniente de iniciar outros pipelines na estrutura do IC do seu projeto. O IC / CD do GitLab oferece uma maneira fácil de iniciar um pipeline entre projetos adicionando uma tarefa especial ao arquivo de configuração do IC.
Arquivo de configuração de IC / CD do GitLab
No GitLab CI / CD, os pipelines, bem como os trabalhos e as etapas de seus componentes são definidos no .gitlab-ci.yml para cada projeto. O arquivo faz parte do repositório do projeto. É totalmente versionado, e os desenvolvedores podem editá-lo usando qualquer IDE de sua escolha. Eles não precisam pedir ao administrador do sistema ou à equipe do DevOps que faça alterações na configuração do pipeline, pois eles mesmos podem fazê-lo. O .gitlab-ci.yml determina a estrutura e a ordem dos pipelines e decide o que precisa ser feito usando o GitLab Runner (o agente que executa as tarefas) e quais decisões devem ser tomadas quando determinadas condições surgirem, por exemplo, quando o processo for concluído com êxito ou sair. sistema
Adição de tarefa para executar o pipeline entre projetos
A partir do GitLab 11.8, o GitLab fornece uma nova sintaxe de configuração de CI / CD para a execução de pipelines entre projetos, que pode ser encontrada nas regras de configuração de pipline . O código a seguir ilustra como configurar um trabalho de ponte para executar um pipeline de downlink:
// job1 job deploy: stage: Deploy script: this is my script // job2 bridge job , - Android: stage: Trigger-cross-projects trigger: mobile/android
No exemplo acima, assim que o trabalho de implantação (tarefa de implantação) no estágio de implantação for bem-sucedido, a tarefa da ponte do Android será iniciada. Seu status inicial estará pendente. O GitLab criará um pipeline downstream no projeto mobile / android e, uma vez criado, o trabalho do Android será bem-sucedido. Nesse caso, mobile / android é o caminho completo para este projeto.
O usuário que criou o pipeline upstream deve ter direitos de acesso ao projeto downstream (neste caso, mobile / android). Se o projeto downstream não puder ser encontrado ou o usuário não tiver direitos de acesso para criar um pipeline, o trabalho do Android receberá o status de falha.
Visão geral dos gráficos do pipeline upstream ao downstream
O CI / CD do GitLab permite visualizar a configuração do pipeline. Na figura abaixo, as etapas de montagem, teste e implantação fazem parte de um projeto upstream. Depois que o trabalho de implantação for concluído com êxito, quatro projetos cruzados serão lançados em paralelo e você poderá prosseguir para eles clicando em um dos trabalhos posteriores.
Na figura abaixo, você pode ver a linha de pagamento descendente "Serviço - Finanças". Agora você pode rolar para a esquerda até o pipeline ascendente, voltar para o pipeline descendente ou selecionar outro pipeline descendente.
Definindo uma ramificação do pipeline filho
Você pode especificar o nome da ramificação que o pipeline descendente usará:
trigger: project: mobile/android branch: stable-11-2
Use a palavra-chave do projeto para indicar o caminho completo para o projeto downstream. Use a palavra-chave branch para determinar o nome do branch. O GitLab usará a confirmação que está atualmente no ramo HEAD ao criar o pipeline de downlink.
Passando variáveis para um pipeline descendente
Algum dia, convém passar variáveis para um pipeline descendente. Você pode fazer isso com palavras-chave para variáveis, como faria com uma definição de trabalho regular.
Android: variable: ENVIRONMENT: 'This is the variable value for the downstream pipeline' stage: Trigger-cross-projects trigger: mobile/android
A variável ENVIRONMENT será passada para cada trabalho definido no pipeline descendente. Ele estará disponível como uma variável de ambiente toda vez que o GitLab Runner selecionar um trabalho.
Pipeline total entre projetos
O .gitlab-ci.yml determina a ordem dos estágios do CI / CD, quais tarefas executar e sob quais condições iniciar ou ignorar a tarefa. A adição de um 'trabalho de ponte' com a palavra-chave trigger nesse arquivo pode ser usada para executar pipelines entre projetos. Podemos passar parâmetros para trabalhos em pipelines descendentes e até definir a ramificação que o pipeline descendente usará.
Os pipelines podem ser estruturas complexas com muitas tarefas sequenciais e paralelas e, como acabamos de aprender, às vezes eles podem executar pipelines a jusante. Para simplificar a compreensão do fluxo do pipeline, incluindo os pipelines a jusante, o GitLab possui gráficos de pipline para visualizar os pipelines e seus status.
Leia também outros artigos em nosso blog: