Implantação com o Zinnector®: vincular, verificar, enviar

Assim que um projeto roda localmente, quatro comandos o levam para um site ativo na hospedagem da Zinn Digital®: entrar, vincular o projeto a um espaço de hospedagem, ler a verificação pré-voo e enviar. Este artigo examina cada um deles, o que exibem e os comandos que você utiliza posteriormente — novas implantações, histórico de implantação e logs de build.

Entrar com uma chave de API

Crie uma chave no painel em Configurações → Chaves de API, e então:

zinnector login

A chave é digitada em um prompt — ela nunca é aceita na linha de comando, portanto não pode parar no histórico do seu shell ou em uma listagem de processos. Em CI, envie-a por pipe: echo "$ZINN_API_KEY" | zinnector login --profile ci, ou defina ZINNECTOR_TOKEN e ignore o login por completo. A chave é verificada antes de ser armazenada e armazenada com permissões de arquivo 600. zinnector whoami --scopes mostra a qual organização você está conectado e quais permissões a chave possui; uma chave de sandbox é rotulada como tal.

Vincular o projeto a um espaço

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

O link grava o id do site em zinnector.json e, a menos que você passe --no-repo, conecta o remoto git do projeto ao site na plataforma para que um envio realize a implantação. Faça o commit de zinnector.json: um colega que clona o repositório implantará no mesmo lugar sem precisar ser avisado. O arquivo não contém segredos.

Ler a verificação pré-voo

zinnector check

Este é o comando para o qual a CLI existe. Ele compara seu projeto com o espaço para o qual está prestes a ser implantado e exibe cada divergência — e cada comparação que não pôde ser feita:

• Versão do PHP, com uma lacuna de versão principal classificada como alta porque ela invariavelmente quebra um site e uma lacuna menor classificada como inferior, pois classificar tudo como crítico ensina as pessoas a ignorarem o aviso.
• Se o espaço pode alternar para a versão na qual você compilou, se o PHP do espaço já passou do fim da vida útil e se a máquina aplicou a versão ou apenas recebeu a instrução.
• O tamanho do projeto e a contagem de arquivos em relação ao espaço livre em disco e de inodes efetivamente restante no espaço — uma árvore do WordPress pode ficar sem arquivos mesmo estando bem abaixo do limite de disco.
• As versões do WordPress em cada lado, se o espaço terminou o provisionamento e se um repositório está conectado para envio.

Ele avisa; nunca bloqueia. Cada descoberta pode ser ignorada com zinnector push --force, porque você sabe coisas sobre o seu próprio site que um verificador não sabe. Uma comparação que não pôde ser feita é relatada como desconhecida, nunca como aprovada, e o resumo sempre indica quantas houve. Por padrão, a versão local do PHP é aquela declarada em zinnector.json; --probe inicia o tempo de execução local e o mede em vez disso. --strict encerra com código diferente de zero também em casos desconhecidos, que é o que um gatilho de CI exige.

Enviar

zinnector push

O push executa a verificação pré-voo, envia seus commits, aciona a implantação e a monitora 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; --no-git implanta o que a plataforma já possui sem enviar. Se o commit implantado não for aquele que acabou de ser enviado, isso é informado.

Quando algo dá errado

zinnector deploys example.com        # histórico de implantação — status, commit, gatilho, mensagem
zinnector logs example.com --build   # o log de build da implantação mais recente
zinnector logs example.com --error   # o log de erros do site
zinnector deploy example.com         # reimplantar o que a plataforma já possui
zinnector ai "why is my deploy failing?"

O zinnector ai é executado na plataforma em sua própria conta, para que possa acessar o mesmo histórico de implantação e logs. 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.

Relacionados

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