Página de boas-vindas à plataforma GitLab contratada, reutilizável por cliente e publicada no GitLab Pages: a assinatura e a instância, para que serve o Customers Portal e o Support Portal, como abrir e acompanhar um chamado na GitLab, os SLAs oficiais de primeira resposta do Priority Support, o que o suporte da GitLab cobre e não cobre e como a Pointer apoia antes, durante e depois de um chamado. Os fatos oficiais vêm da documentação e do portal de suporte da GitLab, com fonte e data de consulta. Em engajamento com avaliação, a página integra o site da avaliação e traz uma seção personalizada, cifrada, com o Customer Success Plan, a maturidade e o levantamento da plataforma.
1. Para quem
- Todo o time do cliente que usa ou administra a plataforma GitLab contratada: administradores, contatos de suporte cadastrados na GitLab, responsáveis pela assinatura e pelas faturas e gestores.
- Clientes com assinatura GitLab Premium ou GitLab Ultimate, nas ofertas GitLab self-managed, GitLab.com ou GitLab Dedicated. O plano gratuito não inclui suporte da GitLab e não é atendido por esta oferta.
- Clientes em engajamento Pointer de avaliação, implantação, migração ou operação assistida, na transferência de conhecimento e antes do início da operação assistida, quando contratada.
2. Onde executamos
A página é publicada no GitLab Pages do projeto do engajamento, no GitLab.com da Pointer:
- Com avaliação (PS-AVA-01): página Onboarding do site da avaliação, com acesso pelo portal do site.
- Sem avaliação: site próprio de onboarding no projeto do engajamento de implantação, migração ou operação assistida.
Nada é instalado no ambiente do cliente: a geração da página não acessa a instância GitLab do cliente, e o time do cliente acessa a página pelo navegador. O acesso segue a visibilidade do GitLab Pages do projeto do engajamento, definida com o cliente.
3. Escopo do serviço
- Página de onboarding gerada pelo pipeline Pointer a partir da configuração versionada no repositório do engajamento e publicada no GitLab Pages, com as seções a seguir, na ordem da página.
- A sua plataforma GitLab: plano (GitLab Premium ou GitLab Ultimate), oferta (GitLab self-managed, GitLab.com ou GitLab Dedicated), forma de ativação no GitLab self-managed (activation code ou arquivo de licença), URL, versão e arquitetura da instância.
- Seção personalizada «O seu caso de uso» (só no site da avaliação): objetivo geral e até 5 iniciativas do Customer Success Plan com maior pontuação, casos de uso, nota geral da maturidade na última rodada com os 3 domínios de menor percentual (prioridades) e, com mais de 3 domínios, os 2 de maior percentual (destaques), e o retrato do levantamento por origem coletada (tipo, escopo, projetos, usuários e adoção de CI). Cifrada com o mesmo esquema dos resultados da avaliação (AES-256-GCM) e decifrada no navegador com a senha dos resultados; pode ser desligada.
- Customers Portal: autoatendimento da assinatura e do faturamento (acompanhar a assinatura, ver e pagar faturas, consultar o activation code e baixar o arquivo de licença), forma de acesso e papéis (Billing account manager, Subscription contact e Billing contact). Ativação online pelo activation code: recurso nativo que requer conexão HTTPS de saída da instância para customers.gitlab.com na porta 443; sem internet, arquivo de licença e envio mensal do arquivo de uso de licença à GitLab.
- Support Portal: canal oficial de chamados técnicos da GitLab para GitLab self-managed e GitLab.com. Só abrem chamado os contatos de suporte cadastrados da organização (até 30); inclusão ou troca de contatos por chamado ao time de Support Readiness da GitLab; dados que comprovam o direito a suporte no GitLab self-managed.
- Como abrir e acompanhar um chamado na GitLab: escolha do motivo do chamado, impacto pelas definições oficiais, informações do problema (versão, arquitetura, passos já tentados e logs) e o que não enviar; acompanhamento pelo portal, resposta pelo e-mail de notificação, inclusão de colegas pelo portal e prazos de pendência e reabertura; formulário de emergência.
- SLAs oficiais do Priority Support, incluído nas assinaturas GitLab Premium e GitLab Ultimate (GitLab self-managed e GitLab.com). Os prazos são de primeira resposta, não de resolução: Emergência (instância de produção indisponível ou completamente inutilizável), 30 minutos (24x7); Alto impacto, 4 horas; Médio impacto, 8 horas; Baixo impacto, 24 horas (24x5, de domingo 15h a sexta 17h, horário do Pacífico); licença e faturamento, até 8 horas em dias úteis.
- O que o suporte da GitLab cobre e não cobre: funcionalidades centrais funcionando como projetadas no ambiente do cliente, versão major atual e as duas anteriores e assistência de upgrade do Priority Support, agendada para ao menos 1 semana após o envio do plano de upgrade, do plano de rollback e da arquitetura atualizada. Fora do escopo do suporte da GitLab: alterações locais no código-fonte, depuração de
.gitlab-ci.yml, aplicações, integrações e serviços de terceiros, infraestrutura, emissão de certificados SSL/TLS, funcionalidades experimentais e treinamento. - A Pointer em qualquer etapa: antes do chamado (triagem e coleta de logs e evidências), durante (abertura conjunta, acompanhamento e interlocução com a GitLab) e depois (aplicação e validação da solução no ambiente do cliente). Itens fora do escopo do suporte da GitLab, como pipelines, integrações e infraestrutura, também podem ser tratados com a Pointer, conforme o contrato de serviços. Contatos, papéis e canal de atendimento da Pointer publicados na página.
- Primeiros passos: confirmar quem da equipe é contato de suporte cadastrado na GitLab; garantir acesso ao Customers Portal para quem cuida da assinatura e das faturas; no GitLab self-managed, guardar o activation code em cofre de senhas da organização ou, sem internet, guardar o arquivo de licença em cofre e programar o envio mensal do arquivo de uso de licença; e os passos adicionais definidos com o cliente.
- Fontes oficiais: a página lista as URLs da documentação e do portal de suporte da GitLab usadas em cada item, com a data de consulta da base de fatos (29/09/2026).
4. Formas de entrega
Disponível Ofertado nas condições deste documento.
| Forma de entrega | Quando se aplica | Onde é publicada | Conteúdo | Estado |
|---|---|---|---|---|
| Página no site da avaliação | Cliente com avaliação de maturidade DevSecOps e Customer Success Plan (PS-AVA-01), com ou sem o levantamento da plataforma (PS-AVA-02) | Página Onboarding do site da avaliação, com acesso pelo portal do site | Conteúdo geral aberto e seção personalizada cifrada com a senha dos resultados da avaliação | Disponível |
| Site próprio de onboarding | Cliente sem avaliação: engajamento de implantação, migração ou operação assistida | GitLab Pages do projeto do engajamento (página inicial do site) | Somente o conteúdo geral, sem seção personalizada | Disponível |
- As duas formas de entrega usam o mesmo conteúdo geral e a mesma base de fatos oficiais da versão do componente usada no engajamento.
- Em engajamento com avaliação, o onboarding é sempre a página do site da avaliação; o site próprio não é publicado no mesmo projeto.
- O conteúdo geral é aberto a quem acessa a página e contém só dados publicáveis: nenhum activation code, arquivo de licença, senha ou token. Contatos e telefones da Pointer publicados são canais corporativos.
- Sem a senha dos resultados da avaliação configurada no projeto, a seção personalizada não é publicada.
5. Recursos configurados
● Nativo — recurso da plataforma GitLab◐ Requer configuração○ Integração externa — depende de serviço do cliente ou de terceiro
| Recurso | Classificação | Detalhe |
|---|---|---|
| GitLab Pages | Requer configuração | Recurso nativo. O pipeline publica a página de onboarding no GitLab Pages do projeto do engajamento a cada merge na branch padrão; a visibilidade segue a configuração do projeto, definida com o cliente. |
| Componente de CI/CD em versão fixa | Requer configuração | Recurso nativo (componentes do CI/CD Catalog). O projeto do engajamento inclui o componente Pointer (onboarding ou, com avaliação, o da avaliação) em versão fixa; os fatos oficiais publicados são os dessa versão, que só muda por merge request. |
| Validação em merge request | Requer configuração | Recurso nativo de CI/CD. Cada merge request e cada branch validam a configuração do onboarding; no site próprio, a publicação depende dessa validação. |
6. Ferramentas
Ferramenta Pointer
psctl
Valida a configuração do onboarding (plano, oferta, forma de ativação, URL da instância, contatos e canal da Pointer, nome do cliente) e gera a página: conteúdo geral e, no site da avaliação, a seção personalizada cifrada.
Arquivo Pointer versionado com o componente, com fonte oficial e data de consulta por item
Base de fatos oficiais do suporte GitLab
Customers Portal e Support Portal, abertura e acompanhamento de chamados, SLAs do Priority Support e escopo do suporte, a partir da documentação e do portal de suporte da GitLab; revisada a cada versão da plataforma Pointer.
Recurso nativo da plataforma GitLab
GitLab Pages
Publica a página de onboarding: no site da avaliação ou em site próprio.
7. Como o pipeline Pointer executa
Cada merge request e cada branch do repositório do engajamento validam a configuração do onboarding. No site próprio, o merge na branch padrão republica a página no GitLab Pages; no site da avaliação, a validação e a publicação da página fazem parte do pipeline da avaliação, que também gera a seção personalizada a partir dos resultados consolidados. A geração da página não acessa a instância GitLab do cliente e não usa runner na rede do cliente.
No site próprio, os dois jobs usam os estágios de validação e de entrega que os modelos de engajamento Pointer (implantação, migração e avaliação) já declaram; em projeto do engajamento sem esses estágios, a configuração do pipeline os declara, e sem essa declaração o pipeline não é criado.
8. Metodologia
Assessment → Implantação → Otimização → Transferência de conhecimento.
Fase 1
Assessment
- Kick-off: forma de entrega (página do site da avaliação ou site próprio), quem acessa a página e contatos e canal de atendimento da Pointer a publicar.
- Coleta das informações do documento de pré-requisitos PR-ONB-01: nome e sigla do cliente, plano, oferta e forma de ativação da assinatura, URL, versão e arquitetura da instância e primeiros passos adicionais.
- Identificação dos contatos de suporte cadastrados na GitLab (quem abre chamado; até 30 por organização).
Fase 2
Implantação
- Configuração do onboarding por merge request no repositório do engajamento, validada pelo pipeline; no site próprio, inclusão do componente de onboarding com os estágios de validação e de entrega declarados no pipeline do projeto.
- Publicação da página no GitLab Pages pelo merge na branch padrão; no site da avaliação, com a seção personalizada cifrada gerada a partir dos resultados consolidados da avaliação.
Fase 3
Otimização
- Ajustes de contatos, canal de atendimento e primeiros passos por merge request, com nova validação e publicação.
- Conferência da data de consulta dos fatos oficiais na versão do componente usada no engajamento; fatos revisados entram por merge request que atualiza a versão do componente.
Fase 4
Transferência de conhecimento
- Apresentação da página ao time do cliente: portais, abertura e acompanhamento de chamados, SLAs de primeira resposta, escopo do suporte da GitLab e canais da Pointer.
- Registro, no repositório do engajamento, da forma de entrega, do acesso à página e dos contatos de suporte cadastrados na GitLab.
- Entrega antes do início da operação assistida, quando contratada (PS-OPS-01).
9. Entregáveis
| Entregável | Descrição | Formato |
|---|---|---|
| Página de onboarding | A plataforma GitLab contratada; Customers Portal e Support Portal; abertura e acompanhamento de chamados; SLAs do Priority Support; escopo do suporte da GitLab; apoio e contatos da Pointer; primeiros passos; fontes oficiais com data de consulta. | Site (GitLab Pages) |
| Seção personalizada «O seu caso de uso» | Só no site da avaliação: objetivo e iniciativas do Customer Success Plan, casos de uso, prioridades e destaques da maturidade e retrato do levantamento, decifrados no navegador com a senha dos resultados. | Site (GitLab Pages, conteúdo cifrado) |
| Configuração do onboarding | Assinatura, instância, contatos e canal da Pointer e primeiros passos adicionais, versionados e validados pelo pipeline. | Repositório do engajamento |
| Registro de decisões do onboarding | Forma de entrega, quem acessa a página e contatos de suporte cadastrados na GitLab (quem abre chamado). | Repositório do engajamento |
10. Premissas
- Assinatura GitLab Premium ou GitLab Ultimate: o Priority Support da GitLab vem com esses planos, e a validação recusa outro plano.
- As etapas de activation code e de arquivo de licença aparecem só para o GitLab self-managed.
- Os fatos oficiais (portais, chamados, SLAs e escopo do suporte) são os da data de consulta registrada na página. Portais, SLAs e políticas de suporte da GitLab mudam sem aviso: a página publicada usa a base de fatos da versão fixa do componente, e fatos revisados entram por merge request.
- Os prazos do Priority Support são prazos de primeira resposta da GitLab, não de resolução, e não são prazos da Pointer.
- Só os contatos de suporte cadastrados da organização do cliente abrem chamado no Support Portal.
- O conteúdo geral é aberto a quem acessa a página; a configuração do onboarding recebe só dados publicáveis.
- A seção personalizada existe só no site da avaliação e usa a senha dos resultados da avaliação, entregue ao cliente por canal separado.
Fora do escopo
- Suporte técnico do fabricante: o suporte oficial da GitLab é o da assinatura GitLab do cliente.
- Aquisição, renovação e ativação de assinaturas GitLab.
- Tratamento de chamados, incidentes e itens fora do escopo do suporte da GitLab pela Pointer: conforme o contrato de serviços (por exemplo, operação assistida PS-OPS-01).
- Seção personalizada no site próprio de onboarding (sem avaliação, a página tem só o conteúdo geral).
- Capacitação das equipes na plataforma GitLab (oferta PS-CAP-01).
Responsabilidades do cliente
- Informar os dados da assinatura (plano, oferta e forma de ativação) e da instância (URL, versão e arquitetura) a publicar.
- Definir quem acessa a página (visibilidade do GitLab Pages do projeto do engajamento).
- Indicar os contatos de suporte cadastrados na GitLab e manter o cadastro no Support Portal (até 30 por organização).
- Garantir acesso ao Customers Portal para quem cuida da assinatura e das faturas.
- No GitLab self-managed, guardar o activation code ou o arquivo de licença em cofre da organização e, sem internet, enviar mensalmente o arquivo de uso de licença.
- No site da avaliação, guardar a senha dos resultados.
Detalhamento no documento de pré-requisitos PR-ONB-01, enviado após a escolha do serviço.
11. Duração
A duração depende da forma de entrega, da devolução das informações do documento de pré-requisitos e da agenda de apresentação da página ao time do cliente. O prazo do engajamento é definido na proposta.
12. Documentos relacionados
- PS-00 · Catálogo de Serviços
- PR-ONB-01 · Pré-requisitos: Onboarding do cliente na plataforma GitLab
- PS-AVA-01 · Avaliação de maturidade DevSecOps e Customer Success Plan
- PS-AVA-02 · Levantamento da plataforma
- PS-OPS-01 · Operação assistida
- PS-IMP-01 · Implantação da plataforma GitLab em servidores Linux
- PS-IMP-02 · Implantação da plataforma GitLab em Kubernetes
- PS-MIG-01 · Migração GitLab para GitLab self-managed
- PS-CAP-01 · Capacitação na plataforma GitLab