Implantando com o Zinnector®: vincule, verifique, envie

Depois que um projeto estiver sendo executado localmente, quatro comandos o levarão a um site no ar na hospedagem da Zinn Digital®: fazer login, vincular o projeto a um slot de hospedagem, ler o pré-voo (pre-flight) e enviar com push. Este artigo detalha cada um deles, o que exibem e os comandos que você utilizará posteriormente — novas implantações, histórico de implantação e logs de compilação.

Fazer login com uma chave de API

Crie uma chave no painel em Configurações → Chaves de API, e depois execute:

zinnector login

A chave é digitada em uma solicitação — ela nunca é aceita na linha de comando, para que não acabe no histórico do seu shell ou em uma listagem de processos. No CI, transmita-a via pipe: echo "$ZINN_API_KEY" | zinnector login --profile ci, ou configure ZINNECTOR_TOKEN e ignore o login completamente. A chave é verificada antes de ser armazenada e gravada com a permissão de arquivo 600. zinnector whoami --scopes mostra em qual organização você está conectado e quais permissões a chave possui; uma chave de sandbox é identificada como tal.

Vincular o projeto a um slot

zinnector link                                   # escolha um site de uma lista
zinnector link example.com --repo acme/site --branch main

O comando link grava o ID do site em zinnector.json e, a menos que você passe --no-repo, conecta o repositório remoto git do projeto ao site na plataforma, de modo que um push faça a implantação. Confirme o zinnector.json: um colega que clonar o repositório poderá implantar no mesmo local sem precisar de instruções. Ele não contém nenhum segredo.

Ler o pré-voo

zinnector check

Este é o comando para o qual a CLI existe. Ele compara o seu projeto com o slot no qual ele está prestes a ser implantado e exibe todas as divergências — e todas as comparações que não pôde realizar:

• Versão do PHP, com uma diferença de versão principal classificada como alta, pois sabidamente quebra um site, e uma diferença menor classificada em nível mais baixo, já que classificar tudo como crítico ensina as pessoas a ignorarem o aviso.
• Se o slot pode alternar para a versão na qual você desenvolveu, se o PHP do slot já passou do fim da vida útil e se a máquina aplicou a versão ou apenas recebeu a instrução.
• O tamanho e a contagem de arquivos do seu projeto em relação ao espaço livre real de disco e inodes restante no slot — uma estrutura do WordPress pode ficar sem arquivos mesmo estando bem abaixo do limite de disco.
• As versões do WordPress em cada lado, se o slot concluiu o provisionamento e se há um repositório conectado para o qual enviar o push.

Ele avisa; nunca bloqueia. Qualquer apontamento pode ser ignorado com zinnector push --force, porque você conhece coisas sobre o seu próprio site que um verificador desconhece. Uma comparação que não pôde ser feita é informada como desconhecida, nunca como aprovada, e o resumo sempre informa quantas ocorreram. Por padrão, a versão local do PHP é a declarada em zinnector.json; --probe inicializa o ambiente de execução local e a afere diretamente. --strict encerra com código diferente de zero também em itens desconhecidos, que é o esperado por um controle de CI.

Enviar (push)

zinnector push

O comando push executa o pré-voo, envia seus commits, aciona a implantação e a acompanha até a conclusão, exibindo o status final e o commit implantado. --dry-run faz tudo, exceto a implantação; --no-wait a aciona e encerra a execução; --no-git implanta o que a plataforma já possui, sem enviar push. Se o commit implantado não for o que acabou de ser enviado, ele avisará.

Quando algo der errado

zinnector deploys example.com        # histórico de implantação — status, commit, acionador, mensagem
zinnector logs example.com --build   # o log de compilação da implantação mais recente
zinnector logs example.com --error   # o log de erros do site
zinnector deploy example.com         # implanta novamente o que a plataforma já possui
zinnector ai "por que minha implantação está falhando?"

O comando zinnector ai é executado na plataforma vinculado à sua própria conta, portanto pode visualizar o mesmo histórico de implantação e os mesmos logs. A partir de dentro de um projeto, ele envia a estrutura do projeto — nomes de diretórios, versões e o ID do site — e nunca o conteúdo dos arquivos.

Relacionado

• Primeiros passos · Desenvolvimento local · Referência de comandos · Solução de problemas