A segurança como código é um dos motores do futuro da segurança de aplicações (application security). Segundo a O'Reilly, segurança como código é a prática de incorporar segurança às ferramentas e aos fluxos de trabalho de DevOps, mapeando como as alterações de código e infraestrutura acontecem e identificando pontos para adicionar verificações, testes e gates de segurança sem gerar custos ou atrasos desnecessários. Os desenvolvedores podem definir a infraestrutura usando uma linguagem de programação, com a infraestrutura como código. É preciso que o mesmo aconteça para levar a segurança ao ritmo do DevOps — daí a importância da segurança como código.

Basicamente, a segurança como código consiste em integrar políticas, testes e verificações de segurança diretamente ao pipeline e ao próprio código. Os testes devem ser executados automaticamente a cada commit, com os resultados disponibilizados imediatamente aos desenvolvedores para que possam corrigir os problemas. Ao trazer as verificações de segurança para o código desde o momento em que é escrito, os times economizam tempo e dinheiro, já que simplificam o processo de revisão nas etapas seguintes do ciclo de vida do desenvolvimento de software (SDLC).

Por que ela é importante?

A segurança como código é fundamental para o shift left e para alcançar o DevSecOps: ela exige que a segurança seja definida desde o início do projeto e codificada para uso repetido e consistente. Dessa forma, os desenvolvedores passam a ter uma opção de autoatendimento para garantir que o próprio código seja seguro.

Políticas de segurança predefinidas aumentam a eficiência e, ao mesmo tempo, permitem verificações sobre os processos automatizados, prevenindo imprevistos no processo de deploy, como acabar derrubando acidentalmente toda a infraestrutura porque um problema não foi identificado em um ambiente de staging.

Seis capacidades de segurança como código para priorizar

François Raynaud, fundador e diretor executivo da DevSecCon, afirmou que a segurança como código consiste em tornar a segurança mais transparente e fazer com que profissionais de segurança e desenvolvedores falem a mesma língua. Em outras palavras, os times de segurança precisam entender como os desenvolvedores trabalham e usar isso para ajudá-los a incorporar os controles de segurança necessários ao SDLC. Os desenvolvedores, por sua vez, podem retribuir mantendo-se receptivos à medida que adotam novas ferramentas e práticas para reforçar a segurança durante o desenvolvimento. Veja seis boas práticas e capacidades para incorporar ao seu pipeline:

1. Automatize verificações e testes de segurança (como análise estática, análise dinâmica e testes de penetração) dentro do seu pipeline, para que possam ser reutilizados em todos os projetos e ambientes.
2. Construa um ciclo de feedback contínuo apresentando os resultados aos desenvolvedores, permitindo que corrijam problemas enquanto programam e aprendam boas práticas durante o próprio processo.
3. Avalie e monitore as políticas de segurança automatizadas incorporando verificações ao processo. Confirme que dados sensíveis e segredos não estão sendo compartilhados ou publicados por engano.
4. Automatize testes manuais complexos ou demorados por meio de scripts personalizados, com aprovação humana dos resultados quando for necessário. Valide a precisão e a eficiência dos scripts de teste para que possam ser replicados em diferentes projetos.
5. Teste o código novo em um ambiente de staging, o que permite uma verificação de segurança completa e falhas com baixo impacto, e faça isso a cada commit.
6. O monitoramento agendado ou contínuo deve gerar automaticamente logs (ou alertas) em um dashboard de revisão, como o Security Dashboard do GitLab.

Segurança como código é uma boa prática para chegar a um objetivo maior

A segurança como código dá um significado prático ao conceito de DevSecOps, mas não deve ser o seu objetivo final. No fundo, ela é um meio de engajar mais pessoas na tarefa de integrar segurança ao longo de todo o SDLC. A ideia vai parecer familiar para desenvolvedores que já praticam infraestrutura como código, pois ela também abre espaço para que a segurança entre em cena, tanto para entender melhor o desenvolvimento de software quanto para ajudar a desenhar as políticas que serão codificadas no processo.

À medida que o seu time avança para se tornar uma máquina de DevSecOps bem afinada, a segurança como código vai naturalmente se revelar uma solução inteligente dentro de um esforço complexo.

Avaliação de metodologia DevSecOps do GitLab

Implementar um processo de DevSecOps envolve muitos elementos. Por isso, para ajudar você a dominar os principais deles, criamos uma avaliação de metodologia DevSecOps. Avalie-se em 20 capacidades e use essa pontuação para entender o nível de maturidade do seu DevSecOps, além de identificar quais ações o seu time pode tomar para levar o DevSecOps ao próximo nível. Baixe a avaliação aqui.

Imagem de capa por Tim Evans no Unsplash

Sumário

• Noções básicas de git fetch e git pull
• O que é o git fetch?
• O que é o git pull?
• Quando usar o git fetch
• Quando usar o git pull
• Perguntas frequentes sobre git fetch e git pull

Noções básicas de git fetch e git pull

O git fetch e o git pull são comandos Git usados para buscar informações atualizadas em um repositório remoto, porém, cada um faz isso à sua própria maneira. Por um lado, o git fetch baixa as alterações do repositório remoto para o repositório local, sem alterar nada no seu diretório de trabalho atual. Como essas alterações não são mescladas na branch local, você pode conferir o que mudou no repositório remoto sem interromper o que está fazendo. Já o git pull também busca as alterações mais recentes do repositório remoto, exatamente como o git fetch, mas vai um passo além e as mescla automaticamente na branch atual, ou seja, diferentemente do git fetch, ele aplica diretamente as mudanças do repositório remoto ao seu diretório de trabalho local.

O que é o git fetch?

O comando git fetch recupera o histórico de commits mais recente do repositório remoto, mas não altera o diretório de trabalho local. Mesmo após buscar as alterações remotas, elas não aparecem refletidas na sua branch local. Por isso, ele é usado principalmente quando você quer conferir o status mais recente do repositório remoto e revisar as mudanças antes de trazê-las para o repositório local. Para aplicar as alterações buscadas à sua branch local, é preciso executar manualmente o git merge ou o git rebase.

O que é o git pull?

O comando git pull combina o git fetch e o git merge (ou o git rebase) em um único comando, permitindo recuperar as alterações do repositório remoto e integrá-las automaticamente à branch local atual.

Explicando melhor: enquanto o git fetch apenas busca as alterações do repositório remoto sem aplicá-las à branch local, rodar o git pull já integra essas mudanças diretamente na branch local. Isso torna o git pull uma boa opção para refletir rapidamente as modificações remotas na sua branch, mas também traz um ponto de atenção: como tudo acontece de forma automática, é preciso cautela para evitar conflitos, principalmente ao trabalhar em equipe.

Quando usar o git fetch

O git fetch é o comando indicado quando você quer apenas buscar as informações mais recentes de um repositório remoto, sem que elas sejam refletidas diretamente na sua branch local. Este é um ponto importante porque usar o git pull traria automaticamente todas as branches remotas para a sua branch local, incluindo eventuais branches problemáticas ou incorretas.

Por isso, quando alterações estão sendo feitas simultaneamente nas branches remota e local, ou quando há novas pessoas entrando no time, é mais seguro usar o git fetch para trazer primeiro o conteúdo da branch remota e só depois realizar o merge ou o rebase,garantindo mais controle sobre o processo.

Quando usar o git pull

O git pull realiza mais processos do que o git fetch, já que combina a busca das alterações (git fetch) com a execução do git merge ou do git rebase em uma única etapa. É por isso que ele é recomendado quando você quer refletir rapidamente as mudanças do repositório remoto na sua branch local, sem precisar rodar dois comandos separados.

Perguntas frequentes sobre git fetch e git pull

Qual é a diferença entre git pull e git fetch?

O git pull é um comando que executa o git fetch seguido do git merge ou do git rebase. Enquanto o git fetch não afeta o repositório local, o git pull sincroniza automaticamente as alterações do repositório remoto com o repositório local.

Quais cuidados devo ter ao usar o git pull?

Ao executar o git pull, podem surgir conflitos entre as alterações remotas e locais — conflitos de merge são comuns nesse cenário e, quando acontecem, precisam ser resolvidos manualmente. Uma alternativa é usar o git pull --rebase, que permite incorporar as alterações mais recentes já realizando um rebase no processo.

Para que serve o git fetch?

O git fetch é útil para checar e buscar o status mais recente do repositório remoto. Como as alterações buscadas não são refletidas automaticamente na branch local, o comando funciona como uma forma de sincronizar os repositórios local e remoto sem comprometer o trabalho em andamento.

Leia mais

• Novidades do Git 2.46
• Aprenda Git
• Conheça o GitLab Gitaly
• Conheça a linha de comando do Git no Windows

O que é CI/CD?

CI/CD é um processo tecnológico, é uma mentalidade, é uma sequência de etapas... o CI/CD é tudo isso. Em resumo, a integração contínua (CI - Continuous Integration) permite que os times de DevSecOps otimizem o desenvolvimento de código usando automação. Explicando melhor, a CI simplifica os builds dos softwares e a integração do código-fonte, viabiliza o controle de versão e promove maior colaboração por meio da automação. Onde a CI termina, a entrega contínua (CD - Continuous Delivery) entra em ação com testes e implantação automatizados. Além de reduzir o tempo manual que os profissionais de operações precisam dedicar à entrega e à implantação, a CD também permite que os times reduzam drasticamente o número de ferramentas necessárias para gerenciar o ciclo de vida. Ao integrar verificações de segurança e conformidade logo no início do pipeline, o CI/CD viabiliza uma abordagem de segurança shift left, que identifica e resolve problemas antes que cheguem aos ambientes de produção.

Quais são as boas práticas para o CI/CD?

Se você quer ter sucesso com o CI/CD, é preciso transformar a integração, a entrega e a implantação contínuas no seu mantra, já que elas são a base das práticas de desenvolvimento de software. O objetivo do DevSecOps é levar o software aos usuários mais rápido do que os métodos tradicionais, logo, essas práticas de desenvolvimento ajudam a tornar isso realidade. Veja as práticas mais essenciais, em ordem de importância:

1. Use uma plataforma DevSecOps unificada: consolide suas ferramentas de CI/CD em uma única plataforma para reduzir a sobrecarga de manutenção, minimizar a mudança de contexto e aumentar a colaboração. Menos ferramentas significam menos complexidade para a integração e uma experiência melhor entre os times de desenvolvimento, segurança e operações.
2. Automatize tudo: continue ajustando o pipeline de CI/CD para garantir que o estado de "automação contínua" seja alcançado. Isso inclui testes automatizados, verificações de segurança, implantação e provisionamento de infraestrutura.
3. Falhe rápido: do lado da CI, os desenvolvedores que fazem o commit de código precisam saber o mais rápido possível se há problemas, para que possam reverter e corrigir enquanto ainda está fresco na memória. A ideia do "falhar rápido" também ajuda a reduzir a troca de contexto dos desenvolvedores, o que deixa os profissionais de DevSecOps mais satisfeitos.
4. Faça commits com frequência: quanto mais regulares forem os commits de código, mais benefícios os times de DevSecOps vão perceber. Alterações pequenas e frequentes são mais fáceis de revisar, testar e implantar com segurança.
5. Antecipe a segurança (shift left): o CI/CD oferece uma boa oportunidade para integrar verificações de segurança, avaliações de vulnerabilidade e checagens de conformidade mais cedo no processo.
6. Aproveite a IA para solucionar problemas no pipeline: use ferramentas com IA para diagnosticar automaticamente falhas no pipeline, identificar causas raiz e sugerir correções, reduzindo o tempo de resolução de horas para minutos.
7. Use feature flags: desacople o deploy (ou seja, a implantação) do release usando as feature flags. Isso permite subir o código em produção sem expor novas funcionalidades aos usuários, possibilitando lançamentos mais seguros e reversões instantâneas.
8. Monitore tudo: implemente uma observabilidade abrangente, incluindo métricas da aplicação, logs e KPIs de negócio. Configure alertas para limites críticos, tanto técnicos quanto de negócio.
9. Mantenha o pipeline como código: armazene a configuração do seu pipeline de CI/CD no controle de versão, junto com o código da sua aplicação. Isso garante que as alterações no pipeline sejam rastreadas, revisadas e possam ser revertidas.
10. Habilite ciclos de feedback: garanta que todo o time receba, de forma facilitada, e também contribua com o feedback. Isso inclui monitoramento, alertas, validação pós-implantação e processos de melhoria contínua.

Boas práticas de entrega contínua

A entrega/implantação contínua merece um aprofundamento à parte em suas boas práticas, já que a CI costuma roubar a maior parte dos holofotes. Veja as boas práticas essenciais de CD:

• Comece com a sua configuração atual: não espere por uma plataforma perfeita. Comece identificando os gargalos no seu processo de implantação atual e automatize inicialmente as etapas manuais mais dolorosas.
• Adote estratégias de implantação: implemente técnicas de entrega progressiva, como deploy blue-green, canary deployment ou feature flags, para reduzir riscos e possibilitar rollbacks seguros.
• Mantenha a paridade entre ambientes: garanta que os ambientes de desenvolvimento, staging e produção sejam o mais parecidos possível. Use infraestrutura como código para eliminar desvios de configuração.
• Automatize a validação de implantação: crie testes de fumaça (smoke tests) e verificações de integridade automatizados que validem as implantações imediatamente após o release. Assim, as validações que falharem devem disparar rollbacks automáticos.
• Implemente monitoramento abrangente: monitore tanto métricas técnicas (como tempos de resposta e taxas de erro) quanto KPIs de negócio (como engajamento do usuário e taxas de conversão) para identificar problemas cedo.
• Pratique implantações sem downtime: projete suas aplicações e o processo de implantação para lidar com atualizações sem interrupção do serviço, usando técnicas como atualizações graduais (rolling updates) ou troca de balanceador de carga (load balancing).
• Mantenha as reversões simples: garanta que você consiga voltar rapidamente para a versão anterior. Teste seu processo de rollback regularmente e, quando possível, torne-o uma operação de apenas um clique.
• Separe a implantação do lançamento: use feature flags para implantar código sem expor imediatamente novas funcionalidades aos usuários, permitindo testes mais seguros em produção.

Como otimizar o pipeline de CI/CD

Um pipeline de CI/CD é a sequência automatizada de etapas que leva o código do desenvolvimento até a produção. O pipeline típico inclui: build, test, security scan, deploy e monitor. Embora essas etapas possam ser feitas manualmente, a automação é o processo que realmente torna o CI/CD valioso. Então, se chegou a hora de otimizar o seu pipeline de CI/CD, considere aplicar estas melhorias de desempenho:

Otimize o desempenho do pipeline

• Implemente o cache de build para evitar recompilar componentes que não mudaram.
• Use a execução de jobs condicionais para pular etapas desnecessárias quando o código não foi alterado.
• Otimize as imagens Docker com builds multi-stage e imagens base menores.

Melhore a visibilidade do pipeline

• Adicione o monitoramento da duração do pipeline para identificar quais são os estágios lentos.
• Implemente um registro de logs detalhado e uma coleta de artefatos para facilitar a solução de problemas.
• Aproveite os dashboards de pipeline para mostrar taxas de sucesso e tendências de desempenho.

Otimize a eficiência de recursos

• Dimensione corretamente seus runners de CI com base no consumo real de recursos.
• Use instâncias spot ou autoscaling para recursos de computação mais econômicos.
• Limpe recursos e artefatos temporários após a conclusão do pipeline.

Escale para o crescimento do time

• Use componentes de pipeline para manter a consistência entre projetos.
• Use ambientes dinâmicos que sobem e são desativados automaticamente.
• Configure fluxos de aprovação de pipeline para implantações em produção.

Estratégia de implantação de CI/CD

Lembre-se: o CI/CD tem como objetivo entregar uma aplicação de software ao cliente com mais qualidade e mais rapidez do que antes. Organizações que adotam o CI/CD veem uma melhora significativa na produtividade. O segredo é criar uma estratégia de implantação que funcione para aquela organização específica. Veja algumas estratégias que ajudam a garantir o sucesso de uma implantação:

• Faça commits de alterações pequenas: implante mudanças pequenas e incrementais com frequência, em vez de fazer grandes releases. Isto porque alterações pequenas são mais fáceis de testar, revisar e reverter caso surjam problemas, reduzindo o risco da implantação.
• Comece pequeno e depois cresça: comece com aplicações menos críticas para ganhar confiança e refinar processos antes de partir para sistemas essenciais para o negócio.
• Implemente rollbacks automatizados: defina critérios claros para reversões automáticas com base em taxas de erro, métricas de desempenho ou verificações de integridade.
• Pratique simulações de deploy: teste regularmente o seu processo de implantação em ambientes de staging que espelhem o ambiente de produção.
• Estabeleça janelas de implantação: agende implantações em períodos de baixo tráfego no início e, à medida que a confiança cresça, avance rumo à implantação contínua.
• Monitore o impacto da implantação: acompanhe tanto métricas técnicas (tempo de resposta, taxas de erro) quanto métricas de negócio (engajamento do usuário, taxas de conversão) após cada implantação.

Como medir o sucesso do CI/CD

Os times de DevSecOps não conseguem saber o quão bem as suas práticas de CI/CD estão indo, a menos que elas sejam quantificadas. Neste sentido, as métricas desempenham um papel importante na melhoria do desempenho do sistema e ajudam a identificar onde é possível agregar valor. Veja as métricas essenciais a serem usadas:

As quatro métricas do DORA

Os times modernos se apoiam no framework DORA, que identifica quatro métricas-chave fortemente relacionadas ao desempenho organizacional:

Frequência de implantação

Com que frequência o seu time consegue publicar o código em produção com sucesso. Os times com desempenho de elite implantam várias vezes por dia, enquanto os times de alto desempenho implantam diariamente ou semanalmente. Essa métrica indica a capacidade do seu time de entregar valor e responder às demandas do mercado.

Prazo de entrega das alterações

Tempo entre o commit do código e a implantação em produção. Os times de elite alcançam prazos de entrega inferiores a um dia; os times de alto desempenho variam entre um dia e uma semana. Se os commits levam semanas para chegar à produção, o seu pipeline precisa de otimização.

Taxa de falha em alterações

Percentual de deploys que causam falhas em produção e exigem hotfixes ou rollbacks. Os times de elite mantêm taxas de falha de até 15%; os times de alto desempenho ficam entre 16% e 30%. Taxas de falha altas indicam problemas de qualidade nas suas práticas de teste e implantação.

Tempo médio de recuperação

Com que rapidez o seu time restaura o serviço após falhas no deploy. Os times de elite se recuperam em menos de uma hora; já os times de alto desempenho, em menos de um dia. Uma recuperação rápida exige monitoramento robusto e capacidades de reversão automatizada.

Métricas adicionais de CI/CD

Além das métricas principais do DORA, os times costumam acompanhar estes indicadores operacionais:

Custos de infraestrutura

O CI/CD nativo em nuvem pode gerar despesas significativas se não for bem gerenciado. Práticas eficientes que reduzem os tempos de build e otimizam o uso de recursos impactam diretamente os custos operacionais.

Retenção de talentos

Desenvolvedores satisfeitos permanecem na empresa. Quando os times colaboram de forma eficaz nas práticas de CI/CD, a retenção aumenta. Taxas de retenção em queda podem sinalizar problemas com ferramentas ou fluxos de implantação, problemas que os desenvolvedores podem hesitar em expressar diretamente.

O impacto do negócio das métricas de CI/CD

Essas métricas técnicas se traduzem diretamente em resultados para o negócio:

• Uma frequência de implantação mais rápida reduz o tempo de lançamento no mercado e melhora a capacidade de resposta ao cliente. Isso representa a velocidade de inovação e capacidade de resposta ao mercado.
• Prazos de entrega mais curtos permitem entregar recursos e correções mais rápido, aumentando a satisfação do cliente. Isso mede o tempo entre a ideia e o valor entregue ao cliente.
• Taxas de falha menores reduzem os custos de suporte e minimizam o impacto ao cliente causado por problemas em produção. Isso indica a qualidade e a confiabilidade da experiência do cliente.
• Um tempo médio de recuperação menor protege a receita durante interrupções e mantém a confiabilidade do serviço. Isso reflete a continuidade do negócio e a capacidade de mitigação de riscos.

Vantagem competitiva

O programa de pesquisa DORA constatou que organizações de alta performance demonstram consistentemente melhores resultados de negócio em múltiplas áreas.

Times com métricas de CI/CD sólidas relatam maior produtividade, maior satisfação do cliente e maior capacidade de competir em mercados que estão em constante mudança.

Quais são os benefícios de seguir as boas práticas de CI/CD?

Quando as boas práticas são seguidas, os benefícios do CI/CD são sentidos primeiro pelos seus clientes e, depois, por toda a organização. Veja os principais benefícios:

• Os clientes recebem recursos e correções mais rápido. O CI/CD permite a entrega rápida de novas funcionalidades e correções de bugs, melhorando diretamente a experiência do usuário e mantendo os clientes satisfeitos com melhorias contínuas.
• Software mais confiável e de maior qualidade. Testes automatizados e lançamentos graduais significam que menos bugs chegam à produção, resultando em aplicações mais estáveis nas quais os clientes podem confiar.
• Resposta mais rápida ao feedback dos clientes. Ciclos de desenvolvimento curtos permitem que os times implementem rapidamente solicitações dos clientes e resolvam problemas, mostrando que a opinião deles é valorizada e atendida com agilidade.
• Melhor uptime e desempenho. Monitoramento automatizado e capacidade de rollbacks rápidos significam que problemas visíveis aos clientes são resolvidos mais rápido, minimizando interrupções no serviço.
• Recursos mais inovadores. Quando os desenvolvedores gastam menos tempo em processos manuais e apagando incêndios, eles podem focar em construir recursos que realmente agregam valor para o cliente e trazem diferenciais para o produto.
• Suporte ao cliente aprimorado. Ciclos de implantação mais rápidos significam que problemas relatados pelos clientes podem ser corrigidos e implantados rapidamente, em vez de esperar pelo próximo grande ciclo de lançamento.

Os benefícios internos vêm naturalmente na sequência: desenvolvedores mais satisfeitos, melhor colaboração entre times, menor sobrecarga operacional e maior retenção de talentos — tudo isso, no fim das contas, contribui para entregar experiências melhores aos clientes.

Como posso implementar o CI/CD na minha organização?

Antes de implementar qualquer software, é fundamental determinar quais são os fatores de negócio, sendo que isto também vale para a adoção do CI/CD. Todas as partes interessadas no desenvolvimento devem ser envolvidas logo no início do processo de implementação. Os desenvolvedores devem contribuir com sua visão, já que serão os principais usuários do produto.

Faça uma pesquisa cuidadosa sobre softwares que viabilizam o CI/CD e pergunte sobre testes gratuitos.

Embora possa parecer contraintuitivo, já que o CI/CD tem como objetivo acelerar o ritmo da entrega de software usando automações, comece o processo de adoção com uma mentalidade de adaptação devagar e segura. O ganho de eficiência diminui se os bugs continuarem chegando de forma constante à aplicação em produção.

É importante manter consistência no processo de integração. Execute testes unitários, dispare releases manualmente e acompanhe as métricas. Depois, determine o que pode e deve ser automatizado.

Comece hoje mesmo com o CI/CD assinando um teste gratuito do GitLab Ultimate com o Duo Enterprise.

Imagine um fluxo de trabalho em que cada alteração de código é automaticamente compilada, testada e publicada para os seus usuários. É esse o poder da Integração Contínua/Entrega Contínua (CI/CD)! O CI/CD ajuda você a identificar bugs mais cedo, garante a qualidade do código e entrega software mais rápido e com mais frequência.

O que é CI/CD?

• A Integração Contínua (CI) é uma prática de desenvolvimento de software em que os desenvolvedores integram com frequência as alterações de código a um repositório compartilhado, de preferência várias vezes ao dia. Cada integração é então verificada por um processo automatizado de build e teste, permitindo que os times detectem problemas logo no início.
• A Entrega Contínua (CD) amplia a CI ao automatizar o pipeline, garantindo que o seu código esteja sempre pronto para o deploy. Assim, você pode implantar sua aplicação em diferentes ambientes (por exemplo, staging, produção) com um único clique ou de forma automática.
• A Implantação Contínua (CD) vai um passo além ao implantar automaticamente cada build bem-sucedido em produção. Isso exige um alto grau de confiança nos seus testes automatizados e no processo de implantação.

Por que usar o GitLab CI/CD?

O GitLab CI/CD é um sistema poderoso e integrado que já vem incluído na plataforma do GitLab. Ele oferece uma experiência integrada para automatizar todo o seu ciclo de vida de desenvolvimento de software (SDLC). Com o GitLab CI/CD, você pode:

• Automatizar todo o processo: compile, teste e suba as suas aplicações com rapidez e facilidade.
• Detectar bugs mais rápido: encontre e corrija erros antes que cheguem aos ambientes de produção.
• Obter feedback mais rápido: receba feedback imediato sobre as alterações realizadas no seu código.
• Melhorar a colaboração: trabalhe em conjunto eficientemente com fluxos de trabalho automatizados.
• Acelerar a entrega: publique novas versões do software mais rapidamente e com mais frequência.
• Reduzir riscos: minimize consideravelmente erros no deploy e rollbacks.

Os elementos do GitLab CI/CD

• .gitlab-ci.yml: este arquivo YAML, localizado no diretório raiz do seu projeto, define o pipeline de CI/CD, incluindo as etapas, jobs e runners.
• GitLab Runner: esse agente executa os seus jobs de CI/CD na sua infraestrutura (por exemplo, máquinas físicas, máquinas virtuais, containers Docker ou clusters Kubernetes).
• Etapas: as etapas definem a ordem de execução dos seus jobs (por exemplo, build, test e deploy).
• Jobs: os jobs são unidades individuais de trabalho dentro de um estágio (por exemplo, compilar código, executar testes e realizar o deploy para staging).

Configurando o GitLab CI

Começar com o GitLab CI é simples. Veja um exemplo básico de um arquivo .gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the application..."

test_job:
  stage: test
  script:
    - echo "Running tests..."

deploy_job:
  stage: deploy
  script:
    - echo "Deploying to production..."
  environment:
    name: production

Essa configuração define três etapas: "build", "test" e "deploy". Cada etapa contém um job que executa um script simples.

Exemplos de configuração de CI/CD

Vamos explorar alguns exemplos mais realistas.

Compilando e implantando uma aplicação Node.js

A definição de pipeline abaixo mostra o uso do npm para compilar e testar uma aplicação Node.js e do dpl para implantar a aplicação no Heroku. A etapa de deploy do pipeline utiliza as variáveis de CI/CD do GitLab, que permitem que os desenvolvedores armazenem informações sensíveis (como credenciais) e as utilizem com segurança nos processos de CI/CD. Neste exemplo, uma chave de API para publicar no Heroku é armazenada na variável $HEROKU_API_KEY, usada pela ferramenta dpl.

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:latest
  script:
    - npm install
    - npm run build

test:
  stage: test
  image: node:latest
  script:
    - npm run test

deploy:
  stage: deploy
  image: ruby:latest
  script:
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY

Publicando em diferentes ambientes (staging e produção)

O GitLab também oferece o conceito de Ambientes (Environments) no CI/CD. Esse recurso permite que os usuários acompanhem as implantações do CI/CD até os seus destinos na infraestrutura. No exemplo abaixo, o pipeline adiciona etapas com uma propriedade de ambiente para staging e produção. Enquanto a etapa deploy_staging sempre executa seu script, a etapa deploy_production exige aprovação manual para evitar publicações acidentais em produção.

stages:
  - build
  - test
  - deploy_staging
  - deploy_production

build:
  # ...

test:
  # ...

deploy_staging:
  stage: deploy_staging
  script:
    - echo "Deploying to staging..."
  environment:
    name: staging

deploy_production:
  stage: deploy_production
  script:
    - echo "Deploying to production..."
  environment:
    name: production
  when: manual  # Requires manual approval

GitLab Auto DevOps

O GitLab Auto DevOps simplifica o CI/CD ao oferecer uma configuração pré-definida que compila, testa e publica suas aplicações automaticamente. Para isso, ele utiliza as boas práticas e padrões do setor para otimizar o seu fluxo de trabalho.

Para ativar o Auto DevOps:

1. Acesse Settings > CI/CD > General pipelines no seu projeto.
2. Ative a opção Auto DevOps.

O Auto DevOps detecta automaticamente a linguagem e o framework do seu projeto e configura as etapas necessárias de build, test e deploy. Ou seja, você nem precisa criar um arquivo .gitlab-ci.yml.

Catálogo de CI/CD

O Catálogo de CI/CD é uma lista de projetos com componentes de CI/CD publicados para que você possa estender o seu fluxo de trabalho de CI/CD. Assim, qualquer pessoa pode criar um projeto de componente e adicioná-lo ao Catálogo de CI/CD, ou mesmo contribuir para um projeto existente para melhorar os componentes disponíveis. Você pode encontrar os componentes publicados no Catálogo de CI/CD no GitLab.com.

Tutorial: Saiba como configurar seu primeiro componente de CI/CD do GitLab

Templates de CI

Você também pode criar seus próprios templates de CI para padronizar e reutilizar configurações de CI/CD em vários projetos, o que promove a consistência e reduz a duplicação.

Para criar um template de CI:

1. Crie um arquivo .gitlab-ci.yml em um projeto ou repositório dedicado.
2. Defina sua configuração de CI/CD no template.
3. No arquivo .gitlab-ci.yml do seu projeto, use a palavra-chave include para incluir o template.

Leve o seu desenvolvimento para o próximo nível

O GitLab CI/CD é uma ferramenta poderosa que pode transformar o seu fluxo de trabalho de desenvolvimento. Ao entender os conceitos de CI/CD, configurar seus pipelines e aproveitar recursos como o Auto DevOps, o Catálogo de CI/CD e os templates de CI, você pode automatizar todo o seu ciclo de vida de desenvolvimento de software e entregar software de alta qualidade mais rápido e com mais eficiência.

Quer saber mais sobre este e outros assuntos, e aprofundar o seu aprendizado? Inscreva-se nos cursos da GitLab University ou comece agora mesmo com um teste gratuito do GitLab Ultimate.

Série "Primeiros passos com o GitLab"

Confira mais artigos da nossa série "Primeiros passos com o GitLab":

• Como gerenciar usuários
• Como importar seus projetos para o GitLab
• Dominando o gerenciamento de projetos
• Automatizando fluxos de trabalho ágeis com a gem gitlab-triage
• Trabalhando com variáveis de CI/CD

Então, o que é DevOps?

O DevOps une dois times que antes eram separados - o time de desenvolvimento de software e o time de operações (de TI) – e os transforma em uma frente unida, capaz de criar código seguro ao mesmo tempo em que acelera o ciclo de vida do desenvolvimento de software - SDLC. Os fundamentos do DevOps incluem uma cultura colaborativa e comunicativa, testes automatizados, releases e implantações, além de iterações frequentes. Outro termo bastante usado no universo DevOps é o DevSecOps, que se refere a uma prática de DevOps com ênfase específica em segurança.

O que realmente importa está no centro da metodologia DevOps: estes quatro princípios-chave, capazes de melhorar a prática de desenvolvimento de software da sua organização.

1. Automação do ciclo de vida do desenvolvimento de software
2. Colaboração e comunicação
3. Melhoria contínua e minimização de desperdício
4. Foco intenso nas necessidades do usuário, com ciclos de feedback curtos

Uma análise dos principais princípios do DevOps

Há cerca de 15 anos, surgiu a ideia de unir desenvolvimento e operações de forma integrada. Em 2009, o termo "DevOps" foi cunhado por Patrick Debois, considerado um dos principais gurus da metodologia. O DevOps incorpora boa parte dos princípios do desenvolvimento ágil de software, mas com ênfase especial na quebra dos silos entre desenvolvimento e operações.

Desde então, o DevOps só cresceu em popularidade, alcançando desde pequenas empresas até grandes corporações com sistemas legados, passando por praticamente todos os portes de negócio. Assim como em outras situações, o DevOps se adapta às necessidades e ao ambiente exclusivo de cada organização, ajustando-se ao que é mais importante para o negócio.

Por isso, é possível encontrar diversas variações do DevOps, mas, no fundo, todas compartilham estes 4 princípios essenciais:

Automação do ciclo de vida do desenvolvimento de software

A automação é o norte de todo time de DevOps. Antes do DevOps, o desenvolvimento de software era um trabalho extremamente manual, que exigia envolvimento humano (e repasses físicos e manuais) em cada etapa do processo. Todo esse envolvimento humano fazia com que as empresas tivessem sorte se conseguissem atualizar ou lançar um novo código uma vez por ano — muitas delas seguiam um ciclo de lançamento de 18 ou 24 meses.

Hoje, os chamados “times de DevOps de elite” publicam código várias vezes ao dia — e conseguem fazer isso principalmente graças à automação.

Para entender o poder e a importância da automação no DevOps, basta pensar nos testes de software: uma etapa frequentemente esquecida e pouco valorizada, mas que costuma levar a culpa por atrasos no lançamento. Não há dúvida de que os testes de software são essenciais; sem eles, as empresas correm o risco de lançar código com falhas ou mesmo códigos inseguros.

Porém, os testes talvez sejam a etapa mais manual de todo o processo de DevOps, exigindo que as pessoas escrevam casos de teste, executem inúmeros testes, analisem os resultados e, depois, retornem aos desenvolvedores para as correções. De forma resumida, não é à toa que os times apontam os testes como o principal motivo pelo qual o código não é lançado no prazo.

É aí que entra a automação, com a ideia de que os testes de software mais básicos podem acontecer no momento em que o código é escrito. Assim, a automação de testes acelera drasticamente todo o processo e libera os analistas de teste de software para buscar problemas de qualidade de código potencialmente mais graves.

Embora os testes sejam uma das vitórias mais marcantes da automação no DevOps, eles estão longe de ser a única. A integração contínua automatiza o processo de incorporar novo código ao código já existente, enquanto a implantação contínua ajuda a automatizar os releases. Já o Infrastructure as Code facilita a automação do processo de provisionamento de ambientes de desenvolvimento.

Colaboração e comunicação

Um bom time de DevOps tem automação, mas um time de DevOps excelente conta também com colaboração e comunicação. A ideia central de unir dev e ops (além de sec, teste, stakeholders etc.) depende da capacidade dos times de colaborar. E isso só é possível quando existe uma comunicação clara e constante.

Esse pode parecer um princípio simples do DevOps, mas, como quase tudo, a dificuldade está presente nos detalhes. Quem é do time de dev quer escrever código e colocá-lo no ar; quem é de ops foca em ferramentas, compliance e nuvem; e o time de segurança quer garantir que o código seja seguro. Dev, ops e sec não têm as mesmas prioridades, podem não falar a mesma “língua” e tendem a abordar a resolução de problemas sob perspectivas bem diferentes. Um exemplo disso: dev e sec ainda não se dão muito bem, em parte porque a lacuna de comunicação e colaboração entre eles permanece grande.

É preciso esforço para aproximar os times e, muitas vezes, também é preciso pensar fora da caixa. E, em mais uma daquelas situações de “o que veio primeiro: o ovo ou a galinha?”, os times precisam se comunicar para um DevOps bem-sucedido, mas o próprio DevOps também pode levar a uma comunicação melhor e a desenvolvedores mais satisfeitos, segundo os resultados da nossa Pesquisa Global de DevSecOps de 2021.

Melhoria contínua e minimização de desperdício

Apoiado fortemente em metodologias de desenvolvimento de software anteriores, incluindo Lean e Agile, o DevOps também foca na redução de desperdício e na melhoria contínua. Seja automatizando tarefas repetitivas, como os testes, para não perder tempo, ou reduzindo o número de etapas necessárias para lançar um novo código, times de DevOps bem-estruturados seguem medindo métricas de desempenho para identificar pontos que precisam melhorar.

Espera-se que os times busquem melhorar continuamente os tempos de release, reduzir o tempo médio de recuperação e o número de bugs encontrados, entre outras métricas.

Foco intenso nas necessidades do usuário, com ciclos de feedback curtos

O último princípio essencial do DevOps é a importância de trazer o usuário real para cada etapa do processo. Por meio da automação, da comunicação e colaboração aprimoradas e da melhoria contínua, os times de DevOps conseguem parar por um instante para focar no que os usuários realmente querem — e em como entregar isso a eles. Não há dúvida de que entender a mente do usuário é algo bastante complexo, e os times podem ter dificuldade em implementar processos para alcançar esse objetivo.

O outro desafio é que o feedback do usuário, uma vez coletado, precisa ser entregue rapidamente, para que o tempo não seja desperdiçado. É por isso que ciclos de feedback curtos são essenciais, e por isso os times precisam se dedicar a torná-los ainda mais curtos com o passar do tempo.

Benefícios de um modelo e das práticas de DevOps

O que acontece quando os times aplicam o DevOps corretamente? Em nossa pesquisa de 2021, 60% dos desenvolvedores nos disseram que estavam lançando código, pelo menos, duas vezes mais rápido graças ao DevOps. Outros benefícios de um modelo DevOps incluem melhor qualidade de código, tempo de lançamento mais rápido e planejamento mais eficiente.

E, de bônus, os participantes da pesquisa também nos contaram que ter uma prática de DevOps bem-sucedida deixa os desenvolvedores mais satisfeitos, e existem dados científicos que mostram que desenvolvedores mais felizes são mais produtivos.

Quais são os desafios de implementar o DevOps?

O DevOps pode ser desafiador no início, principalmente se for a primeira vez que está sendo implementado em uma organização. Confira alguns dos desafios de implementar o DevOps.

• Quebrar os silos. Pode ser difícil romper a mentalidade de que desenvolvimento e operações são entidades separadas. Busque entender bem os papéis e as responsabilidades de um time combinado de DevOps.
• Entender os jargões. O DevOps vem com muitas abreviações, jargões técnicos e uma quantidade enorme de siglas, como CI/CD. Reserve um tempo para estudar e lembre-se de que aprender aos poucos é completamente normal e aceitável.
• Migrar de sistemas legados. O DevOps pode ser especialmente complicado para times que estão migrando software legado. Muitas ferramentas criadas para DevOps não funcionam com mainframes (só para dar um exemplo), e as integrações podem ser desafiadoras até mesmo para profissionais experientes em DevOps. Também não ajuda o fato de haver escassez de programadores especializados em mainframe e outros sistemas legados.
• Excesso de ferramentas. Os times gastam tanto tempo integrando e mantendo ferramentas que isso acaba atrapalhando o trabalho real de desenvolver, publicar e monitorar o código. Esse fenômeno é conhecido como “toolchain tax”, o custo oculto da cadeia de ferramentas.
• Lidar com a frustração da curva de aprendizado. O DevOps é complexo, e aprender como ele funciona é uma maratona, não 100 metros rasos. Tenha paciência e seja compreensivo com o time à medida que a implementação avança, e conte com os recursos disponíveis, como a documentação e representantes da plataforma — e, às vezes, confie no bom e velho processo de tentativa e erro.

Como começar a implementar o DevOps na sua organização

Ao se preparar para começar com o DevOps, é preciso seguir a seguinte preparação:

1. Mapeie os objetivos por trás da implementação do DevOps.
2. Esclareça os papéis e as responsabilidades de cada participante.
3. Comece de forma simples e evolua com a experiência.
4. Planeje automatizar o máximo possível.
5. Planeje seu toolchain (e lembre-se: toolchains sempre podem ser ajustados).
6. Estabeleça checkpoints regulares de progresso.
7. Esteja preparado para iterar constantemente (mas só depois de dar tempo suficiente para provar que a iteração é realmente necessária).

Qual é o futuro do DevOps?

A adoção e o sucesso do DevOps ganharam um enorme impulso graças à pandemia global. Os times superaram parte das questões culturais de “como trabalhar juntos?” e amadureceram para a mentalidade de “como adotar as tecnologias certas?”, segundo os resultados da nossa pesquisa. O uso de tecnologias avançadas, incluindo Kubernetes, plataformas de DevOps e inteligência artificial (IA) / machine learning (ML), já dá pistas de como será o futuro do DevOps.

É seguro esperar mais automação, tomadas de decisão mais inteligentes com IA/ML (começando em áreas como revisão de código) e uma escolha mais criteriosa de ferramentas, como a adoção contínua de plataformas de DevOps para otimizar o processo.

Contudo, há um padrão que vale observar: quanto melhores ficam as ferramentas de programação com agentes de IA para escrever código, mais o restante do ciclo de vida do software luta para acompanhar o ritmo. O backlog de bugs cresce. As taxas de falha nos pipelines crescem e as vulnerabilidades de segurança se acumulam mais rápido do que os times conseguem classificá-las. Isso mostra que programar e entregar um software não são a mesma coisa, e essa diferença entre os dois é real.

É neste ponto que o GitLab entra para acelerar tudo o que vem depois do Claude Code no restante do ciclo de vida do software: CI/CD, verificação de segurança, revisão de código e aprovações, tudo em um só lugar, com um fluxo auditável.

Este tutorial apresenta três cenários nos quais o Claude Code avança rápido na base de código, enquanto o GitLab cuida de tudo o que transforma esse código em uma mudança certificada e entregue:

• Corrija um bug em C++ com o Claude Code e deixe que o GitLab CI/CD, a verificação de segurança e o Duo Code Review sigam a partir daí.
• Adicione contexto do GitLab via MCP para que o Claude trabalhe a partir do tíquete real, e não apenas dos arquivos locais.
• Use um agente externo do Claude no Duo Agent Platform para resolver o feedback de revisão de código diretamente na merge request - MR.

Pré-requisitos

1. Claude Code no terminal, configurado e em execução.
2. Um projeto GitLab com relatos de bugs e issues de proposta de recursos — por exemplo, o projeto Tanuki Iot Platform.
3. Para casos de uso específicos: o servidor MCP do GitLab e o GitLab Duo Agent Platform com agentes externos.
4. Para compilar o código: CMake, Make, gcc/clang++ para C++, Maven para Java.

Prepare o projeto GitLab

Se quiser acompanhar o tutorial, você pode repetir todas as etapas aqui no seu próprio ambiente de desenvolvimento. Para isso:

• Importe o projeto Tanuki Iot Platform para o seu ambiente GitLab, incluindo todos os issues abertos.
• Clone o projeto no seu ambiente local e navegue até ele.
• Abra um terminal e execute o Claude Code com claude.

git clone https://gitlab.example.com/examplegroup/tanuki-iot-platform.git
cd tanuki-iot-platform

claude

Faça uma pergunta no prompt para saber mais sobre a finalidade do projeto.

Sobre o que é este projeto?

Comece a usar o Claude Code com o GitLab

No nosso primeiro cenário, precisamos corrigir um sensor de hardware escrito em C++. O coletor Arduino lê métricas da placa Arduino Uno R4 conectada via USB e trava quando o dispositivo /dev/ttyACM0 não está conectado.

Depois de ler o relato de bug no Issue 4, inspecione o código no arquivo main.cpp, por exemplo, usando o vim:

vim sensors/arduino-iot-collector/src/main.cpp

Compile e execute o binário do coletor com o CMake para reproduzir o problema.

cmake -S . -B build
cmake --build build

./build/arduino_iot_collector
Starting Arduino IoT Collector Application...
libc++abi: terminating due to uncaught exception of type std::runtime_error: Failed to initialize Arduino temperature sensor: Arduino port not found: /dev/ttyACM0
[1]    85289 abort      ./build/arduino_iot_collector

Abra o Claude Code e insira o seguinte pedido:

Pode me ajudar a corrigir o sensor do Arduino IoT Collector? Ele está travando.

O Claude Code pesquisa a base de código (codebase) e identifica o problema no arquivo main.cpp, que lança uma exceção std::runtime_error(), fazendo a aplicação travar imediatamente. O comportamento esperado é registrar um erro de configuração amigável ao usuário e continuar executando a aplicação normalmente.

Depois de corrigir e compilar o código com sucesso, precisamos criar uma branch do Git, um commit e uma merge request para disparar os pipelines de CI/CD, a verificação de segurança e os fluxos de revisão de código.

Você pode usar diferentes formas de trabalhar com o Git no Claude Code:

• Usar um prompt: Pode me ajudar a criar uma branch do Git, fazer o commit e enviar as alterações?
• Executar os comandos do shell: abra o prompt de comando com !, seguido dos comandos git checkout -b fix-arduino-sensor, git commit -avm "..." e git push. A saída do git push gera uma URL de criação da merge request. Clique nela para abrir o navegador e preencher o formulário.

Os pipelines de CI/CD são disparados na criação da MR e verificam se o build e os testes estão funcionando. A verificação de segurança garante que nenhuma vulnerabilidade nova seja introduzida. A nova MR dispara automaticamente o GitLab Duo Code Review Flow, que avalia a precisão da correção, de acordo com os guias de estilo de desenvolvimento e as instruções de revisão personalizadas.

Veja abaixo uma gravação do Claude Code, do GitLab CI/CD e do GitLab Duo Agent Platform em ação:

Corrigindo um bug em C++ com o GitLab MCP no Claude Code

No cenário anterior, o Claude Code pesquisou o repositório de código local e fez suposições sobre uma possível correção com base no contexto disponível. No entanto, ele não tinha conhecimento do tíquete do GitLab que descrevia o bug, das discussões para a sua depuração e das soluções propostas para resolver o problema em definitivo. Além disso, ele também não levou em conta o histórico de alterações de código anteriores salvas em merge requests e issues com relatos parecidos, que são parte importante do contexto do ciclo de vida do desenvolvimento de software (SDLC).

Para permitir a utilização desse contexto rico do SDLC do GitLab, podemos integrar o servidor MCP do GitLab para o Claude Code.

Configure o servidor MCP do GitLab

Confirme que o servidor MCP do GitLab está habilitado na instância ou no grupo de nível superior.

Abra um novo terminal e adicione o servidor MCP do GitLab ao Claude Code usando o tipo de transporte http.

Substitua gitlab.example.com pela sua instância do GitLab ou use GitLab.com:

claude mcp add --transport http GitLab https://gitlab.example.com/api/v4/mcp

Execute claude em uma nova sessão do terminal e digite /mcp para autenticar com o servidor MCP do GitLab, usando OAuth na página do navegador que será aberta.

claude

/mcp

Para verificar a conexão, pergunte ao Claude:

Quais ferramentas MCP do GitLab estão disponíveis para você?

Mostre a versão do servidor MCP do GitLab

Ao autenticar o Claude Code com o servidor MCP do GitLab, a conexão passa pelo OAuth e atua com a sua identidade já existente no GitLab e não com permissões elevadas ou separadas. Na prática, isso significa que o Claude Code só consegue ver projetos, issues (tíquetes), merge requests e outros dados do GitLab que você já tem acesso, seja pela sua conta ou seja pela sua participação em projetos e grupos. Essa é uma importante barreira de proteção: o MCP amplia o contexto dentro da ferramenta de IA, mas não contorna os controles de visibilidade do GitLab nem cria um acesso mais amplo por conta própria.

Uma segunda barreira de proteção é a aprovação do usuário. Nesse fluxo, o Claude Code identifica a ferramenta MCP que quer chamar e pede aprovação antes de seguir adiante, para que os desenvolvedores continuem no controle sempre que um contexto externo é buscado. Em ambientes sensíveis à segurança, também vale reforçar que os times devem ficar atentos aos dados expostos nos prompts e usar o MCP principalmente com conteúdo confiável do GitLab.

Trabalhe em um issue de relato de bug

Vamos buscar o contexto do tíquete no Claude Code referenciando o Issue 4 no prompt. Se você não tiver um tíquete no seu projeto, clone/copie o Issue 4 e ajuste o número no prompt.

Pode me ajudar a corrigir o issue 4?

O Claude Code identifica a necessidade de chamar a ferramenta MCP get_issue e pede a sua aprovação, sendo que também é possível aprovar o uso futuro automaticamente.

Depois que o Claude Code buscar o contexto necessário do issue, ele começa a analisar diretamente o código-fonte em C++ do sensor. Depois de criar e verificar uma correção, você pode pedir para criar uma nova branch do Git, um commit e uma MR, caso o Claude Code ainda não o faça automaticamente.

Pode criar uma nova branch do Git, fazer o commit das alterações e criar uma nova merge request?

O Claude Code encontra a ferramenta MCP create_merge_request e cuida da criação da MR diretamente, sem precisar trocar de contexto para o navegador.

No GitLab, o evento de criação da MR dispara automaticamente vários fluxos de trabalho em paralelo:

• pipeline de CI/CD para builds e testes automatizados
• verificação de segurança com o Advanced SAST para C++
• um Code Review Flow pelo GitLab Duo Agent Platform

Esses fluxos de trabalho automatizados e agênticos dentro do GitLab aceleram a entrega de software tanto quanto o Claude Code acelera o desenvolvimento com IA para a resolução de issues.

Você pode abrir a Merge Request no navegador ou continuar no terminal e enviar o seguinte prompt ao Claude Code:

A Merge Request está sendo executada corretamente?

Ele vai usar a ferramenta MCP get_merge_request_pipelines para buscar o status do pipeline da MR, confirmando que está verde e pronto para o merge.

Veja a gravação para ver como o Claude Code resolve o problema com a ajuda do servidor MCP do GitLab:

Claude Code como agente externo revisor

Neste último cenário, o Claude Code ajudou a implementar um novo recurso com base nos requisitos do Issue 24 — um servidor de API Spring Boot com backend REST/Websocket. Os pipelines de CI/CD e as verificações de segurança estão OK, mas há feedback de revisão de código esperando na MR.

Você pode adicionar o Claude Code como parceiro de colaboração em issues, epics e MRs e resolver tarefas em conjunto. Siga a documentação de agentes externos para conhecer os pré-requisitos.

Ative o Claude Agent by GitLab no menu do projeto, em AI > Agents. Anote o nome da conta de serviço para saber como mencionar ou atribuir o agente depois — ele segue o padrão: @ai-<nome-do-agente>-<nome-do-grupo-de-nível-superior>.

Em seguida, abra a MR com o feedback de revisão de código e analise as alterações solicitadas. A captura de tela usa a MR 78, e o GitLab Duo Code Review segue as instruções de revisão personalizadas para Java.

Crie um novo comentário mencionando o Claude Code Agent:

@ai-claude-agent-by-gitlab-<nome-do-grupo-de-nível-superior> Pode me ajudar a resolver o feedback da revisão?

Essa menção inicia uma nova sessão de agente em segundo plano, configurando o Claude Code Agent, que passa a trabalhar no feedback da revisão. Quando termina, ele segue as instruções para criar um commit no Git e um comentário com um resumo na MR.

Para garantir que o desenvolvimento de software permaneça dentro das diretrizes de proteção da sua organização, seus próximos passos incluem:

• Resolver o feedback de revisão restante.
• Revisar o aviso nos jobs do pipeline de CI/CD.
• Revisar as possíveis vulnerabilidades de segurança, usando, por exemplo, a Resolução de vulnerabilidades SAST.
• Obter a aprovação da merge request de um desenvolvedor elegível, configurado como Code Owner.

Assista a este vídeo para aprender como o Claude Code pode ajudar com revisões como agente externo no GitLab Duo Agent Platform:

Dicas para usar o Claude Code com o GitLab

Instruções personalizadas

É possível instruir os agentes a compilar e testar o código antes dos commits, manter as alterações mínimas ou entender melhor a arquitetura do projeto usando uma entrada no AGENTS.md. O Tanuki IoT Platform usa o seguinte exemplo de produção:

## Working with sensors

### Before editing
1. Identify the sensor directory you're working with
2. Check for an `AGENTS.md` file in that directory
3. Read sensor-specific instructions before making changes
4. Follow language-specific style guides

### Making changes
- Keep changes minimal and focused on the user request
- Do not refactor existing code unless specifically instructed
- Preserve original code formatting
- Only modify code necessary to solve the specific request

### Creating MRs
- Always run local builds and tests first
- Create a new branch for changes
- Automatically create a merge request after successful commits
- Reference relevant issues or tasks in the MR description

Essas instruções personalizadas também são processadas por agentes e flows no GitLab Duo Agent Platform.

O Claude Code prefere o CLAUDE.md, que também pode ser apontado para o AGENTS.md.

@AGENTS.md

Resumo

As ferramentas de programação com IA tornam as equipes de desenvolvedores mais rápidas na hora de programar. Porém, escrever código e entregar software não são a mesma coisa, e essa diferença entre os dois cresce justamente porque as ferramentas são muito boas na primeira parte. Com elas, mais código é escrito, mas o backlog de bugs aumenta, as taxas de falha nos pipelines sobem e as vulnerabilidades de segurança se acumulam.

O Claude Code mantém a produtividade onde o código se localiza: entende bases de código desconhecidas, propõe correções e estrutura novos recursos rapidamente. O GitLab Duo Agent Platform é o que transforma essa velocidade — de muitos desenvolvedores em times de software de organizações empresariais — em software seguro que você realmente pode entregar e certificar em diversos marcos de release e projetos. Com o GitLab, o restante do ciclo de vida do software (como as correções no pipeline de CI/CD, a verificação de segurança, a remediação automatizada, revisão de código e muito mais, com fluxos de trabalho que mantêm humanos no controle) permite que cada ação dos agentes de IA seja rastreada e configurada para funcionar dentro das diretrizes de proteção e políticas de segurança da sua organização.

Neste tutorial, você viu três formas de unir o Claude Code e o GitLab Duo Agent Platform:

• Corrigir um bug com o Claude Code e deixar que o GitLab CI/CD, a verificação de segurança e o Duo Code Review façam o resto.
• Adicionar contexto do GitLab via MCP para que o Claude trabalhe a partir do contexto real salvo no issue do GitLab, e não apenas dos arquivos locais.
• Usar um agente externo com tecnologia Claude no GitLab Duo Agent Platform para resolver o feedback de revisão diretamente na MR.

O princípio se mantém o mesmo nos três casos: o Claude avança rápido, o GitLab certifica o trabalho.

Se você ainda não usa o GitLab Duo Agent Platform, pode começar com um teste gratuito da ferramenta.

Se você já usa o GitLab no plano gratuito, pode assinar o GitLab Duo Agent Platform seguindo alguns passos simples.

E se você já é assinante do GitLab Premium ou Ultimate, basta ativar o Duo Agent Platform e começar a usar os GitLab Credits incluídos na sua assinatura.