Checklist de prontidão
Marcações ficam salvas somente neste navegador.
- Reunião de prontidão
- Cliente
- Cliente
- Preflight automático
- Reunião de prontidão
- Cliente
- Cliente
- Reunião de prontidão
- Preflight automático
- Reunião de prontidão
- Reunião de prontidão
- Reunião de prontidão
- Reunião de prontidão
Este documento é enviado depois da escolha da oferta PS-CAP-01 — Capacitação na plataforma GitLab. Ele lista o que o cliente provisiona e informa à Pointer, separado pelo destino dos exercícios práticos (grupo da Pointer no GitLab.com ou instância GitLab do cliente), a credencial entregue quando os exercícios rodam na instância do cliente e o checklist de prontidão conferido antes da abertura de cada turma. O prazo de devolução é definido no kick-off.
Com os exercícios no grupo da Pointer no GitLab.com, o cliente não entrega credencial e nada é instalado no ambiente do cliente. Os exercícios que dependem de ambiente preparado (VM ou instância por aluno, cluster Kubernetes, URL de teste, servidor LDAP, framework de compliance, GitLab Duo Agent Platform com GitLab Credits) são sob consulta e têm os pré-requisitos definidos em proposta específica.
- Destino dos exercícios práticos
- O que o cliente provisiona (os dois destinos)
- Instância GitLab do cliente (quando é o destino dos exercícios)
- Exercícios por tier
- Proteção de dados pessoais (LGPD)
- Senha dos resultados
- Credenciais que o cliente entrega à Pointer
- Informações a enviar
- Checklist de prontidão
1. Destino dos exercícios práticos
| Item | Grupo da Pointer no GitLab.com | Instância GitLab do cliente |
|---|---|---|
| Onde ficam os projetos dos alunos | Grupo da Pointer no GitLab.com: um subgrupo por turma e, dentro dele, um subgrupo por aluno, com o aluno como Owner. | Grupo pai indicado pelo cliente: um subgrupo por turma e, dentro dele, um subgrupo por aluno, com o aluno como Owner. |
| Usuários dos alunos | Conta de cada aluno no GitLab.com. | Usuário de cada aluno já existente na instância. |
| Tier | GitLab Ultimate: todos os exercícios com correção automática. | Tier da instância: exercício GitLab Premium ou GitLab Ultimate só entra com a instância no tier exigido (tabela Exercícios por tier). |
| Assentos | Assentos GitLab Ultimate do grupo da Pointer, compartilhados entre as turmas abertas; voltam com a remoção dos exercícios da turma encerrada ou com a expiração do acesso. | Conforme a assinatura da instância do cliente. |
| Pipelines dos exercícios | Runners hospedados do GitLab.com. | Runners da instância disponíveis aos projetos dos alunos (seção Instância GitLab do cliente). |
| Credencial entregue à Pointer | Nenhuma. | Token do grupo pai (seção Credenciais). |
| Instalação no ambiente do cliente | Nenhuma. | Runner na rede do cliente, quando a instância não é alcançável a partir dos runners hospedados do GitLab.com. |
- Nos dois destinos, o site da turma (portal, formulários, verificação de certificados e resultados cifrados) é publicado no GitLab Pages do projeto do engajamento, no GitLab.com da Pointer.
- O acesso de cada aluno aos projetos dos exercícios expira na data da última sessão somada aos dias definidos no contrato (padrão: 30 dias).
2. O que o cliente provisiona (os dois destinos)
| Item | Especificação | Obrigatório |
|---|---|---|
| Lista de alunos por turma | Nome, e-mail e usuário GitLab de cada aluno; o usuário já existe na instância dos exercícios (no grupo da Pointer, conta no GitLab.com). E-mail e usuário sem repetição na turma. A ordem da lista define os pares de colegas de turma dos exercícios em dupla (turma ímpar: os três últimos em trio); aluno incluído depois entra no fim da lista. Aluno sem usuário participa das sessões, da presença e das avaliações e fica fora dos exercícios. | Sim |
| Agenda das sessões | Por turma: trilha ou módulos e formato (remoto ao vivo, presencial in company ou híbrido); por sessão: data, horário de início e de fim e módulos. Sessões em blocos de 4 h ou dias de 6 h a 8 h divididos em blocos de 3 h ou 4 h. | Sim |
| Responsável pela capacitação | Nome e cargo; aparecem na capa do relatório da turma. | Sim |
| Ciência dos alunos sobre o tratamento de dados (LGPD) | Alunos informados, antes da primeira sessão, do termo de consentimento aceito em cada formulário de presença e de avaliação: tratamento do e-mail pela Pointer exclusivamente para registrar presença e avaliações da capacitação e emitir o certificado, nos termos da Lei 13.709/2018. | Sim |
| Acesso ao site da turma e à API do GitLab.com | Navegador com acesso, a partir da rede ou do dispositivo de cada aluno, ao site da turma no GitLab Pages (domínio gitlab.io, acesso público) e à API do GitLab.com, que recebe o envio dos formulários pela API de trigger do projeto do engajamento. | Sim |
| Acesso à instância dos exercícios | Navegador com acesso de cada aluno ao GitLab.com (grupo da Pointer) ou à instância do cliente, durante as sessões e até a expiração do acesso. | Sim |
| Logo do cliente | Arquivo de imagem com autorização de uso; aparece no cabeçalho do site, sobre placa branca. | Não |
- Presença e avaliações pré e pós exigem o e-mail cadastrado na lista da turma; a pesquisa de satisfação é anônima.
- A presença é aceita só com o código da sessão, informado pelo instrutor durante a sessão, dentro do horário da sessão com a tolerância configurada (padrão: 2 horas antes do início e depois do fim).
3. Instância GitLab do cliente (quando é o destino dos exercícios)
| Item | Especificação | Obrigatório |
|---|---|---|
| URL da instância | Endereço https:// da instância GitLab do cliente. Os exercícios e a correção automática seguem a documentação da versão 19.4 da plataforma GitLab; a versão da instância é informada no formulário. | Sim |
| Grupo pai | Grupo já existente onde são criados o subgrupo de cada turma e o subgrupo de cada aluno. A criação e a correção dos exercícios atuam só dentro desse grupo. Restrição de associação de membros configurada no grupo impede a inclusão dos alunos. | Sim |
| Token do grupo pai | Escopo api e papel Owner no grupo pai (group access token ou token de service account), cadastrado como variável de CI/CD protegida e mascarada no projeto do engajamento (seção Credenciais). | Sim |
| Tier da instância | GitLab Free, GitLab Premium ou GitLab Ultimate, declarado na configuração do engajamento. A validação recusa turma com exercício acima do tier declarado; com tier menor, a turma lista só os exercícios compatíveis. | Sim |
| Usuários dos alunos | Usuário já existente na instância para cada aluno com exercícios. A criação de usuários pelo pipeline está no roadmap. | Sim |
| Usuário do instrutor | Usuário do instrutor da Pointer na instância. Recebe Maintainer no grupo de cada turma e aprova o merge request do exercício de regra de aprovação e CODEOWNERS; sem ele, esse exercício fica fora da turma. | Condicional: exercício de regra de aprovação e CODEOWNERS (GitLab Premium) |
| Usuário de demonstração da Pointer | Usuário na instância para o aluno de demonstração da Pointer, incluído na lista da turma, usado pelo instrutor para demonstrar os exercícios e conferir a criação e a correção dos exercícios antes da primeira turma. | Sim |
| Runners para os pipelines dos exercícios | Runners Linux disponíveis aos projetos dos alunos (runners de instância ou do grupo pai), com executor Docker ou Kubernetes e acesso às imagens de contêiner usadas pelos pipelines dos exercícios (alpine:3.20, python:3.12-slim, docker:27) e pelos templates CI/CD de segurança da plataforma GitLab. SAST exige runner Linux com executor Docker ou Kubernetes (documentação GitLab 19.4). | Sim |
| Docker-in-Docker e container registry | Runner com Docker-in-Docker (modo privilegiado) e container registry habilitado na instância, para os exercícios que constroem e publicam imagem: imagem no container registry, pacote genérico e limpeza (alerta do exercício no catálogo) e varreduras de segurança, cujo pipeline inicial constrói a imagem com o serviço docker:27-dind e a publica no container registry do projeto. | Condicional: módulos de container registry e de varreduras de segurança |
| Componente OpenTofu | Componente OpenTofu do CI/CD Catalog (projeto components/opentofu) disponível na instância, espelhado, e imagem do componente acessível pelos runners. | Condicional: exercício de OpenTofu com estado gerenciado (módulo de IaC e Kubernetes) |
| Runner do projeto do engajamento na rede do cliente | Máquina Linux na rede do cliente com runner registrado no projeto do engajamento no GitLab.com (executor Docker ou Kubernetes), somente conexões de saída: HTTPS para a instância e para gitlab.com e registry.gitlab.com (imagem dos jobs). Executa a criação, a correção e a remoção dos exercícios. | Condicional: instância não alcançável a partir dos runners hospedados do GitLab.com |
| Certificado da CA corporativa | Certificado (PEM) da autoridade certificadora que emitiu o certificado HTTPS da instância, cadastrado como variável de CI/CD do tipo arquivo no projeto do engajamento. | Condicional: certificado da instância não emitido por CA pública |
| GitLab Duo Code Review | Disponível e habilitado no grupo pai dos exercícios: sim ou não. Com ele, o instrutor ou o aluno chama a orientação automática no merge request de cada exercício (Tutor PS). Se não, o retorno nos merge requests dos exercícios fica com o instrutor; a criação e a correção dos exercícios não mudam. | Não: informativo |
- Os itens condicionais dependem dos módulos das turmas: a validação da configuração lista, por turma, os exercícios incluídos e, com a instância do cliente, o requisito de cada exercício.
- Proxy de saída na rede do runner do projeto do engajamento: endereço e exceções informados no formulário.
4. Exercícios por tier
| Tier exigido | Exercícios com correção automática (módulo) |
|---|---|
| GitLab Premium | Push rule de mensagem de commit (repositório Git); regra de aprovação e CODEOWNERS (merge requests e revisão de código); épico com issues, iteração e pesos (gestão de portfólio); merged results e merge train (pipelines avançados); ambiente protegido com aprovação de deploy (entrega contínua). |
| GitLab Ultimate | Deploys e value stream (métricas de entrega); secret push protection e dependency scanning por SBOM (varreduras de segurança); triagem e correção de vulnerabilidades (gestão de vulnerabilidades); scan execution policy e merge request approval policy (políticas de segurança). |
| GitLab Free | Os demais 16 exercícios com correção automática. |
- No grupo da Pointer no GitLab.com, todos os exercícios rodam em GitLab Ultimate.
5. Proteção de dados pessoais (LGPD)
- A lista de alunos (nome, e-mail e usuário GitLab), as presenças, as respostas das avaliações, o registro da criação dos exercícios e as correções ficam no repositório privado do projeto do engajamento.
- A presença é gravada com uma referência derivada do e-mail, sem o e-mail; a pesquisa de satisfação é anônima.
- O site publica só resultados cifrados por senha (AES-256-GCM, chave derivada por PBKDF2-SHA256 com 600 mil iterações), decifrados no navegador; a página pública de verificação mostra só tipo do documento, trilha, carga, período e iniciais do aluno.
- Logs dos jobs sem tokens e sem e-mails.
- O prazo de retenção dos dados pessoais é definido no contrato; ao fim do prazo, o projeto do engajamento é excluído. A exclusão só dos arquivos das turmas não basta, porque arquivos apagados continuam no histórico do repositório.
- A exclusão do projeto remove também o site da capacitação, inclusive a página pública de verificação dos certificados e declarações: o prazo de retenção cobre o período em que a verificação fica disponível. Os PDFs do relatório, dos certificados e das declarações ficam com o cliente.
- As respostas da pesquisa de satisfação são anônimas e só são mantidas de forma agregada, como no relatório da turma.
6. Senha dos resultados
A senha de acesso aos resultados é gerada pela Pointer na preparação do projeto do engajamento, exibida uma única vez e entregue ao cliente por canal separado.
7. Credenciais que o cliente entrega à Pointer
Nenhum valor secreto é enviado por e-mail, chat, issue ou arquivo. A credencial é cadastrada como variável de CI/CD do projeto do engajamento com as opções Protected e Masked and hidden; a configuração do engajamento guarda só o nome da variável. O token é enviado só à própria instância e não aparece nos logs. Com os exercícios no grupo da Pointer no GitLab.com, o cliente não entrega credencial.
| Credencial | Finalidade | Permissões | Formato e validade | Obrigatório |
|---|---|---|---|---|
| Token do grupo pai dos exercícios | Criação dos subgrupos, membros e projetos dos alunos, correção automática dos exercícios e remoção dos exercícios da turma. | Escopo api e papel Owner no grupo pai (group access token ou token de service account): cria subgrupos, inclui o aluno como Owner do próprio subgrupo e o instrutor como Maintainer do grupo da turma, cria projetos e, na correção, lê configurações, variáveis de CI/CD e eventos de auditoria dos projetos dos alunos. |
Token (uma linha) Até a remoção dos exercícios da última turma; revogado pelo cliente no encerramento. |
Condicional: exercícios na instância do cliente |
8. Informações a enviar
Informações sem sigilo, devolvidas pelo cliente antes da reunião de prontidão. Os campos marcados como obrigatórios são conferidos pela validação automática do pipeline.
Identificação
| Informação | Exemplo | Obrigatório | Observação |
|---|---|---|---|
| Nome do órgão ou da empresa | Órgão Exemplo | Sim | Aparece no site, no relatório e nos certificados. |
| Sigla | EXEMPLO | Sim | Até 24 caracteres: letras, números, espaço, ponto, sublinhado, hífen e parênteses. |
| Setor | Público | Não | Público ou privado. |
| Responsável pela capacitação | Nome, cargo | Sim | Aparece na capa do relatório da turma. |
| Ponto focal | Nome, cargo, e-mail | Sim | Agenda, listas de alunos, acessos e validação. |
Turmas
| Informação | Exemplo | Obrigatório | Observação |
|---|---|---|---|
| Trilha ou módulos de cada turma | Fundamentos da plataforma GitLab | Sim | Uma trilha, um subconjunto ou uma combinação de módulos do catálogo. |
| Formato | Remoto ao vivo | Sim | Remoto ao vivo, presencial in company ou híbrido. |
| Sessões: data, início, fim e módulos | 2026-11-03, 09:00–13:00, organização e repositório Git | Sim | Datas AAAA-MM-DD; horários HH:MM no fuso informado. |
| Fuso das sessões | -03:00 | Não | Padrão: -03:00. |
| Tolerância da presença, em horas | 2 | Não | De 0 a 72; padrão 2. |
| Regra de aprovação | 75 / 70 / 70 | Não | Presença mínima, nota pós mínima e percentual mínimo de critérios dos exercícios, de 0 a 100; padrão 75, 70 e 70; definida no contrato. |
| Questões por módulo na avaliação pré e pós | 5 | Não | De 1 a 10; padrão 5. |
Alunos (uma lista por turma)
| Informação | Exemplo | Obrigatório | Observação |
|---|---|---|---|
| Nome | Aluna Exemplo Um | Sim | Aparece no certificado ou na declaração. |
| aluna.um@exemplo.gov.br | Sim | Usado na presença e nas avaliações; sem repetição na turma. | |
| Usuário GitLab | aluna.exemplo1 | Condicional: aluno com exercícios | Usuário já existente na instância dos exercícios (no grupo da Pointer, conta no GitLab.com); sem repetição na turma. |
Destino dos exercícios
| Informação | Exemplo | Obrigatório | Observação |
|---|---|---|---|
| Destino | Grupo da Pointer no GitLab.com | Sim | Grupo da Pointer no GitLab.com ou instância GitLab do cliente. |
| Dias de acesso após a última sessão | 30 | Não | Padrão 30; 0 = sem expiração. |
| URL da instância | https://gitlab.cliente.gov.br | Condicional: instância do cliente | https:// seguido do host. |
| Versão da instância | 19.4.1 | Condicional: instância do cliente | |
| Tier da instância | GitLab Ultimate | Condicional: instância do cliente | Define os exercícios GitLab Premium e GitLab Ultimate que entram nas turmas. |
| GitLab Duo Code Review no grupo pai | Sim | Condicional: instância do cliente | Disponível e habilitado: sim ou não. Se não, o retorno nos merge requests dos exercícios fica com o instrutor. |
| Caminho do grupo pai | capacitacao/turmas-2026 | Condicional: instância do cliente | Grupo já existente. |
| Usuário do instrutor | instrutor.pointer | Condicional: exercício de regra de aprovação e CODEOWNERS | Usuário na instância. |
| Usuário de demonstração da Pointer | demo.pointer | Condicional: instância do cliente | Usuário na instância. |
| Acesso à instância a partir da internet | Não | Condicional: instância do cliente | Sem acesso a partir dos runners hospedados do GitLab.com: runner do projeto do engajamento na rede do cliente. |
| Proxy de saída do runner do projeto do engajamento | http://proxy.cliente.gov.br:3128; exceções: *.cliente.gov.br | Condicional: saída por proxy | |
| Autoridade certificadora da instância | AC interna | Condicional: CA não pública | O certificado PEM da CA é cadastrado como variável do tipo arquivo. |
| Caminho do componente OpenTofu espelhado | components/opentofu | Condicional: exercício de OpenTofu | |
| Runners dos exercícios: executor, Docker-in-Docker e container registry | Runner de instância, executor Docker, modo privilegiado; registry habilitado | Condicional: instância do cliente | Docker-in-Docker e container registry para os módulos de container registry e de varreduras de segurança. |
Identidade visual
| Informação | Exemplo | Obrigatório | Observação |
|---|---|---|---|
| Logo do cliente e autorização de uso | logo.png | Não | Exibido sobre placa branca no cabeçalho do site. |
9. Checklist de prontidão
Itens conferidos antes da execução. "Preflight automático" indica verificação feita pelo pipeline contra o ambiente real; os demais são conferidos na reunião de prontidão ou pelo cliente.
| ☐ | Item | Verificado por |
|---|---|---|
| ☐ | Formulário de informações devolvido e revisado com a Pointer: turmas, agenda das sessões e regra de aprovação. | Reunião de prontidão |
| ☐ | Lista de alunos de cada turma enviada com nome, e-mail e usuário GitLab já existente na instância dos exercícios. | Cliente |
| ☐ | Alunos informados sobre o tratamento dos dados e o termo de consentimento (LGPD); prazo de retenção definido no contrato. | Cliente |
| ☐ | Configuração das turmas e listas de alunos validadas pelo pipeline do engajamento: e-mails e usuários sem repetição, sessões e módulos coerentes, exercícios compatíveis com o tier do destino e códigos de presença gerados para todas as sessões. | Preflight automático |
| ☐ | Destino dos exercícios definido; no grupo da Pointer no GitLab.com, soma de alunos das turmas abertas conferida. | Reunião de prontidão |
| ☐ | Site da turma aberto na rede e nos dispositivos dos alunos (portal e um formulário). | Cliente |
| ☐ | Senha dos resultados recebida pelo cliente por canal separado. | Cliente |
| ☐ | Instância do cliente: grupo pai existente, sem restrição de associação que impeça a inclusão dos alunos; token com escopo api e papel Owner no grupo pai cadastrado como variável protegida e mascarada. | Reunião de prontidão |
| ☐ | Instância do cliente: usuários dos alunos, do instrutor e de demonstração existentes; criação dos exercícios sem erro (o job confere o grupo pai e cada usuário na instância). | Preflight automático |
| ☐ | Instância do cliente: GitLab Duo Code Review disponível e habilitado no grupo pai dos exercícios registrado como sim ou não; se não, o retorno nos merge requests dos exercícios fica com o instrutor. | Reunião de prontidão |
| ☐ | Instância do cliente: runners disponíveis aos projetos dos alunos; Docker-in-Docker e container registry quando as turmas incluem os módulos de container registry e de varreduras de segurança; componente OpenTofu espelhado quando a turma inclui o exercício de OpenTofu. | Reunião de prontidão |
| ☐ | Instância do cliente: runner do projeto do engajamento com acesso HTTPS à instância, quando ela não é alcançável a partir do GitLab.com; certificado da CA corporativa cadastrado quando o certificado da instância não é de CA pública. | Reunião de prontidão |
| ☐ | Instância do cliente: exercícios da turma conferidos com o usuário de demonstração da Pointer antes da primeira sessão. | Reunião de prontidão |