Questionário e Gabarito - Aula 9: Sprint 1 e CI/CD (2026-2)

Este documento contém as questões que devem ser enviadas aos alunos via GitLab Issues para a Lista L09 (Aula 9: Sprint 1 e CI/CD). O prazo final geral sugerido (Milestone) é 08/11/2026 (Domingo).

---

Questão 1: CI vs. CD (Continuous Delivery vs. Continuous Deployment) e o Fim do “Na Minha Máquina Funciona”

Due Date: 2026-11-08

Texto da Issue

Em equipes de desenvolvimento modernas, manter código isolado por semanas em branches individuais é uma das maiores fontes de risco operacional. A automação através de práticas de CI/CD surgiu para erradicar o famoso “na minha máquina funcionava” e o temido “inferno de integração (Merge Hell)”.

1. Estabeleça formalmente a distinção técnica entre Integração Contínua (CI), Entrega Contínua (Continuous Delivery) e Implantação Contínua (Continuous Deployment), destacando onde reside a decisão de negócio (gatilho manual vs. automático para o ambiente de produção). Por que a prática de CI exige que merges aconteçam em pequenos incrementos diários no repositório compartilhado?
2. O gatilho de CI no repositório do seu time: No projeto do seu Assistente I.A. no GitLab, detalhe a política de execução do pipeline:
   • Quais eventos no repositório disparam a validação automática (ex: push em branch de feature, abertura de Merge Request ou merge na branch main)?
   • O que acontece se um desenvolvedor tentar finalizar um Merge Request com o pipeline em falha (status vermelho)?

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo! Respostas puramente conceituais sem os dados reais do repositório da sua equipe não atingirão a nota máxima.)

Gabarito / Rubrica de Correção

• Excelente (10): Articula com precisão as fronteiras conceituais entre CI, Continuous Delivery e Continuous Deployment; explica o custo da ramificação prolongada vs. integração diária; detalha o fluxo de eventos e regras de bloqueio adotadas no repositório do time.
• Bom (7): Conhece as siglas, mas confunde Continuous Delivery com Continuous Deployment, ou traz uma visão vaga do pipeline do grupo.
• Insuficiente (0): Trata CI/CD como mero script de deploy ou não compreende a importância da integração contínua.

---

Questão 2: Anatomia do .gitlab-ci.yml: Estágios, Jobs, Imagens Docker e Runners

Due Date: 2026-11-08

Texto da Issue

No ecossistema do GitLab, toda a automação de compilação, testes e entrega é configurada de forma declarativa através do arquivo .gitlab-ci.yml, executado por agentes distribuídos chamados GitLab Runners.

1. Explique a estrutura hierárquica do arquivo de configuração do GitLab CI, diferenciando Estágios (Stages) — que definem a ordem de execução sequencial — de Jobs — que são as tarefas executadas (muitas vezes em paralelo) dentro de cada estágio. Por que o uso de imagens Docker customizadas por job é fundamental para garantir ambientes efêmeros, limpos e reprodutíveis?
2. A anatomia do pipeline do seu Assistente I.A.: Apresente os estágios configurados no pipeline do projeto do seu grupo (ex: lint/check, test, deploy/pages), citando:
   • Pelo menos 1 comando real executado no job de testes ou lint (ex: pytest, flake8, npm test, validação de requirements);
   • Como o pipeline garante que bibliotecas ou dependências externas não precisem ser baixadas do zero a cada execução (mecanismo de cache ou artifacts).

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

• Excelente (10): Domina a anatomia técnica do .gitlab-ci.yml (stages vs. jobs, runners e isolamento via containers Docker); detalha comandos reais de lint/testes e fundamenta a política de artefatos/cache no repositório da equipe.
• Bom (7): Sabe o básico do .gitlab-ci.yml, mas não compreende a diferença entre cache e artefatos, ou apresenta trechos genéricos sem relação com a aplicação do grupo.
• Insuficiente (0): Desconhece a sintaxe do GitLab CI ou confunde pipeline com Makefile local.

---

Questão 3: Testabilidade de Software com LLMs: Testes Determinísticos vs. Avaliação de Prompts

Due Date: 2026-11-08

Texto da Issue

Em softwares convencionais, os testes de unidade são determinísticos: se a função soma(2, 3) retornar qualquer valor diferente de 5, o teste falha com 100% de certeza. No desenvolvimento de aplicações com Modelos de Linguagem (LLMs), a resposta gerada possui natureza probabilística e não-determinística.

1. Como uma equipe de engenharia de software deve estruturar a suíte de testes automatizados no pipeline de CI para lidar com essa dualidade? Explique a separação necessária entre Testes Determinísticos (testes unitários de regras de negócio, parsers de JSON, validação de schemas de entrada/saída, tratamento de erros de rede/timeout) e Testes de Regressão de Prompts / Guardrails (verificação de tom socrático, limites de tokens e bloqueio de vazamento de respostas).
2. O teste automatizado do seu grupo: Descreva 1 teste automatizado real implementado (ou configurado no pipeline de CI) da sua aplicação do Assistente I.A. Mostre o que é inspecionado (ex: status code HTTP, schema retornado pelo backend, recusa de comandos maliciosos) e como esse teste protege o sistema contra quebras acidentais após um commit.

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

• Excelente (10): Compreende a fundo o desafio de engenharia da não-determinação em IA generativa; propõe com clareza a coexistência de testes determinísticos de backend com testes de validação de comportamento de prompts; detalha um teste automatizado prático do Assistente IA.
• Bom (7): Percebe que a IA varia as respostas, mas não sabe como testar isso de forma automatizada no CI, sugerindo apenas “testar na mão conversando com o bot”.
• Insuficiente (0): Afirma que aplicações com IA não podem ser testadas automaticamente ou ignora testes de backend.

---

Questão 4: Trunk-Based Development vs. GitFlow e a Proteção da Branch main

Due Date: 2026-11-08

Texto da Issue

A estratégia de ramificação de código (Branching Strategy) dita a velocidade e a estabilidade do fluxo de entrega de uma equipe. Enquanto o modelo clássico do GitFlow preconiza branches de longa duração (develop, release, feature, hotfix), equipes ágeis modernas migram crescentemente para o Trunk-Based Development.

1. Compare o modelo do GitFlow com o Trunk-Based Development (onde branches de feature são de curtíssima duração, durando no máximo 1 a 2 dias antes do merge na branch principal). Por que manter branches abertas por duas ou três semanas viola frontalmente a essência da Integração Contínua e multiplica o risco de conflitos catastróficos?
2. A blindagem da branch main no GitLab do time: Como o seu grupo configurou a governança de branches no repositório? Explique por que a branch main deve ser Protegida (Protected Branch), detalhando as regras obrigatórias de bloqueio (ex: proibição de commits diretos sem Merge Request, aprovação obrigatória de revisor e exigência de pipeline verde).

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

• Excelente (10): Contrasta com rigor GitFlow e Trunk-Based Development com foco em cadência de integração e resolução precoce de conflitos; detalha os mecanismos de branch protection e code review ativados no GitLab do projeto.
• Bom (7): Conhece branches do Git, mas não entende por que branches longas prejudicam a CI, ou descreve uma política frouxa sem regras formais no GitLab.
• Insuficiente (0): Defende que cada integrante commite diretamente na branch main sem revisão ou desconhece o que é uma branch protegida.

---

Questão 5: Gestão Segura de Segredos no CI/CD: Variáveis Mascaradas e Protegidas

Due Date: 2026-11-08

Texto da Issue

Para que um pipeline automatizado consiga executar testes de integração, acessar bancos de dados ou chamar APIs de Modelos de Linguagem (como OpenAI ou Google Gemini), o runner precisa ter acesso a credenciais e chaves criptográficas. No entanto, o histórico de acidentes da indústria está repleto de casos onde chaves privadas vazaram no console público de execução dos testes.

1. Quais os perigos de segurança decorrentes de expor segredos em texto puro no arquivo .gitlab-ci.yml ou permitir que scripts de teste imprimam variáveis no console (stdout/stderr)? Como a funcionalidade de CI/CD Variables do GitLab resolve isso através das diretivas de Masked (Mascarada) e Protected (Protegida)?
2. A gestão de segredos no seu time: Como o seu grupo configurou o acesso à chave da API da LLM (Gemini/OpenAI) ou token de mensageria (Telegram/Discord) no repositório do Assistente I.A.? Explique como um novo desenvolvedor que clone o projeto consegue rodar localmente sem comprometer os segredos de produção no Git.

(Lembre-se: Arraste a Issue para “Doing” no Board Kanban e escreva a resposta nos comentários abaixo!)

Gabarito / Rubrica de Correção

• Excelente (10): Analisa a superfície de ataque em pipelines de automação; explica com exatidão o funcionamento das variáveis Masked (ocultação de regex nos logs) e Protected (restritas a branches/tags protegidas); descreve a separação limpa entre ambiente local (.env.example sem chaves) e ambiente de CI/CD.
• Bom (7): Conhece as variáveis do GitLab, mas confunde variáveis protegidas com mascaradas, ou não explica como a equipe trabalha localmente sem subir chaves.
• Insuficiente (0): Sugere colocar chaves no repositório ou não compreende os riscos de vazamento em logs.