Controle de código-fonte
Conecte a conta do GitHub ou GitLab em que você trabalha e faça a implantação diretamente de uma branch: para o Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps ou AWS Amplify — ou em nossa própria hospedagem gerenciada, onde o repositório e os arquivos do site permanecem sincronizados em ambas as direções. Cada conexão exibe os privilégios de que necessita, é verificada com a API do provedor antes de ser armazenada e fica protegida no Vault. Você também pode iniciar sessão com o GitHub ou o GitLab.
Uma conexão é uma credencial que você entrega a outra pessoa. A nossa informa do que precisa antes de você criá-la, comprova que funciona antes de armazená-la e pode ser revogada por qualquer uma das partes.
Antes de você criar um token, nós lhe dizemos o que ele precisa ser capaz de fazer e o porquê. Sem escopo generalizado só porque era mais fácil de solicitar, e sem descobrir depois do fato que queríamos mais do que o trabalho exigia.
Chamamos a própria API do provedor com seu token antes de armazená-lo. Um token incorreto, expirado ou com escopo inadequado é recusado no formulário, em vez de ser aceito, exibido como funcional e falhar na primeira implantação real.
Não em nosso código, não em um arquivo de ambiente, não em um log e não em uma linha de comando. Resolvido no momento em que é utilizado, pela carga de trabalho que o utiliza.
Conecte uma conta pessoal e a de uma organização, ou de duas organizações. Cada site escolhe a partir de qual implantar, de modo que o repositório de um cliente e o seu nunca compartilham credenciais.
Oito hosts de borda gerenciados e nossa própria frota. O destino é uma propriedade do site, não da conexão, portanto o mesmo repositório pode publicar uma ramificação em um host Pages e outro site pode ser executado em nosso próprio hardware.
Largura de banda ilimitada, uso comercial permitido e domínios apex gerenciados no mesmo provedor que normalmente hospeda sua zona DNS. É o primeiro destino ao qual recorremos por esses motivos.
Hospedagem do Cloudflare Pages →Publique diretamente do repositório onde o código já reside. Sinalizado na linha Footprint-Free, pois a infraestrutura compartilhada do github.io é, por si só, uma pegada.
Hospedagem GitHub Pages →GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps e AWS Amplify são destinos para os quais você pode apontar um site, com a mesma conexão e o mesmo histórico de implantação.
Hospedagem de sites estáticos →Uma aplicação completa em vez de um pacote compilado — WordPress, PHP, Node. Este é o destino que recebe a sincronização bidirecional, para que os arquivos no servidor e na ramificação permaneçam sincronizados.
Hospedagem gerenciada →Um site publicado em um host que não nos pertence ainda consome uma cota e continua aparecendo no seu painel com suas implantações, seu tempo de atividade e seus dados de SEO ao lado de tudo o mais que você executa.
Limites de sites externos →O editor no navegador funciona nos mesmos arquivos que a sincronização bidirecional envia de volta, para que uma correção rápida no painel se torne um commit na sua ramificação, em vez de uma alteração que ninguém consiga encontrar mais tarde.
O editor web →Sincronização bidirecional
Ative-o e os próprios arquivos do site serão commitados de volta para a sua branch, enquanto os commits nessa branch retornarão para o site. Ele funciona em todos os sites que hospedamos, em todas as linhas — o único requisito é que a máquina subjacente consiga executar o Git em seus arquivos, o que é verificado diretamente com o servidor, em vez de presumido com base no plano.
Você escolhe qual diretório sincronizar, porque um cliente do WordPress deseja que seu tema seja rastreado, e não quarenta mil arquivos principais. E fica desativado até que você o ative: habilitar uma sincronização é uma decisão sobre o repositório de outra pessoa, e uma migração nunca deve tomar essa decisão por você.
Dois modos, e a diferença é onde a compilação é executada. Ambos terminam no mesmo lugar: uma ref que buscamos e publicamos, com o commit registrado na implantação.
GitHub ou GitLab, em Conexões. Os privilégios são listados antes de você criar o token e ele é verificado com o provedor antes de ser armazenado.
Proprietário, repositório, branch e se publicamos um diretório ou buscamos o que o seu CI compilou. Registramos o webhook de push como parte disso.
Um push para a ramificação indicada inicia uma implantação, ou você pode implantar sob demanda a partir da guia Implantar do site. As compilações são executadas em segundo plano.
O histórico de implantação mostra o que foi publicado e quando. Ative a sincronização bidirecional e as edições feitas aqui retornarão como commits no seu branch.
Quando algo dá errado
Uma conexão de repositório que parece íntegra e não recebe nada é a clássica falha silenciosa — um token com o escopo incorreto, uma entrega bloqueada no provedor, um hook que alguém removeu manualmente. Isso fica invisível em qualquer outra tela, por isso o cartão do repositório exibe essas informações diretamente: quando o provedor fez o último envio para nós e o que ele informou.
As entregas têm suas assinaturas verificadas antes de agirmos sobre elas, utilizando o esquema próprio de cada provedor, em vez de um que presumíssemos aplicar-se a todos eles. Uma entrega que não é verificada é recusada e registrada, não silenciosamente ignorada.
Identidade
Além de um endereço de e-mail e uma senha, você pode fazer login na sua conta Zinn Digital® com GitHub, GitLab, Google ou Microsoft. A camada de identidade realiza o handshake; nós nunca vemos a senha do seu provedor, e a vinculação de uma conta social a uma conta Zinn® existente ainda precisa ser confirmada por e-mail.
Fazer login com o GitHub e conectar o GitHub para deploys são decisões separadas e credenciais separadas. Fazer um não faz o outro, e remover um não remove o outro.
GitHub e GitLab. Conecte a conta na qual você já trabalha e poderemos fazer a implantação a partir de seus repositórios, registrar um webhook de push neles e — se desejar — sincronizar os arquivos do seu site de volta no sentido inverso. Ambos passam pela mesma integração de conta conectada, portanto, tudo abaixo se aplica a qualquer um deles.
Sim, e com o Google ou a Microsoft. Além de um endereço de e-mail e uma senha, você pode fazer login na sua conta Zinn Digital® com qualquer uma das quatro opções. A camada de identidade gerencia a comunicação e nós nunca vemos a senha do seu provedor. Fazer login com o GitHub é algo separado de conectar o GitHub para deploys — você pode fazer um, ambos ou nenhum.
Para o Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps ou AWS Amplify para um site estático ou compilado — ou para nossa própria hospedagem gerenciada, onde o repositório e os arquivos do site permanecem sincronizados em ambas as direções. Você escolhe o destino do site; a conexão com o repositório é a mesma em qualquer um dos casos.
Qualquer um. No modo de publicação, pegamos a ramificação como ela está e publicamos o diretório indicado por você. No modo CI, o próprio pipeline do seu provedor executa seu comando de compilação e confirma a saída em uma ramificação de publicação separada, que nós então buscamos como qualquer outra referência. O segundo mantém sua compilação em seu próprio CI, onde seus segredos e seu armazenamento em cache já estão.
Por padrão, sim — registramos um webhook no repositório e um push para a ramificação indicada por você inicia uma implantação. Você pode desativar isso e manter o webhook, o que é mais útil do que parece: a entrega ainda é gravada, permitindo que você acompanhe a chegada dos seus pushes antes de nos autorizar a agir sobre eles.
As edições feitas em nosso hardware tornam-se commits no seu branch, e os commits no seu branch retornam ao site. Ele fica desativado até que você o ative, pois ativá-lo é uma decisão sobre o repositório de outra pessoa e nós não tomaremos isso por você. Você escolhe qual diretório sincronizar — geralmente um tema ou um plugin, não quarenta mil arquivos principais do WordPress.
Nada é sobrescrito e nada é enviado. A sincronização é interrompida, informa que o branch avançou além do commit no qual nos baseamos e pergunta qual lado você deseja manter — o repositório ou o site. Um site que nunca foi sincronizado e aponta para um branch que já possui commits também é um estado próprio, e o sistema pergunta em vez de adivinhar qual é o correto.
Mostramos a você os privilégios de que a conexão precisa antes de criá-la, verificamos o token na própria API do provedor no momento da inserção — para que um token inválido ou com escopo incorreto nunca seja armazenado — e só então o gravamos no Vault. Ele nunca toca em nosso código, em um registro, em um arquivo de ambiente ou em uma linha de comando. Revogue-o no provedor ou remova a conexão aqui, sempre que desejar.
O cartão do repositório mostra quando o provedor fez a última entrega para nós e o que ele informou. "Nunca entregue" é o diagnóstico individual mais útil nessa tela, porque "conectado, mas nunca entregue" é exatamente o que um token com escopo incorreto ou uma entrega bloqueada aparenta ser — e isso não fica visível em nenhum outro lugar. Cada entrega tem sua assinatura verificada antes que possamos agir sobre ela.
Ele é oferecido e sinalizado. O GitHub Pages e o GitLab Pages compartilham a infraestrutura do provedor e os nomes de host públicos github.io e gitlab.io, e isso é uma pegada (footprint) — a única coisa que essa linha existe para evitar. Para uma rede com zero pegada (zero-footprint), faça a implantação em uma hospedagem isolada. Em qualquer outro lugar, o Pages é de primeira classe.
Porque seu nível gratuito é licenciado apenas para uso não comercial. Deduzimos um destino a partir das contas conectadas por você quando isso é seguro, e o Vercel foi deliberadamente excluído dessa dedução — conectar uma conta nunca deve posicionar silenciosamente um site comercial onde sua licença não permite. Escolha-o e ele funcionará exatamente como os outros.
Sim. Cada deploy registra o commit publicado, quando ele foi executado e como foi finalizado, e a aba Deploy do site mostra o histórico com a URL ativa ao lado. Os deploys são executados em segundo plano, portanto a página é atualizada assim que o build é concluído, em vez de fazer você esperar com um indicador de carregamento na tela.
Inicie um teste de 14 dias sem cartão, conecte o GitHub ou o GitLab e aponte um site para uma ramificação. Publique em um host de borda ou em nossa própria hospedagem com arquivos sincronizando nos dois sentidos.
Comece grátis