Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- pres:gerti:devops:como_criar_uma_pipeline_de_ci_cd:start [17/03/2026 17:28] – ↷ Nome da página alterado de pres:gerti:devops:como_criar_uma_pipeline_de_ci_cd:introducao para pres:gerti:devops:como_criar_uma_pipeline_de_ci_cd:start lvinicius
+++ pres:gerti:devops:como_criar_uma_pipeline_de_ci_cd:start [19/03/2026 15:08] (atual) – removida lvinicius
@@ Linha 1: / Linha 1: @@
-====== Como criar uma pipeline de CI/CD ======
-Este guia irá te ensinar a configurar a pipeline de CI/CD do seu repositório integrando totalmente com a nossa infraestrutura.
-===== Objetivo =====
-Ao final de todos os passos, você terá uma pipeline que:
-  - Faz **deploy em produção** quando há commit na ''main''
-  - Faz **deploy em homologação** quando há commit na ''develop''
-  - Realiza [[..:versionamento_semantico]] automaticamente
-  - Executa **testes** automatizados
-Este guia está dividido em partes. **Nesta primeira parte**, você vai configurar o **deploy em produção**.
-===== Pré-requisitos =====
-  - Antes de começar, se seu projeto ainda não possui uma **Dockerfile** funcional, veja [[..:como_envelopar_meu_projeto_com_docker]].
-  - Se não conhece o **Gitflow**, vale a pena ver como é a nossa [[pres:gerti:padronizacao_git:start|Padronização do Git]].
-===== Conceitos: Jobs e Estágios =====
-Para implementar as pipelines do GitLab, é importante saber que ela funciona com **Jobs** organizados em **Estágios**, como uma linha de montagem.
-Vamos apresentar brevemente esses conceitos pois, com a biblioteca [[https://gitsource.tce.go.gov.br/GER-TI/tce.kubernetes/tce.templates|TCE.Templates]], não será necessário escrever os jobs na mão — apenas saber como eles funcionam.
-Para mais informações, veja: [[https://docs.gitlab.com/ci/jobs/|CI/CD Jobs]] e [[https://docs.gitlab.com/ci/pipelines/|CI/CD Pipelines]].
-==== Job ====
-Cada Job é um script (definido por nós, desenvolvedores) que realiza alguma tarefa: executar um **teste**, fazer o **versionamento**, realizar o **deploy**... Um exemplo de job de testes seria:
-<code yaml>
-test-job:  # Nome do job, pode ser qualquer nome
-  image: python:3.10-alpine
-  stage: test
-  before_script:
-    - pip install pytest
-  script:
-    - pytest # Comando que efetivamente executa os tests
-  allow_failure: false
-  tags:
-    - docker-pipes-runner  # Servidor onde ele será executado
-</code>
-  * ''test-job'' — nome do Job.
-  * ''image: python:3.10-alpine'' — roda dentro de um container [[..:docker]] com essa imagem.
-  * ''stage: test'' — será executado durante o estágio de testes.
-  * ''script: pytest'' — o comando que executa os testes.
-  * ''before_script: pip install pytest'' — instala a dependência antes de rodar.
-  * ''allow_failure: false'' — se o ''pytest'' retornar erro, interrompe os próximos estágios.
-**Dica**: O ''allow_failure: false'' funciona como um Quality Gate: previne que código com erros chegue à produção.
-==== Estágios ====
-Se os **Jobs** são as tarefas, os **Estágios** são o cronograma da linha de montagem. Eles definem a **ordem de execução**: o estágio 2 só começa quando o estágio 1 terminar com sucesso. Jobs no mesmo estágio rodam em paralelo.
-<code yaml>
-# A ordem aqui define a ordem de execução
-stages:
-  - lint                  # 1. Verifica estilo e erros de sintaxe
-  - tests                 # 2. Executa os testes automatizados
-  - sonar                 # 3. Analisa cobertura e segurança (Quality Gate)
-  - semantic-release      # 4. Gera versão e Changelog se tudo acima passou
-  - build                 # 5. Gera o pacote/imagem da nova versão
-  - deploy                # 6. Publica no ambiente de destino
-</code>
-===== Parte 1: Deploy em Produção =====
-==== 1. Acessando o Editor de Pipeline ====
-O GitLab centraliza a configuração da pipeline no arquivo ''.gitlab-ci.yml''. Para editá-lo:
-  - No menu lateral do seu projeto, acesse **Compilação > Editor de pipeline**.
-  - Caso o arquivo ainda não exista, o GitLab oferecerá um modelo padrão. Apague o conteúdo inicial para começarmos do zero.
-==== 2. Declarando os Estágios ====
-No topo do arquivo, declare o estágio de ''deploy'' que utilizaremos nesta etapa:
-<code yaml>
-stages:
-  - deploy
-</code>
-> Mais estágios serão adicionados nas próximas partes do tutorial.
-==== 3. Importando o Componente de Deploy ====
-Para garantir simplicidade e padronização, não escrevemos scripts complexos em cada projeto. Em vez disso, importamos componentes pré-configurados da nossa biblioteca central, o **TCE.Templates**.
-  * No topo do Editor de Pipeline, clique em **Catálogo de CI/CD** > **TCE.Templates**. (Aqui é possível ver a documentação dos componentes)
-  * Localize o componente ''deploy-docker''.
-  * Adicione o bloco de inclusão no seu arquivo:
-<code yaml>
-stages:
-  - deploy
-include:
-  - component: $CI_SERVER_FQDN/GER-TI/tce.kubernetes/tce.templates/deploy-docker@2.0.0  # Sempre especifique a versão
-    inputs:
-      environment: "production"
-      compose-file: "docker-compose.yml"
-      tag: dockers-prod-runner
-</code>
-O ''environment: "production"'' instrui o componente a realizar o deploy no ambiente de produção quando houver commit na branch ''main'' ou ''master''.
-O ''tag: dockers-prod-runner'' indica qual servidor irá receber o deploy. Para ver quais tags estão disponíveis veja [[https://gitsource.tce.go.gov.br/groups/GER-TI/-/runners]]. Para saber qual tag utilizar, veja [[..:gitlab_runners]]. Em nosso caso, como estamos fazendo deploy em produção, iremos colocar no servidor de produção ''vmdocker-01.tce.go.gov.br'', e seu runner tem a tag ''dockers-prod-runner''.
-> Os componentes funcionam como funções: você passa os parâmetros necessários (inputs) e a automação sabe como se comportar no seu projeto.
-=== Boas práticas: Especifique a versão ===
-----
-No final do ''component'' perceba que há um ''@2.0.0'' que especifica qual versão da biblioteca utilizar.
-É **extremamente** recomendado especificar qual versão da biblioteca você está utilizando, pois sua pipeline não terá chances de quebrar caso haja atualizações da biblioteca.
-Na escrita deste artigo, a versão mais atual é a versão `2.0.0`. É recomendado sempre utilizar a versão mais recente.
->
-=== Dica: Atualizando a pipeline ===
-----
-Futuramente, caso haja alguma mudança na padronização, uma nova versão da [[https://gitsource.tce.go.gov.br/GER-TI/tce.kubernetes/tce.templates|TCE.Templates]] será lançada. Para atualizar a sua pipeline, bastará apenas atualizar para a nova versão. //Extremamente Elegante.//
-==== 4. Habilitando o Runner no Projeto ====
-Os runners são os servidores que executam os jobs da pipeline. Por padrão, runners de grupo não ficam habilitados automaticamente em projetos novos — é necessário ativá-los manualmente.
-. No menu lateral do projeto, acesse **Configurações > CI/CD**.
-. Expanda a seção **Executores** (Runners).
-. Na lista de **Executores de grupo disponíveis**, localize o runner com a tag ''dockers-prod-runner''.
-. Clique no botão **Habilitar** ao lado dele.
-> Se pular este passo, a pipeline ficará travada com status **"pending"** e uma mensagem indicando que não há runners disponíveis para o job.
-==== 5. Validar e Commitar ====
-- Utilize a aba **Visualizar** no editor para garantir que a sintaxe está correta.
-- Se tudo estiver certo, clique em **Commit changes** no final da página.
-- Faça o commit direto na branch ''main''.
-Sua pipeline vai rodar imediatamente. Acesse **Compilação > Pipelines** para acompanhar a execução.
-==== O que esperar ====
-Após o commit na ''main'', você deve ver:
-- Um pipeline criado automaticamente.
-- O estágio ''deploy'' sendo executado.
-- O job finalizando com sucesso (ícone verde ✓).
-Se o job falhar, acesse o log do job clicando nele para investigar o erro.
-===== Próximos Passos =====
-  * **Parte 2**: [[..:configurando_o_deploy_em_homologacao]] — adicionar deploy na branch ''develop'' com gitflow
-  * **Parte 3**: Adicionando o job de Semantic Release
-  * **Parte 4**: Adicionando o job de Testes
-===== FAQ =====