Se você está começando a estudar desenvolvimento de software, provavelmente já encontrou termos como CI/CD, pipeline, GitLab Runner, build, artifacts, Docker e deploy. O problema é que, quando esses conceitos aparecem todos juntos, é fácil decorar comandos sem realmente entender o que está acontecendo.
Neste artigo, vamos construir esse entendimento do zero.
A ideia é usar uma situação simples como analogia e, a partir dela, transformar o conceito em uma implementação real usando GitLab. O objetivo não é criar a pipeline mais sofisticada possível, mas entender os fundamentos necessários para conseguir ler, escrever, modificar e solucionar problemas em uma pipeline de CI/CD.
No final, você terá uma visão de como uma alteração de código pode ser automaticamente construída, testada e transformada em uma imagem Docker.
Antes de falar de CI/CD, imagine uma fábrica
Imagine uma fábrica que produz computadores.
Um funcionário monta as peças. Outro verifica se o computador liga. Outro realiza testes mais específicos. Depois, o produto é embalado e armazenado para distribuição.
Seria estranho colocar um computador recém-montado diretamente na caixa sem verificar se ele funciona.
Seria ainda mais estranho descobrir um defeito depois que centenas de unidades já foram distribuídas.
No desenvolvimento de software, o problema é parecido.
Uma pessoa escreve código, outra altera uma funcionalidade existente, outra modifica uma configuração. Em algum momento, essas alterações precisam ser integradas. A grande pergunta é: como saber rapidamente se aquilo que foi produzido continua funcionando?
É exatamente aí que entra a Integração Contínua.
1. O que significa Continuous Integration?
Continuous Integration (CI), ou Integração Contínua, é uma prática de desenvolvimento em que as alterações de código são integradas frequentemente e submetidas a verificações automatizadas.
Na prática, isso pode significar que, quando um desenvolvedor envia uma alteração para o GitLab, o sistema automaticamente executa tarefas como:
Instalar dependências
Executar build
Executar testes
Se tudo funcionar, a alteração passa pelas verificações.
Se alguma etapa falhar, a equipe descobre o problema rapidamente.
Martin Fowler descreve Continuous Integration como a integração frequente das alterações em uma base compartilhada, acompanhada de um build automatizado que inclui testes para detectar problemas de integração rapidamente.
A Red Hat também descreve CI como a integração automática e frequente de mudanças em um repositório compartilhado.
A ideia mais importante aqui é simples:
CI não existe para "deixar o projeto moderno". Ela existe para detectar problemas cedo.
2. E o que significa CD?
O termo CD pode representar duas ideias diferentes: Continuous Delivery e Continuous Deployment.
No Continuous Delivery, o software passa por um processo automatizado de construção e validação e fica preparado para ser entregue. A implantação final ainda pode depender de uma decisão ou ação manual.
No Continuous Deployment, a implantação também é automatizada.
Uma maneira simples de diferenciar:
Continuous Integration
Código
Build
Testes
Continuous Delivery
Código
Build
Testes
Artefato pronto para entrega
Continuous Deployment
Código
Build
Testes
Deploy automático
Esses conceitos fazem parte de uma mesma ideia de automação, mas não precisam ser implementados todos de uma vez. Para quem está começando, entender CI primeiro costuma ser muito mais importante do que tentar automatizar todo o processo de implantação logo no início.
3. A pipeline é a linha de produção
Agora podemos voltar à nossa fábrica.
A pipeline é a linha de produção completa.
Ela representa o conjunto de etapas que o software precisa atravessar para chegar ao resultado desejado.
No GitLab, pipelines são configuradas normalmente em um arquivo chamado .gitlab-ci.yml. Elas podem ser disparadas por diferentes eventos, como commits, Merge Requests ou execução manual.
Um exemplo simples de pipeline seria:
Build → Testes → Empacotamento
Não precisamos interpretar isso como uma lista de comandos. Pense na pipeline como uma sequência de responsabilidades.
Primeiro perguntamos:
"O sistema consegue ser construído?"
Depois:
"O sistema está se comportando como esperado?"
E, por fim:
"Conseguimos preparar esse resultado para ser distribuído?"
Essa forma de pensar ajuda muito mais do que simplesmente decorar sintaxe YAML.
4. Pipeline, Stage e Job
Agora aparecem três palavras que todo iniciante precisa entender.
Uma pipeline é o processo completo.
Um stage é uma etapa lógica desse processo.
Um job é uma tarefa executada dentro de um stage.
Podemos imaginar uma estrutura como esta:
Pipeline
├── Build
│ └── build-app
├── Test
│ ├── unit-tests
│ └── lint
└── Docker
└── build-image
O GitLab executa os stages na ordem definida. Dentro de um mesmo stage, jobs podem ser executados em paralelo quando houver runners disponíveis.
Essa diferença é importante porque uma pipeline pode possuir dezenas de jobs sem necessariamente possuir dezenas de stages.
5. Quem executa os jobs?
A essa altura surge outra pergunta.
Quem realmente executa os comandos?
O GitLab Runner.
O GitLab gerencia a pipeline, mas os jobs precisam ser executados por um agente capaz de fornecer um ambiente de execução.
O Runner recebe o job, executa os comandos definidos e devolve o resultado ao GitLab.
Se tivermos:
script:
- npm ci
- npm test
o Runner será responsável por executar esses comandos.
Essa distinção resolve uma dúvida comum: GitLab e GitLab Runner não são exatamente a mesma coisa.
O GitLab organiza e gerencia o processo. O Runner executa o trabalho.
6. Criando a primeira pipeline
A melhor maneira de aprender é começar pequeno.
Crie um arquivo chamado:
.gitlab-ci.yml
e coloque:
stages:
- build
- test
build:
stage: build
script:
- echo "Executando build"
test:
stage: test
script:
- echo "Executando testes"
Nesse momento, não estamos construindo uma aplicação real.
Estamos apenas testando nossa infraestrutura.
Se o GitLab conseguir executar esses dois jobs com sucesso, já confirmamos várias coisas:
- o arquivo está sendo interpretado;
- existe um Runner disponível;
- os stages estão sendo reconhecidos;
- os jobs estão sendo executados;
- a pipeline consegue chegar ao final.
A documentação oficial do GitLab possui um tutorial específico para esse primeiro contato.
7. Agora precisamos de um ambiente para nossa aplicação
Até aqui usamos apenas echo.
Agora imagine que nosso projeto seja uma aplicação web construída com Node.js.
O Runner precisa de um ambiente capaz de executar Node e npm.
Uma forma prática de fornecer esse ambiente é utilizar uma imagem Docker como ambiente do job:
default:
image: node:24
Com isso, podemos alterar nossa pipeline:
stages:
- build
- test
default:
image: node:24
build:
stage: build
script:
- npm ci
- npm run build
test:
stage: test
script:
- npm ci
- npm test
Aqui começamos a sair da teoria.
Agora a pipeline está realmente trabalhando com o projeto.
8. Por que npm ci aparece tanto em CI/CD?
Quem está começando em Node.js geralmente conhece:
npm install
Mas é muito comum encontrar:
npm ci
em pipelines.
O motivo é que npm ci foi projetado para instalações automatizadas, como ambientes de integração contínua. Ele exige um lockfile existente e utiliza esse arquivo para realizar uma instalação limpa e previsível. Se package.json e package-lock.json estiverem inconsistentes, o comando falha em vez de alterar o lockfile automaticamente.
Podemos pensar no package-lock.json como uma especificação das versões das dependências que devem ser utilizadas.
Isso reduz a chance de um cenário como:
"Na minha máquina funciona, mas no ambiente da pipeline veio outra versão de uma dependência."
Não significa que npm install esteja errado. Significa que os dois comandos possuem objetivos diferentes.
9. Build: a primeira inspeção
Agora temos nosso primeiro estágio real:
build:
stage: build
script:
- npm ci
- npm run build
O papel desse job é bastante claro:
verificar se a aplicação consegue ser construída.
Se o npm run build funcionar, o job termina com sucesso.
Se o comando retornar erro, o job falha.
Isso é importante porque uma alteração que impede a aplicação de ser construída não precisa esperar a revisão manual de alguém para ser descoberta.
A própria documentação do GitLab utiliza build como exemplo de uma tarefa típica de um job de CI/CD.
10. Mas uma aplicação que compila pode estar errada
Imagine que nosso computador seja montado perfeitamente.
Isso prova que as peças foram encaixadas, mas ainda não prova que o computador está funcionando corretamente.
Software é igual.
Uma aplicação pode compilar sem erros e ainda possuir bugs.
Por isso precisamos de testes.
Essa é a segunda grande responsabilidade da nossa pipeline:
Build
Testes
O build responde:
"Consigo produzir a aplicação?"
Os testes respondem:
"Ela está se comportando como esperado?"
11. Testes automatizados
Um teste unitário, por exemplo, pode verificar uma função ou uma pequena unidade do sistema isoladamente.
Suponha que exista um serviço responsável por calcular o valor final de um pedido.
Podemos escrever testes que verifiquem diferentes situações:
Pedido com um produto
Pedido com vários produtos
Pedido sem produtos
Desconto aplicado
Valor inválido
Não precisamos confiar apenas em alguém abrir a aplicação manualmente e testar esses cenários toda vez que uma alteração for feita.
Podemos transformar essas verificações em código e executá-las automaticamente.
No Angular atual, novos projetos criados pelo Angular CLI utilizam Vitest como configuração padrão de testes, e o próprio Angular possui documentação específica sobre a execução de testes em CI.
12. Um detalhe importante sobre testes no CI
Existe uma diferença entre executar testes localmente e executá-los em uma pipeline.
Durante o desenvolvimento, ng test pode utilizar watch mode, observando alterações nos arquivos e executando os testes novamente.
Em ambientes de CI, queremos que os testes executem e terminem.
A documentação atual do Angular explica que ng test detecta o ambiente de CI e pode executar em modo de execução única; caso seja necessário forçar esse comportamento, --no-watch e --no-progress podem ser utilizados.
Por isso, não devemos simplesmente copiar um comando de desenvolvimento para a pipeline sem entender como ele se comporta naquele ambiente.
Esse é um bom exemplo de uma ideia importante em DevOps:
Automação não é copiar comandos do terminal; é adaptar o processo ao ambiente em que ele será executado.
13. Quando um teste falha, isso é uma coisa boa
Essa frase pode parecer estranha no começo.
Imagine que nosso código tenha um bug.
Sem testes automatizados, podemos descobrir o problema apenas depois de integrar a alteração.
Com testes, temos a possibilidade de descobrir o problema antes.
Por exemplo:
Build: PASS
Testes: FAIL
A pipeline interrompe o processo.
Isso não significa que a pipeline "quebrou o projeto".
Na verdade, ela descobriu que o projeto já estava com um problema.
Esse é um dos maiores valores da CI.
14. Merge Requests: onde tudo começa a fazer sentido
Agora podemos conectar a pipeline ao fluxo de desenvolvimento.
Imagine que você esteja trabalhando em uma branch:
feature/login
Depois de implementar sua alteração, você envia o código para o GitLab e abre um Merge Request.
Podemos configurar a CI para executar uma pipeline nesse contexto.
O GitLab oferece suporte específico a Merge Request Pipelines, que podem ser configuradas por regras utilizando CI_PIPELINE_SOURCE == "merge_request_event".
Isso cria uma situação muito útil:
Seu código não precisa ser integrado imediatamente à branch principal.
Primeiro, ele passa pelas verificações automatizadas.
Assim, o Merge Request passa a ser mais do que um pedido de merge: ele também se torna um ponto de validação técnica.
15. Um exemplo de rules
Podemos definir:
test:
stage: test
script:
- npm test
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
A palavra rules é importante porque permite controlar quando um job deve executar.
O GitLab oferece diversas possibilidades para essa lógica, incluindo condições baseadas na origem da pipeline, branch e alterações de arquivos.
Esse recurso se torna especialmente útil quando a pipeline cresce.
16. E o resultado do build?
Imagine que o build da aplicação gere uma pasta:
dist/
Agora temos um resultado concreto.
O GitLab pode armazenar esse resultado como um artifact.
build:
stage: build
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
A ideia de um artifact é simples: é um arquivo ou conjunto de arquivos produzidos por um job e preservados para serem usados posteriormente ou baixados pela equipe.
O GitLab permite armazenar outputs de build e outros resultados de jobs como artifacts.
17. Artifact e cache não são a mesma coisa
Esse é um daqueles conceitos que parecem pequenos, mas fazem diferença.
Um artifact é uma saída importante da execução.
Por exemplo:
dist/
Já o cache serve principalmente para melhorar o desempenho de execuções futuras.
Imagine nossa fábrica novamente.
O artifact é o produto que saiu da produção.
O cache é uma caixa de ferramentas que deixamos preparada para não precisar buscar as mesmas ferramentas novamente.
A documentação do GitLab trata artifacts e cache como mecanismos diferentes: artifacts preservam outputs dos jobs, enquanto cache é utilizado principalmente para acelerar execuções futuras.
18. Agora podemos falar de Docker
Até aqui, a pipeline consegue construir e testar nossa aplicação.
Mas ainda precisamos pensar em como executar esse software de maneira consistente.
É aqui que entra Docker.
Uma imagem Docker funciona como um pacote contendo aquilo que precisamos para executar determinado software.
Podemos pensar na nossa fábrica novamente.
Até agora produzimos e inspecionamos o produto.
Agora precisamos colocá-lo em uma embalagem padronizada.
No caso de uma aplicação web, podemos ter algo como:
Aplicação construída
Dockerfile
Imagem Docker
A documentação oficial do Docker explica os conceitos fundamentais de imagens, containers e construção de aplicações containerizadas.
19. Um Dockerfile simples
Para uma aplicação Angular que será servida como conteúdo estático por Nginx, um exemplo simplificado é:
FROM nginx:alpine
COPY dist/ /usr/share/nginx/html/
EXPOSE 80
Não é importante decorar esse arquivo agora.
O importante é compreender o que ele representa.
FROM define a imagem de base.
COPY coloca os arquivos da aplicação dentro da imagem.
EXPOSE documenta a porta utilizada pelo serviço.
A imagem resultante pode ser executada como container.
20. Primeiro faça o Docker funcionar localmente
Antes de adicionar Docker ao GitLab CI, precisamos verificar se ele funciona localmente.
Construímos a imagem:
docker build -t minha-aplicacao .
Depois executamos:
docker run -p 8080:80 minha-aplicacao
Agora podemos acessar a aplicação localmente.
Essa etapa é muito importante.
Se o Dockerfile não funciona na sua máquina, adicionar um Runner no meio da história só vai tornar o problema mais difícil de investigar.
Uma boa prática de engenharia é reduzir o número de variáveis desconhecidas.
Primeiro:
Docker funciona localmente?
Depois:
Docker funciona dentro da pipeline?
Essa ordem economiza muito tempo.
21. Docker dentro da pipeline
Depois que a imagem estiver funcionando localmente, podemos adicionar um novo stage:
stages:
- build
- test
- docker
E então criar um job responsável pela construção da imagem:
docker-build:
stage: docker
script:
- docker build -t minha-aplicacao .
Aqui existe um detalhe importante: esse exemplo é conceitual.
A forma como Docker será executado dentro de um GitLab Runner depende da configuração do Runner e do executor utilizado. O GitLab possui documentação específica para diferentes estratégias de uso do Docker em CI/CD.
Esse é um ponto em que vale parar de copiar tutoriais e começar a entender a infraestrutura.
22. Onde guardar a imagem?
Depois de construir a imagem, precisamos de um lugar para armazená-la.
É aqui que entra um Container Registry.
Podemos utilizar o próprio GitLab Container Registry.
A ideia é que a pipeline construa uma imagem e publique essa imagem no registry para que ela possa ser utilizada posteriormente.
Uma imagem poderia ser identificada por uma versão, por exemplo:
minha-aplicacao:1.0.0
ou por um identificador associado ao commit.
Isso ajuda a responder uma pergunta importante:
"Qual código gerou esta imagem?"
Quanto mais um sistema cresce, mais importante se torna essa rastreabilidade.
23. Não coloque credenciais no YAML
Suponha que seja necessário autenticar no registry.
Nunca faça algo como:
PASSWORD: "minha-senha"
e envie isso para o Git.
Credenciais e outros valores sensíveis devem ser armazenados nas variáveis de CI/CD do GitLab.
A pipeline pode então acessar a variável sem que o valor seja incorporado diretamente ao código-fonte.
O GitLab possui uma seção específica de documentação sobre CI/CD Variables e segurança de variáveis.
Essa ideia vale para tokens, senhas, chaves e outras credenciais.
24. Nossa pipeline está começando a tomar forma
Depois de entender cada parte, podemos juntar os conceitos.
Uma pipeline inicial poderia ser:
stages:
- build
- test
default:
image: node:24
build:
stage: build
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
test:
stage: test
script:
- npm ci
- npm test
Essa pipeline já faz algo importante.
Ela garante que o projeto seja construído e testado automaticamente.
Não precisamos começar adicionando Docker, registry, segurança, deploy e dezenas de outras etapas.
Primeiro fazemos o básico funcionar.
25. Depois adicionamos Docker
Com o básico estável, podemos evoluir:
stages:
- build
- test
- docker
Então:
build
test
docker
A ideia é que o processo de containerização aconteça apenas depois das validações anteriores.
Em outras palavras, não faz muito sentido produzir uma imagem de um software que nem passou pelo build ou pelos testes definidos pela equipe.
26. Por que não criar uma pipeline gigantesca logo no começo?
Esse é um erro bastante comum.
A pessoa descobre CI/CD e tenta adicionar imediatamente:
Build
Testes
Lint
Coverage
SonarQube
Security
Docker
Registry
Deploy
E2E
Performance
Rollback
O resultado costuma ser uma pipeline difícil de entender e ainda mais difícil de corrigir.
Uma pipeline deve crescer conforme as necessidades do projeto.
Uma progressão mais saudável é:
Build
Build + Testes
Build + Testes + Artifacts
Build + Testes + Docker
Build + Testes + Docker + Registry
Não existe prêmio por ter o arquivo .gitlab-ci.yml mais comprido.
27. A pipeline como uma barreira de qualidade
Quando o processo está funcionando, podemos pensar na pipeline como uma série de verificações.
Uma alteração de código precisa passar por critérios objetivos antes de avançar.
Por exemplo:
Build passou?
Testes passaram?
Imagem foi construída?
Isso não significa que a pipeline substitui a revisão humana.
Ela não sabe, sozinha, se uma arquitetura é boa.
Ela não sabe se um nome de classe está adequado.
Ela não entende completamente uma decisão de negócio.
Essas responsabilidades continuam pertencendo aos desenvolvedores.
A pipeline automatiza aquilo que é objetivo, repetitivo e verificável.
28. CI não é sinônimo de deploy
Outro erro comum é pensar:
"Se não existe deploy automático, então não existe CI/CD."
Isso não é verdade.
Uma pipeline que automaticamente executa build e testes já está implementando práticas de Continuous Integration.
O GitLab descreve CI/CD como um processo contínuo que automatiza construção, testes e, quando aplicável, implantação e outras etapas do ciclo de entrega.
O deploy automático é apenas uma possibilidade posterior.
29. Como estudar CI/CD sem decorar YAML
Uma boa forma de aprender é estudar cada conceito junto com uma pequena implementação.
Aprenda o que é uma pipeline e crie uma pipeline mínima.
Aprenda o que é um job e crie um job.
Aprenda o que é um stage e crie dois stages.
Aprenda sobre Runner e observe onde o comando realmente é executado.
Aprenda sobre testes e coloque um teste real dentro da pipeline.
Aprenda sobre artifacts e faça o build gerar um arquivo que possa ser recuperado depois.
Aprenda Docker e construa a imagem localmente.
Depois coloque esse processo na CI.
Essa estratégia é muito mais eficiente do que consumir horas de conteúdo antes de escrever a primeira linha do .gitlab-ci.yml.
30. Um exercício simples para começar
Crie um projeto vazio no GitLab e adicione:
stages:
- build
- test
build:
stage: build
script:
- echo "Meu build está funcionando"
test:
stage: test
script:
- echo "Meus testes estão funcionando"
Faça o commit e observe a pipeline.
Depois altere o job de teste:
test:
stage: test
script:
- echo "Executando testes"
- exit 1
Agora o job deve falhar.
Essa pequena experiência ensina um conceito fundamental: a pipeline utiliza o código de saída dos comandos para determinar o sucesso ou falha do job.
Depois disso, substitua os echo por comandos reais do seu projeto.
31. O que você deve saber depois deste artigo?
Não é necessário memorizar todas as palavras-chave do GitLab.
O mais importante é entender o papel de cada componente.
| Conceito | Pergunta que ele responde |
|---|---|
| CI | Como validar alterações automaticamente? |
| CD | Como automatizar a entrega do software? |
| Pipeline | Quais etapas compõem esse processo? |
| Stage | Em que fase da pipeline estamos? |
| Job | Qual tarefa específica deve ser executada? |
| Runner | Onde essa tarefa será executada? |
| Build | A aplicação pode ser construída? |
| Testes | O comportamento esperado continua funcionando? |
| Artifact | Qual resultado produzido precisamos preservar? |
| Docker | Como empacotar a aplicação? |
| Registry | Onde armazenamos a imagem? |
| Variables | Como disponibilizar configurações e secrets sem colocá-los no código? |
Quando essa relação estiver clara, aprender novas funcionalidades do GitLab se torna muito mais simples.
32. O próximo nível
Depois de dominar essa primeira estrutura, existem muitos assuntos que podem ser adicionados:
Qualidade de código: linters, análise estática e ferramentas como SonarQube.
Testes: cobertura, testes de integração e testes end-to-end.
Segurança: secret detection, dependency scanning e outras verificações.
Performance: cache, execução paralela e needs.
Entrega: environments, deploy automatizado e rollback.
O próprio GitLab possui documentação sobre esses recursos e também disponibiliza tutoriais progressivos para quem está começando.
Mas não há necessidade de aprender tudo de uma vez.
O fundamento continua sendo o mesmo: automatizar o processo de construção, validação e entrega de software de maneira previsível.
33. Materiais recomendados
Se você está começando, vale combinar três tipos de material.
O primeiro são conteúdos introdutórios em português. O próprio GitLab mantém um guia recente em português voltado para iniciantes e também possui um guia rápido para configurar a primeira pipeline.
O segundo são as documentações oficiais. Elas são particularmente importantes quando você sai do exemplo didático e começa a configurar o projeto real.
Por fim, vídeos são úteis para visualizar o GitLab funcionando na prática. Um conteúdo introdutório em inglês bastante completo é o tutorial da TechWorld with Nana, que aborda pipeline, jobs, stages, runners, testes, Docker e variáveis. Também existe um vídeo em português do Vinicius Barreto demonstrando GitLab CI/CD com build e push de imagem Docker.
34. Referências
CI/CD e DevOps
Martin Fowler — Continuous Integration
Artigo clássico sobre os princípios e práticas de Integração Contínua.
Red Hat — O que é CI/CD?
Material introdutório em português explicando CI, Continuous Delivery e Continuous Deployment.
GitLab
GitLab — Get started with GitLab CI/CD
Introdução oficial ao funcionamento do CI/CD no GitLab.
GitLab — CI/CD Pipelines
Documentação sobre pipelines, stages e jobs.
GitLab — Runners
Documentação sobre os agentes responsáveis pela execução dos jobs.
GitLab — Job Artifacts
Documentação sobre armazenamento dos resultados dos jobs.
GitLab — Merge Request Pipelines
Documentação sobre pipelines executadas em Merge Requests.
Angular
Angular — Testing
Documentação oficial sobre testes unitários e execução de testes em CI.
Docker
Docker — Get Started
Introdução oficial a imagens, containers e aplicações containerizadas.
npm
npm — npm ci
Documentação oficial sobre instalações reproduzíveis para ambientes automatizados.
Conclusão
Quando vemos um arquivo .gitlab-ci.yml pela primeira vez, é fácil enxergar apenas uma sequência estranha de YAML.
Mas, depois que entendemos o problema que ele resolve, a estrutura começa a fazer sentido.
Uma equipe produz alterações de software. Essas alterações precisam ser construídas, verificadas e testadas antes de avançarem no processo. O GitLab fornece a plataforma para organizar essa automação. O Runner executa as tarefas. Os jobs representam o trabalho. Os stages organizam as etapas. Os artifacts preservam resultados importantes. Docker empacota a aplicação. E o Registry pode armazenar as imagens produzidas.
A tecnologia pode mudar. Os comandos podem mudar. A forma de configurar a pipeline pode evoluir.
A ideia central, porém, continua a mesma:
Quanto mais do processo de desenvolvimento pudermos verificar de forma automática, consistente e reproduzível, menos dependeremos de tarefas manuais e de descobertas tardias.
CI/CD não é sobre criar uma pipeline enorme.
É sobre criar um processo confiável para transformar código em software que foi construído, testado e preparado de maneira controlada.
E esse é o conceito que vale levar para qualquer projeto, independentemente da linguagem, framework ou plataforma utilizada.
`
Top comments (0)