Olá a todas as pessoas, vamos discutir os fundamentos de CI (Integração Contínua) e CD (Entrega Contínua) na prática. Antes, vamos falar sobre DevOps (Desenvolvimento e Operações).
Há uma máxima amplamente utilizada para definir DevOps: é cultura, não ferramenta; em essência, tampouco é um cargo. Para compreender por que esse conceito surgiu, precisamos voltar ao contexto anterior.
Historicamente, na área de tecnologia havia dois mundos separados: um time de desenvolvimento e outro de operações. O time de desenvolvimento buscava entregar software com rapidez, enquanto o time de operações priorizava manter tudo estável. Esses objetivos, na prática, frequentemente entravam em conflito.
Para reduzir essa tensão, nasceu DevOps para diminuir a fricção e aproximar quem constrói do software de quem mantém o sistema em funcionamento. Estabeleceu-se responsabilidade compartilhada para que a área opere como uma só, e não como duas áreas em constante atrito. O termo destaca a união de Development (Desenvolvimento) e Operations (Operações), com as iniciais em maiúsculas (D e O). Os objetivos centrais incluem automação, colaboração e retorno rápido.
Com esse entendimento, seguimos para CI (Integração Contínua), CD (Entrega Contínua) e publicação contínua.
CI (Integração Contínua) refere-se à prática de integrar mudanças pequenas e frequentes no repositório principal, com validações automáticas executadas continuamente. Em vez de acumular código por longos períodos, integramos em partes menores e identificamos problemas mais cedo. CI não é apenas builds (compilações) automáticas; é um hábito de integração frequente com validação automática, o que reduz conflitos, evita surpresas e acelera o retorno.
Ao passarmos para Continuous Delivery (Entrega Contínua) e Continuous Deployment (Publicação Contínua), surge uma distinção clássica de nomenclatura. Continuous Delivery (Entrega Contínua) significa que o software está sempre em condição de ser publicado: passou pelas validações, está empacotado e pronto, mas ainda depende de uma decisão humana para autorizar o deploy (publicação) em produção.
Continuous Deployment (Publicação Contínua) vai um passo além: publica automaticamente em produção toda mudança que já passou pelos critérios que chamaremos aqui de gates (critérios de aprovação). Esses gates podem incluir segurança, boas práticas e testes. Para que o deploy (publicação) ocorra, não é necessária ação manual. A diferença principal está justamente nesse último passo.
Em Delivery (entrega), a publicação está pronta, mas depende de uma decisão humana. Em Deployment (implantação), o fluxo segue automaticamente para produção, porque já definimos critérios considerados aceitos.
Agora, vamos ver um exemplo prático de pipeline (esteira). Vamos mostrar como funciona um repositório que já temos criado. Fechamos o terminal e, em seguida, abrimos um arquivo YAML que está na tela para discutirmos em aula.
O primeiro parâmetro é o name. Vamos detalhar o conteúdo. Trata-se de um YAML simples, que é o arquivo dentro desta pasta. Neste caso, estamos no GitHub, no workflow (fluxo de trabalho) do GitHub, isto é, o GitHub Actions. Em seguida, veremos esse fluxo sendo executado na prática; por ora, esta é uma visão simples para entendermos como funciona.
Começando pelo topo do arquivo, definimos o nome do workflow:
name: CI
No primeiro bloco, temos workflow_dispatch, pull_request e push. Chamamos isso de trigger (gatilho). O que é um gatilho? Sempre que executarmos um git push na ramificação main, será disparada a execução de todos os comandos na esteira. Portanto, quando houver um push, um pull_request ou um workflow_dispatch, o fluxo será iniciado.
Vamos adicionar os gatilhos. Note que comentamos o objetivo do pipeline e a ideia de “gates” (cada etapa aumenta a confiança para prosseguir):
# Este workflow materializa o pipeline minimo discutido na aula:
# checkout -> dependencias -> lint -> testes -> artefato.
#
# Cada etapa e um "gate" que aumenta a confianca antes da proxima promocao.
on:
push:
branches: [main]
pull_request:
branches: [main]
workflow_dispatch:
O que é o workflow_dispatch? É uma forma de executar manualmente. Se quisermos ir até a interface e clicar em “Run workflow” em Actions, será executado tudo o que está definido abaixo.
Abaixo, temos jobs. Nos jobs do CI (integração contínua), definimos:
Assim, será utilizada uma máquina hospedada no GitHub Actions para nós. Indicamos que desejamos essa máquina, que é Linux ubuntu-latest (a versão mais recente disponível).
Vamos declarar o bloco de jobs com o job principal, o nome e o runner:
jobs:
ci:
name: Pipeline de CI
runs-on: ubuntu-latest
Em seguida, há os steps, que são as etapas que serão executadas:
Primeiro, adicionamos o checkout do código e a configuração do Node.js com cache de dependências:
steps:
- name: Checkout do codigo
uses: actions/checkout@v4
- name: Configurar Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
Este projeto é em Node com Express, concebido de forma simples apenas para explicar o fluxo. Depois de instalar as dependências e executar o que for preciso, ao final, publicamos um artefato nesta esteira.
Vamos incluir a instalação de dependências com npm ci, que é adequada para ambientes de CI por ser determinística e rápida:
- name: Instalar dependencias
run: npm ci
Em seguida, acrescentamos as verificações de qualidade (lint) e os testes automatizados. Essas etapas funcionam como “gates” que precisam ser aprovados antes de prosseguir:
- name: Lint
run: npm run lint
- name: Testes
run: npm test
Com as validações passando, geramos o artefato (build) do projeto:
- name: Gerar artefato
run: npm run build
Por fim, publicamos o artefato para ficar disponível no resumo da execução do workflow (aba Summary) do GitHub Actions. Assim, é possível baixar e inspecionar o que foi produzido:
- name: Publicar artefato
uses: actions/upload-artifact@v4
with:
name: devops-pipeline-demo-${{ github.sha }}
path: dist/
retention-days: 7
Voltando à esteira: lembram-se do workflow_dispatch? Podemos executá-lo aqui selecionando a ramificação main e clicando em “Run workflow”. Ele será executado na prática e poderemos observar. Cada etapa que vimos no YAML é realizada: se olharmos nos logs, veremos a publicação do artefato e todas as etapas definidas. A primeira ação é o checkout do código, e, a partir daí, o trabalho progride até concluir.
Pronto. Vimos o que é uma esteira na prática e a execução completa. Observamos o trigger (gatilho), os estágios, os steps e o artefato gerado na esteira. É relevante mostrar onde o artefato é disponibilizado: por exemplo, na aba Resumo, conseguimos visualizar um artefato que pode ser baixado para inspecionarmos o que foi gerado. Podemos anexar relatórios, diversos conteúdos e formatos, como um JSON, entre outros.
Como exemplo do tipo de conteúdo que pode ser empacotado como artefato, poderíamos ter um arquivo JSON com metadados do build, como este:
{
"name": "devops-pipeline-demo",
"version": "1.0.0",
"builtAt": "2024-03-19T22:39:19.467Z",
"commit": "2aa0d7228dd1c28c8340d29d84688eaa39e6511"
}
Este é um exemplo para ilustrar o funcionamento. Na próxima aula, continuaremos com mais conteúdo.
Olá a todas as pessoas.
Neste curso, vamos abordar pipelines (fluxos de automação) e CI/CD, construindo uma visão completa sobre o tema: partiremos dos conceitos fundamentais até chegar às práticas modernas de pipelines (fluxos de automação) em produção. Passaremos por DevOps (integração entre desenvolvimento e operações), integração contínua, ramificação, portas de qualidade, ferramentas, Docker (ferramenta de contêineres), estratégias de implantação, segurança e métricas.
A ideia aqui não é memorizar sintaxe ou YAML (formato de configuração), nem se tornar refém das ferramentas, porque a ferramenta muda o tempo todo, o contexto muda, a plataforma muda. O objetivo é entendermos os princípios de validação, de fluxo, de segurança e de confiabilidade, que sempre permanecerão.
Vou falar um pouco sobre mim. Eu sou Eric, serei a pessoa instrutora aqui hoje. Já tenho mais de 18 anos de experiência na área de tecnologia, SRE (Engenharia de Confiabilidade de Sites), observabilidade e qualidade. Qualquer coisa, entrem em contato comigo também pelo Discord (plataforma de comunicação).
Hoje, quando falamos de fundamentos de CI/CD, o primeiro pensamento costuma ser automação. No entanto, não se resume a isso.
Quando pensamos em CI/CD, há muito mais envolvido. Na prática, tratamos de um sistema de entrega. Podemos encará-lo como a forma pela qual uma organização transforma código em mudanças em produção. Nosso objetivo é colocar essas mudanças em produção com a menor fricção possível e com o maior nível de segurança possível. Esse é o fundamento de CI/CD; é por isso que existe.
Ao longo deste curso, nós vamos avançar continuamente além da visão superficial de “temos um pipeline (esteira)” para uma visão mais madura. Vamos avaliar se essa esteira realmente ajuda a equipe a entregar melhor, se proporciona retroalimentação rápida — um de seus propósitos —, se protege a qualidade e se ajuda a escalar a engenharia. Escala é muito importante.
A mensagem principal que reforçaremos aqui é: pipeline (esteira) não é o que simplesmente se executa; é o que melhora a entrega da equipe. CI/CD não é apenas automação. CI/CD é fluxo de entrega com qualidade, segurança e velocidade.
Nos vemos no início desta Aula 1 em breve.
Olá a todos.
Vamos falar sobre Revisão de código e Proteção de branches. Antes de entrar no tema, reforçamos que temos falado bastante sobre um pipeline (esteira) robusto. Um pipeline robusto não elimina a revisão humana; ele melhora a qualidade da revisão. Na era da IA, muitas tarefas já foram automatizadas, e a revisão humana pode se concentrar no que realmente importa: arquitetura, clareza e impacto, além da identificação de riscos. Mantemos o controle. Esse é o ponto.
A Revisão de código, especificamente, não pode ser tratada como um ritual vazio. É um mecanismo importante de qualidade e, sobretudo, de compartilhamento de conhecimento.
Trouxemos alguns conceitos para fixarmos. Ainda vamos discutir bastante teoria aqui e, depois, veremos na prática. Vamos ver o material que preparamos, anotado em nosso Markdown (marcação).
Esses são os três pontos nos quais vamos fixar conceitos agora.
Qual problema a Revisão de código resolve? Em que ela ajuda? Anotamos os principais pontos que uma boa Revisão de código permite observar:
Além disso, a Revisão de código funciona como uma mentoria implícita e promove a difusão de conhecimento dentro do time. As pessoas do time ficam alinhadas sobre a mudança que está sendo enviada, com participação de quem realmente precisa estar envolvido naquela tarefa.
Agora passamos aos conceitos de Proteção de branches. São configurações presentes no dia a dia ao enviar código e que costumamos encontrar nos repositórios, como:
Também vamos tratar de Estratégia de merge (mesclagem) ao longo do conteúdo, conectando teoria e prática.
Às vezes, precisamos que o nosso Pull Request (solicitação de integração) passe por verificações automatizadas, os Status Checks (verificações de status). Também podemos definir pessoas obrigatoriamente requeridas para aprovação: responsáveis pelo repositório, pela área ou membros de um time. Frequentemente há um grupo aprovador.
O bloqueio de push (envio) direto é uma prática autoexplicativa, pois estamos falando de um ramo protegido. É governança, não burocracia. Não podemos fazer push (envio) de alterações o tempo todo sem nenhuma proteção no ramo principal.
É consenso que o ramo principal é o caminho mais confiável. Quando vamos fazer uma alteração nova, fazemos pull (obter) do ramo principal para ter a base, implementamos a mudança e, em seguida, fazemos o push (envio) do código. Proteger esse ramo é uma forma de manter organização no time, previsibilidade e disciplina.
Agora, estratégias de mesclagem. Vamos abordar rapidamente três conceitos que também funcionam como estratégias de proteção, pois impactam o histórico e a forma como o time lê a evolução do repositório.
Não existe uma estratégia de mesclagem universal. Gostamos de enfatizar que cada pessoa e cada time têm preferências, e a mais adequada é a que se alinha à forma de trabalho do time. Não há bala de prata.
É importante destacar um erro comum: não podemos usar a revisão como mecanismo absoluto. O ramo precisa ter a contraparte de estar protegido, porque isso poupa esforços em outros pontos. Revisão sem política de proteção vira um acordo informal, e isso não funciona. Ao formalizarmos a proteção, tudo se torna mais simples e tranquilo para evoluir.
Falamos sobre esses conceitos. Na nossa próxima aula, vamos discutir a pirâmide de testes. Quando falamos de qualidade, não podemos deixar de abordar esse tema; comentaremos rapidamente. Em seguida, falaremos sobre gates (barreiras de qualidade), cobertura e vulnerabilidades.
Eu vejo vocês lá. Agradeço a todas as pessoas.
O curso CI/CD e DevOps: implementar pipelines automatizados e seguros possui 134 minutos de vídeos, em um total de 50 atividades. Gostou? Conheça nossos outros cursos de Builds em DevOps, ou leia nossos artigos de DevOps.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Back-end, Dados, Front-end, DevOps, Mobile, Gestão & Negócios, UX & Design, Cibersegurança, Cloud, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Catálogo de tecnologia para quem é da área de Marketing
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
20% de desconto na Pós Tech
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Acesso ao catálogo da Casa do Código e leitura dentro da plataforma
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Modo entrevista - Pratique situações reais e evolua com feedback personalizado
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Lives CareerUp: eventos exclusivos com foco em empregabilidade e carreira
Mentorias de carreira: 2 encontros individuais com mentores do Talent Lab
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
