DevOps para SEFAZ-CE na FCC: Git/Gitflow, CI/CD, qualidade contínua e DevSecOps (o que mais cai)

Quando a FCC cobra DevOps, ela costuma trabalhar com uma ideia bem objetiva: como o software sai do código e chega em produção com qualidade, velocidade e controle. Por isso, as questões geralmente misturam conceitos de versionamento, automação, pipeline, ferramentas e segurança — e o candidato erra quando confunde camadas (por exemplo, Docker com Kubernetes) ou quando acha que DevOps é “uma ferramenta”.

Neste artigo, vou focar no que mais aparece em prova para SEFAZ-CE: Git e Gitflow, CI/CD, qualidade contínua, containers e orquestração, observabilidade e DevSecOps.

DevOps não é “uma ferramenta”: é fluxo, cultura e automação

DevOps é um conjunto de práticas para integrar desenvolvimento e operações, reduzindo atrito e aumentando a capacidade de entregar mudanças com segurança. Em prova, a banca tenta te “vender” DevOps como sinônimo de Jenkins, Docker ou GitHub. Não caia: essas ferramentas podem existir em ambientes DevOps, mas o conceito é maior: processo + automação + feedback.

Git e Gitflow: o básico que a FCC adora confundir

O Git é um controle de versão distribuído: você tem histórico local, trabalha com commits, branches e merges. Já o Gitflow é um modelo de ramificação (uma estratégia de uso do Git), com papéis bem definidos para organizar trabalho paralelo e versões.

Um esquema típico do Gitflow envolve:

• main/master: versão estável (geralmente produção) 
• develop: integração do que vai virar release 
• feature: novas funcionalidades 
• release: estabilização para lançar versão 
• hotfix: correções urgentes em produção 

Pegadinha clássica: Gitflow não faz build, não roda teste, não faz deploy. Ele organiza o versionamento. Quem executa essas etapas é o pipeline de CI/CD.

CI/CD: saber a ordem e o significado resolve metade da prova

• CI (Integração Contínua): integrar alterações com frequência e validar automaticamente (build + testes). 
• CD (Entrega Contínua): manter o sistema pronto para implantar, com etapas automatizadas e, se necessário, aprovações. 
• Implantação Contínua: levar automaticamente para produção após passar no pipeline. 

A FCC costuma tratar CI/CD como um processo relacionado chamado pipeline, com etapas encadeadas do commit até o feedback. Outra pegadinha comum é dizer que CI “é deploy em produção”. Em geral, isso é falso.

Qualidade contínua: SonarQube e “quality gate” como trava do pipeline

Em ambientes DevOps, a qualidade é tratada como algo contínuo. Ferramentas como SonarQube são usadas para análise estática do código, apontando problemas como:

• bugs prováveis, 
• vulnerabilidades, 
• code smells, 
• duplicações, 
• e indicadores ligados a testes (como cobertura). 

O ponto mais cobrado é o quality gate: um conjunto de critérios mínimos que pode bloquear a promoção de uma versão no pipeline caso não atinja o padrão estabelecido.

Pegadinha: SonarQube não substitui testes funcionais, testes de carga ou revisão humana. Ele ajuda a reduzir risco, mas não “garante ausência de falhas”.

Docker, Kubernetes e Helm: três camadas que a FCC troca de propósito

Aqui mora muito erro de prova, porque as alternativas misturam conceitos.

• Docker: empacota aplicação e dependências em uma imagem. O container é a instância dessa imagem em execução. 
• Kubernetes: orquestra containers (deploy, escala, recuperação, serviços, alta disponibilidade) em um cluster. 
• Helm: gerenciador de pacotes para Kubernetes. Você instala e atualiza aplicações usando charts, com parâmetros e possibilidade de rollback. 

Pegadinhas clássicas:

• “Kubernetes substitui Docker” → errado (orquestra containers; não é a mesma coisa). 
• “Helm substitui Kubernetes” → errado (Helm opera dentro do Kubernetes, facilitando a gestão de aplicações). 

Observabilidade: o que monitorar e por quê

A FCC pode cobrar observabilidade como capacidade de entender o sistema em produção. O tripé mais cobrado é:

• métricas (latência, erros, throughput, uso de recursos), 
• logs (eventos e contexto), 
• traces (caminho de uma requisição entre serviços). 

Ferramentas como Prometheus aparecem fortemente ligadas a coleta de métricas e alertas.

DevSecOps: segurança dentro do pipeline (shift left)

DevSecOps é a evolução do DevOps com segurança integrada desde o início. Em prova, a ideia-chave é “shift left”: trazer verificações para mais cedo, automatizando checagens no CI/CD.

Siglas que costumam aparecer:

• SAST: análise estática (sem executar a aplicação). 
• DAST: análise dinâmica (aplicação em execução, “de fora para dentro”). 
• IAST: combina execução com instrumentação durante testes. 
• RASP: proteção e monitoramento em tempo de execução. 

Pegadinha: “segurança só no fim para não atrasar” → a lógica do DevSecOps é justamente o contrário.

Questões FCC (múltipla escolha)

1) Na abordagem DevOps, a integração e a entrega contínuas (CI/CD) juntas são comumente tratadas como um processo relacionado, conhecido como

A) GitHub
B) Container registry
C) End-to-end
D) Pipeline
E) Hub register

Gabarito: D

2) Assinale a alternativa correta:

A) Gitflow é um versionador distinto do Git e substitui o controle de versão distribuído
B) Git é uma estratégia de ramificação; Gitflow é a ferramenta de versionamento
C) Gitflow organiza branches (main, develop, feature, release, hotfix), mas não executa build ou deploy
D) Gitflow elimina a necessidade de CI/CD, pois garante integração automática por design
E) Git é incompatível com pipelines automatizados, pois depende de merges manuais sem validação

Gabarito: C

3) Em um pipeline de CI/CD, uma ferramenta como SonarQube é utilizada principalmente para

A) orquestrar containers em um cluster e manter o estado desejado
B) empacotar aplicações como charts para instalação em Kubernetes
C) realizar análise estática do código e apoiar decisões com quality gate
D) substituir testes funcionais por inspeção automática de código
E) coletar logs centralizados e gerar traces distribuídos por padrão

Gabarito: C

4) Em relação a Docker, Kubernetes e Helm, assinale a alternativa correta:

A) Docker é uma VM completa, com kernel próprio, por isso substitui Kubernetes
B) Kubernetes substitui Docker, pois executa imagens sem containers
C) Helm é um orquestrador que elimina a necessidade de Kubernetes
D) Docker empacota em imagens/containers; Kubernetes orquestra; Helm gerencia charts e releases no Kubernetes
E) Helm e Kubernetes são equivalentes e diferem apenas por sintaxe YAML

Gabarito: D

5) Em DevSecOps, “shift left security” significa

A) concentrar verificações de segurança apenas na fase final do desenvolvimento
B) integrar segurança ao pipeline de CI/CD para detectar vulnerabilidades mais cedo
C) substituir ferramentas automatizadas por auditorias manuais periódicas
D) executar somente testes de performance como forma de prevenção
E) delegar segurança exclusivamente à equipe de operações

Gabarito: B