Implantando para Live e Staging com Deploybot

Se você já trabalha com desenvolvimento web há algum tempo, provavelmente estragou uma transferência de arquivos ao tentar atualizar um site. Na melhor das hipóteses, você adiciona vários arquivos facilmente identificáveis ​​a um diretório e os remove para corrigir o erro. Sim, custa-lhe tempo e é chato, mas não faz mal.

Na pior das hipóteses, você transfere um monte de arquivos de tema incorretamente. Então você tem que descobrir quais foram sobrescritos, quais não pertencem, e como você vai recuperar o estado de funcionamento adequado do seu tema.

Hoje vamos resolver esse problema usando Git e Deploybot para automatizar seu processo de implantação.

O que é implantação automatizada?

Uma implantação automatizada básica tem quatro partes, conforme mostrado neste diagrama.

A maioria dos desenvolvedores começa apenas com seu código e o servidor. Eles fazem alterações em sua cópia de trabalho do site e, em seguida, enviam essas alterações diretamente para o servidor via FTP. Ferramentas como Coda ou Dreamweaver têm integração direta com FTP para que você possa fazer isso de dentro do seu ambiente de codificação.

A próxima etapa que muitos desenvolvedores dão é adicionar um site de teste para que eles não modifiquem o servidor ativo diretamente. Você pode fazer isso com algo como VVV ou MAMP. Muitas vezes, isso também significa que você está usando um sistema de controle de versão como o Git para gerenciar as alterações feitas em seu site de trabalho local.

Ao adicionar um site de teste, você também adiciona complexidade. Como você obtém suas alterações de código do seu site de trabalho local para um site de teste onde seu cliente pode ver as alterações? Sim, como eu já disse, você pode usar um cliente FTP básico como FileZilla, Transmit ou Forklift para mover os arquivos à medida que você faz alterações, mas isso é propenso a erros e é aí que automatizar seu processo de implantação economizará muito tempo.

Em vez de pegar os arquivos alterados e enviá-los para seu servidor de teste, você usa outro sistema para detectar automaticamente as alterações em seu repositório Git e enviar apenas essas alterações para o site de teste que seu cliente pode usar para verificar o trabalho.

Isso ainda deixa seu site ativo como uma implantação manual, o que é muito mais assustador porque pode significar a perda de dinheiro real se você derrubar um site ativo. Em vez disso, vamos supor que você vai configurar seu sistema de implantação para implantar automaticamente no teste e, em seguida, seu sistema será implantado com um único clique no ambiente ativo quando estiver pronto para começar.

Então agora você tem um sistema que se parece com isso.

Vamos nos aprofundar para que eu possa mostrar como configuro esse processo de implantação para cada cliente com o qual trabalho. Estes são os passos que dou assim que começo um novo projeto. Sempre me certifico de que meu processo de implantação esteja configurado e funcionando antes de começar a fazer qualquer outro trabalho em um projeto de cliente.

Como estruturar seu repositório Git

Sua primeira escolha a fazer é em qual diretório você configurará sua implantação automatizada? A menos que meu cliente solicite especificamente esse controle total do código-fonte para a instalação do WordPress, eu uso o diretório wp-content para configurar meu sistema de implantação automatizado. Isso começa no terminal emitindo este comando que inicializa um repositório git.

git init

Agora é hora de ignorar os arquivos que você não deseja implantar o tempo todo. Esses são arquivos como arquivos de backup, imagens e qualquer um dos arquivos de projeto personalizados que muitos editores de código adicionam a um diretório. Você pode ver meu arquivo .gitignore usual abaixo.

config/app_config.yml

config/database.yml

config/*.sphinx.conf

config/s3_credentials.yml

*~

*.cache

*.registro

*.pid

tmp/**/*

.DS_Store

banco de dados/cstore/**

banco de dados/esfinge/**

doc/api

documento/aplicativo

doc/plugins

doc/*.dot

cobertura/*

db/*.sqlite3

*.tmproj

*.sw?

*.esproj

_notas*

dwsync.xml

podcast.xml

*.kpf

*carregando/*

*.swp

*.idéia

*.sublime-project

*.sublime-workspace

*/node_modules/*

Tag

*.bak

cache/*

gerenciarwp/*

mu-plugins/*

dp.php

corrente ascendente de ar/*

línguas/*

db.php

plugins/wp-rocket/cache.json

Sinta-se à vontade para adicionar ou remover isso conforme necessário. Quase todo projeto em que trabalho precisa de algum tipo de entrada personalizada para ignorar algum arquivo específico do meu site de trabalho local para o qual os sites de teste e ao vivo terão seu próprio arquivo personalizado que não quero substituir.

A partir daqui, é hora de configurar as ramificações necessárias para que seu sistema de implantação funcione. Eu uso dois ramos principais. O primeiro é o branch master que corresponde ao meu site de produção ao vivo. Em segundo lugar, é uma ramificação que chamo de teste e corresponde ao site de teste que quero que meu cliente use como forma de verificar as alterações que estamos fazendo.

Quando você inicializou seu repositório Git, você já obteve seu branch master, então use este comando para adicionar um branch de teste e confira.

git checkout -b staging

Este comando cria e verifica uma nova ramificação. Se você é novo no git, pode encontrar mais informações sobre os comandos disponíveis na documentação do Git.

Agora você precisará enviar seu projeto para o sistema de controle de origem. Github e Bitbucket são duas opções populares que funcionam com o sistema de implantação automatizada que usaremos chamado Deploybot. Quando você cria um novo repositório com qualquer um dos sites, eles fornecem mais instruções para adicionar seu repositório local à sua versão online no Github ou Bitbucket.

• Documentação de configuração do repositório Bitbucket
• Documentação de configuração do repositório Github

Configurando o Deploybot

Quando eu estava entrando em um trabalho mais complexo como desenvolvedor, meu amigo Duane continuou recomendando o Deploybot para mim quando reclamei on-line sobre bagunçar a implantação manual de FTP. Foram necessárias várias recomendações antes de finalmente fazer o que me disseram, mas agora sou um cliente feliz do Deploybot há anos.

Embora existam outras maneiras de implantar seus sites, muitas delas envolvem a interface com o Git Webhooks ou alguns arquivos de configuração de implantação automatizada por meio do editor de código. Há muito poder nessas outras ferramentas, mas se você está apenas começando com a implantação automatizada, seguir com algo direto como Deploybot é o lugar para começar.

Para começar, inscreva-se em uma conta Deploybot e conecte o Github ou Bitbucket à sua conta. Vou usar minha conta Bitbucket existente hoje. Comece adicionando um novo repositório à sua conta do Deploybot.

Depois de encontrar o repositório que você deseja configurar para implantação automatizada, clique no botão conectar na parte inferior da página. Isso o enviará de volta à página do seu repositório enquanto o Deploybot termina de inicializar seu repositório. Geralmente, isso é feito em um ou dois minutos, então encha seu café e volte para terminar de configurar seu processo de implantação.

Depois que seu repositório estiver configurado, clique nele para ser levado à página principal. Como ainda não temos informações de sFTP configuradas, ele terá uma caixa grande dizendo para você configurar um servidor. Clique no botão para criar um ambiente e servidor.

Vamos começar com a implantação em nosso ambiente de teste. Portanto, rotule seu servidor como staging. Escolha a implantação automática e certifique-se de definir a ramificação para teste.

Quando terminar, clique no botão Salvar na parte inferior da página para ir para a configuração do servidor.

Na próxima página, rotule-o como um servidor de teste novamente e insira as informações de sFTP do seu site. Se você não tiver certeza de onde encontrá-los, leia este guia útil.

Com suas informações de sFTP inseridas, você pode rolar para baixo e salvá-las. O Deploybot testará sua conexão para garantir que as informações fornecidas funcionem. Agora é hora de fazer nossa implantação inicial para o site para garantir que tudo funcione. Costumo adicionar um arquivo test.txt à implantação como uma maneira fácil de verificar se a implantação funcionou corretamente.

Para iniciar sua implantação no histórico do ambiente e clique em implantar.

Agora você verá uma página com sua última mensagem de confirmação do git como a nota que você verá dentro do Deploybot ao lado deste deploy. Para grandes mudanças, vou mudar isso, mas se estou apenas alterando CSS ou algo menor, a mensagem de confirmação pode permanecer. Como isso é staging, cada commit para nosso branch staging será implantado automaticamente, o que significa que suas mensagens de commit são o que vai aparecer. É apenas o commit inicial que precisamos fazer manualmente em nosso site de teste.

Agora, verifique se seus arquivos foram publicados no site de teste e podemos configurar a implantação ao vivo.

Para sua implantação ao vivo, certifique-se de não escolher a implantação automática e certifique-se de escolher a ramificação mestre como a origem da sua implantação. Queremos que isso seja uma implantação manual quando estivermos prontos para enviar as alterações para nosso site ativo.

Para fazer isso, você precisará verificar sua ramificação master e depois mesclar suas alterações de sua ramificação de teste no master.

Você pode fazer isso com esses comandos.

mestre de checkout git

git merge staging

mestre de origem git push

Agora, quando você acessar sua conta do Deploybot, poderá implantar manualmente suas alterações, assim como fizemos com nossa implantação inicial em nosso ambiente de teste. Para seu ambiente ativo, certifique-se de alterar a mensagem de implantação para se adequar às alterações que estão sendo enviadas por push para seu site ativo. Você também deve criar um backup do seu site. Você pode fazer isso acessando a navegação de backups em seu site e criando um backup manual.

É isso, você tem sua configuração de sistema de implantação automatizada para ambientes de teste e ao vivo.

Outras considerações de implantação

Embora este sistema seja um grande passo à frente para a maioria dos desenvolvedores, não está isento de problemas. A maior delas é que, se você tiver várias alterações, ainda estará esperando que o FTP termine de transferir os arquivos que foram alterados. Isso pode significar que alguém visita seu site e nem todos os arquivos que seu site precisa para executar estão presentes.

Para muitos clientes, isso não será um problema, mas se for para o seu site, você precisará configurar um sistema de implantação Atomic. Esse tipo de sistema de implantação move todos os arquivos, verifica se estão funcionando corretamente e, em seguida, altera as configurações de arquivo em seu servidor para que o novo diretório seja agora aquele que executa seu site.

O processo de vinculação a uma nova pasta leva tão pouco tempo que apenas um computador perceberia. Isso também significa que, se você encontrar um problema posteriormente, poderá alterar o link do sistema para a versão antiga do site para reverter para a versão que estava funcionando. Novamente, isso leva apenas um período muito curto de tempo e reduz o tempo de inatividade.

Não importa o que você escolha fazer, pare de usar um cliente FTP para implantar seus arquivos de cliente hoje. O pequeno custo mensal do Deploybot é recuperado toda vez que você não comete um erro ao implantar seus arquivos.