Configurações do Projeto Orbit

Todos os controles de um projeto Orbit ficam na aba Settings, agrupados para facilitar a localização: informações gerais, build e deploy, segurança, notificações, integrações, limites de uso, automação de deploy, rede, observabilidade, compartilhamento e uma zona de perigo na parte inferior.

Onde as Configurações Ficam

Abra Orbit, clique no projeto e escolha Settings na faixa de abas do projeto. A página descreve a si mesma como configuração do nome do projeto, comandos de build e integração Git, o que não faz jus às suas capacidades.

Este guia é um mapa. Quando um assunto tem seu próprio artigo, ele é vinculado em vez de repetido.

Geral

Project info mostra o slug da URL, a data de criação, o repositório conectado e a URL de produção, e permite alterar o Name e a Description do projeto.

Git contém a Production branch. Pushes para essa branch disparam deploys de produção.

Status badge oferece um SVG de status de deploy em tempo real com botões de cópia para a URL, markdown e HTML, pronto para colar no seu README. Veja Visualizando seu README do Projeto no Orbit.

Public status page vincula à configuração da página de status. Veja Orbit Status Page.

Build e Deploy

Build settings são os cinco campos que Orbit detecta automaticamente e você pode sobrescrever: comando de instalação, comando de build, diretório de saída, diretório raiz e versão do Node.js. Deixe um campo em branco para manter o valor detectado. Detalhes completos estão em Configurando seu Comando de Build e Diretório de Saída.

Runtime traz quatro opções que merecem compreensão:

• Server mode mantém a máquina de build ativa executando seu comando start após cada deploy. Necessário para qualquer coisa que renderize no servidor em vez de exportar arquivos estáticos.
• Branch previews cria um ambiente automaticamente para cada push de branch que não seja produção ou staging, cada um em sua própria URL sob branch-*.kaps.run. Veja Branch Previews.
• Auto-rollback on failure restaura o último deployment de produção saudável se um deploy falhar.
• Scheduled rebuild reconstrói a produção em um intervalo, de hora em hora a semanalmente, o que se adequa a sites gerenciados por conteúdo que precisam de uma atualização sem um git push.

Build auto-retry recoloca na fila builds que falharam em erros de infraestrutura, como um problema de rede ou timeout, até três vezes. Não tenta novamente erros de código, portanto não pode mascarar um build quebrado.

Ignored paths e Branch ignore patterns interrompem builds desnecessários: padrões glob para arquivos cujas alterações não devem fazer deploy, e para branches como dependabot/* que nunca devem disparar um.

Git tag deploys define o padrão de tag que transforma um push de tag em um deploy de produção. Veja Orbit Releases.

Automação e Proteção de Deploy

Deploy protection tem dois portões: Require approval for production, que pausa deploys de produção disparados por push até que alguém aprove, e Require staging success before production, que mantém a produção até que staging tenha feito deploy do mesmo commit com sucesso.

CI required checks bloqueia deploys em seus próprios CI. No GitHub você lista nomes de jobs, todos os quais devem passar; no GitLab qualquer valor não vazio aguarda todo o pipeline. Uma falha de CI cancela o deploy.

Deploy freeze schedule bloqueia deploys disparados por push fora de janelas aprovadas, seja fins de semana ou um intervalo de hora UTC. Deploys manuais e deploy hooks não são afetados.

Branch protection adiciona regras de padrão glob que bloqueiam deploys em branches correspondentes até que verificações externas necessárias passem e, opcionalmente, um humano aprove.

Auto-promote staging promove staging para produção automaticamente uma vez que tenha funcionado por um número configurado de horas sem falhas de saúde e com testes de fumaça passando.

Todos esses estão resumidos em uma visualização na aba Orbit Deployment Pipeline.

Verificações de Saúde e Qualidade

Health check obtém um caminho que você escolhe após cada deploy de produção. Uma resposta não-2xx em 15 segundos restaura o deployment saudável anterior.

Smoke tests executam requisições GET contra até dez caminhos separados por vírgula após cada deploy bem-sucedido e registram sucesso ou falha. Combinado com auto-rollback, um smoke test falhando reverte o deploy.

Performance budgets alertam ou falham builds que excedem um limite: tamanho total de artefato em MB, tamanho de arquivo individual em kB correspondido por um glob, ou tempo de build em segundos. Cada orçamento é definido como aviso ou falha de build.

Staging

Staging tem seu próprio conjunto de cartões: a staging branch, access protection com uma senha, um IP allowlist aceitando endereços IPv4 e intervalos CIDR um por linha, auto-rollback on failure, se staging herda variáveis de ambiente de produção com menor prioridade, e build overrides para instalação, build, saída e diretório raiz.

Senha e IP allowlist são os dois para definir em qualquer ambiente de staging que não seja destinado a ser público. Deixe ambos em branco e a URL de staging é acessível por qualquer pessoa que a tenha.

Rede

Custom domains adiciona e verifica domínios para o ambiente de produção, incluindo provisionamento de certificados. Veja Adicionando um Domínio Personalizado ao Orbit.

Redirects and rewrites são regras baseadas em caminho aplicadas antes de servir, testadas em ordem com o primeiro match vencendo. Um redirecionamento envia o navegador para uma nova URL como 301 ou 302; uma reescrita serve um caminho diferente silenciosamente sem mudança de URL. Padrões suportam correspondências exatas, wildcards, parâmetros nomeados e splats. Veja Redirects e Rewrites em Orbit.

Response headers aplicam cabeçalhos HTTP personalizados a caminhos correspondentes, com predefinições para HSTS, CSP, no-embed, no-sniff, política de referrer e CORS. Todas as regras correspondentes são aplicadas, e entradas posteriores sobrescrevem as anteriores para a mesma chave.

Skew protection mantém artefatos de build antigos no armazenamento por uma janela de retenção após um novo deployment ficar ativo, para que um visitante que tenha carregado a versão anterior ainda possa buscar seus ativos em vez de obter um 404.

The config store contém configurações de chave/valor que seu deployment lê no tempo de execução, para flags de recurso e configurações que mudam sem um redeploy. É gerenciado em Storage, não aqui, e é grátis: não há cobrança de leitura nem de escrita. Os valores são armazenados em texto simples, portanto nunca coloque um segredo em um. Até 100 entradas por projeto, chaves de até 200 caracteres e valores de até 4096. Um snapshot noturno de cada entrada é feito e trinta noites são mantidas em todos os planos, portanto uma entrada que você deletou pode ser restaurada: veja Snapshots e restore.

Uso e Limites

Build usage mostra os builds que este projeto executou.

Spending cap define o gasto máximo mensal de excedente, cobrindo excedentes de minutos de build e largura de banda além da alocação do seu plano. O mínimo é US$6.32 e o máximo US$6,315.79. Alertas são disparados em 50% e 80%, e em 100% o serviço pausa até que você aumente o limite. Veja Orbit Spending Cap.

Build spending cap é o limite separado e mais simples: um teto mensal no total de minutos de build, após o qual novos builds param de ficar na fila até o próximo mês ou você aumentar o limite.

Artifact retention define quantos artefatos de build bem-sucedidos manter por ambiente. Os mais antigos são deletados diariamente, e o deployment atualmente ativo é sempre mantido independentemente do limite.

Preview expiry pausa ambientes de preview após 7, 14, 30 ou 60 dias, ou nunca. Previews pausados têm seu armazenamento recuperado dentro de 24 horas.

Artifact size alert envia um email para você quando um artefato de build excede um tamanho que você define.

Notificações, Integrações e Observabilidade

Deploy email notifications tem três configurações: todos os deploys, apenas falhas, ou desligado. Uma notification webhook URL pode ser definida junto com ela, postando em cada sucesso ou falha.

Notification channels é a versão mais rica, com seleção por evento, histórico de entrega e um botão de teste. O controle completo de webhook está em sua própria aba: veja Orbit Webhooks.

Deploy hooks cria URLs secretas que disparam um deploy quando algo faz POST para elas. Veja Disparando Deployments Via Deploy Hooks.

Log drains envia logs de build para sua plataforma de observabilidade após cada deployment, com suporte integrado para Datadog, Logtail, Axiom e New Relic, ou um webhook personalizado, opcionalmente filtrado para um ambiente.

Web Analytics oferece o snippet de coleta Core Web Vitals. Veja Orbit Web Vitals.

Cron triggers agenda requisições HTTP para um ambiente escolhido, até dez por projeto. A versão maior, apenas de produção, está em sua própria aba: veja Orbit Cron Jobs.

Compartilhamento e Equipe

Team gerencia colaboradores com três funções: admin, developer e viewer.

Share links gera links temporários sem senha para que um revisor externo possa visualizar um ambiente sem uma senha ou conta. Cada link pode expirar em 1 hora, 24 horas ou 7 dias, ou nunca, e mostra sua contagem de visitas. Revogue um a qualquer momento.

Deployment group junta este projeto a um grupo para que projetos relacionados façam deploy juntos, opcionalmente filtrados por branch.

Clone environment e Clone project duplicam configuração. Clonar um projeto copia configurações de build, configuração de ambiente e variáveis de ambiente não secretas; segredos não são copiados.

Zona de Perigo

Clear build cache deleta as dependências em cache para cada ambiente, para que o próximo deployment execute uma instalação completa do zero. Não pode ser desfeito, embora o cache se reconstrua sozinho no próximo build.

Transfer project move o projeto para outra conta Kapsule. Veja Transferindo um Projeto Orbit.

Archive project para de servir tráfego imediatamente. É restaurável dentro de 30 dias a partir da lista Orbit, após o qual é permanentemente deletado.

Próximos Passos

• Orbit Deployment Pipeline para ver o efeito de cada configuração em uma visualização.
• Shared Environment Variable Groups para valores usados em todos os projetos.
• Orbit Plan Limits para o que seu plano permite.