Implantação Contínua do WordPress e Controle de Versão com Bitbucket

Ok, pessoal. Hora de confessar.

Se você for como eu, você passou a primeira etapa de seus anos de desenvolvimento do WordPress “codificando cowboy” – ou seja, fazendo alterações descontroladamente em sites ao vivo, testando-os com urgência e acionando-os com FTP, geralmente resultando em 500 mensagens de erro interno do servidor e sitewide quebra tudo visível para seus visitantes estimados.

Embora isso fosse absolutamente emocionante, pois a adrenalina bombeava por entre os dedos, batendo naquele ponto e vírgula esquecido, em sites com mais de 0 visitantes (que realmente notaram o tempo de inatividade), isso começaria a se tornar um problema. Se uma árvore cai e ninguém está lá para ouvir, ela faz barulho? Depende da teoria da humanidade que você subscreve.

No entanto, se um site travar e alguém estiver lá para vê-lo, eles certamente farão um som.

Implantação contínua do WordPress feita de forma errada

Entre nos sites de teste, duplique as instalações do WordPress (pelo menos em teoria) onde as alterações podem ser feitas e, em seguida, faça novamente no site ativo assim que tudo estiver funcionando. Enquanto isso acalmou os visitantes, começou a fazer com que nós, desenvolvedores, fizéssemos algum barulho. De repente, precisávamos acompanhar dois sites, garantir que o código fosse sincronizado manualmente entre eles e testar tudo novamente para ter certeza de que estava funcionando no site ativo. Listas longas e confusas de “certifique-se de alterar isso ao vivo” e “certifique-se de alternar isso no site de teste antes de copiar o código” eram estressantes, para dizer o mínimo. Os backups desse sistema também eram um pesadelo – uma série de pastas chamadas “my-theme-staging-1” e “my-theme-live-before-menu-restyle-3” e assim por diante.

Tinha que haver uma maneira melhor, e havia.

Havia o Git, que dá controle de origem perfeito e outros recursos aos desenvolvedores. O uso do controle de versão para instalações do WordPress agilizou e limpou instantaneamente o desenvolvimento, pois as horas não eram mais gastas fazendo backup em um sistema por desenvolvedor, mas na verdade em codificação. As alterações foram salvas e eu finalmente pude adicionar mensagens significativas ao meu trabalho, mundos de diferença de “meu-tema-4-v2”.

Embora a base de código fosse muito mais limpa, o problema ainda permanecia nas implantações reais e na garantia de que o site em questão estava usando o código mais recente — digite oportunidade para erro humano. Ainda depender de uploads de FTP manuais sobrescrevendo o código anterior não parecia ótimo. Embora existissem outros serviços de CI/CD, muitos deles vinham com um preço substancial e uma grande quantidade de configuração - reconfiguração do servidor, confiando em outro serviço até mesmo para o site mais simples, aprendendo toda a "maneira de fazer as coisas" do outro serviço e tudo as idiossincrasias que o acompanham.

Embora configurações semelhantes a este tutorial possam ser feitas com o GitHub/GitLab e outros serviços, eu coloquei meus ovos na cesta da Atlassian desde o início devido a seus repositórios privados gratuitos (que só foi uma oferta recente do GitHub). Quando o Bitbucket introduziu seus serviços de Pipelines e Implantações , ele permitiu que o novo código fosse implantado automaticamente em sites de teste ou produção (ou qualquer outro site intermediário) sem reenviar via FTP ou usar um serviço externo. Os desenvolvedores agora podem usar todos os valores do controle de origem em seu desenvolvimento WordPress e enviar instantaneamente essas alterações para os destinos apropriados sem cliques ou pressionamentos de teclas adicionais, com o status de tudo visível em um painel. Isso garante que tudo permaneça sincronizado e, rapidamente, permite que você saiba exatamente qual código cada site está executando. Além disso, o preço dos minutos de compilação do Bitbucket é incrivelmente acessível - com 50 minutos grátis por mês e uma opção para um plano “Grátis com excessos”.

Demorou um pouco de tempo de inicialização para descobrir como usar melhor as ramificações e outros recursos de controle de origem neste novo modelo e os detalhes da configuração do Bitbucket Pipelines. Aqui está o processo que eu uso para iniciar novos projetos do WordPress. Não vou entrar em todos os detalhes sobre como configurar o git e a instalação do WordPress, pois ótimos recursos para isso estão a apenas uma pesquisa do Google. No final, o fluxo de conteúdo será algo assim:

A rotina de depósito Alexa Green WordPress

As etapas descritas aqui devem ser executadas conforme necessário:

No servidor do cliente

Configure um domínio para o site ativo (por exemplo, clientsite.com) e um subdomínio para teste (por exemplo, staging.clientsite.com).

Instale o WordPress no site ativo e no subdomínio de teste. Isso pode ser feito via cPanel/Softaculous (se a hospedagem do cliente tiver) ou baixando do wordpress.org. Certifique-se de que haja bancos de dados separados para live e staging, respectivamente.

No Bitbucket.com

Configure um novo repositório. Inclua um .README para nos ajudar a começar.

No repositório, Configurações > Pipelines > Configurações e marque Ativar pipelines .

Em Configurações > Pipelines > Variáveis ​​de repositório , insira o seguinte:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Volte para Pipelines > Configurações e clique no botão Configurar bitbucket-pipelines.yml . Selecione PHP como o idioma na página a seguir. Você vai querer usar algo como o código a seguir. Certifique-se de substituir a versão do PHP com o que você está usando no servidor do cliente e os URLs/servidores FTP pelos servidores URL/FTP do site do cliente real (produção e teste).

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Clique em Confirmar arquivo . A configuração do Pipelines agora será confirmada e executada.

Se tudo for implantado com sucesso, volte e edite o arquivo bitbucket-pipelines.yml (você pode chegar lá em Pipelines > Settings e View bitbucket-pipelines.yml ). Você vai querer substituir os dois lugares onde diz git ftp init por git ftp push e save/commit. Isso garantirá que apenas os arquivos alterados sejam carregados, economizando minutos de compilação. Seu arquivo bitbucket-pipelines.yml agora deve ser:

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Adicione uma ramificação chamada main-dev .

Em sua máquina local

Clone o repositório em um diretório vazio que você gostaria de usar para a instalação local. Confira o branch main-dev .

Configure uma instalação local do WP neste diretório. Existem muitas ferramentas para isso—Local por Flywheel, MAMP, Docker, etc. Certifique-se de que tudo esteja igual (versão do WordPress, versão do PHP, Apache/Nginx, etc.) que está sendo executado no servidor do cliente.

Adicione um .gitignore parecido com isto. Essencialmente, queremos que o Git ignore tudo, exceto wp-content (para evitar problemas de instalação entre instalações). Você também pode adicionar suas próprias regras para ignorar arquivos de backup grandes e ícones criados pelo sistema e arquivos DS_Store.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

Salve e confirme .gitignore .

Faça as alterações e confirme de acordo.

Sempre que você se comprometer com o main-dev, ele disparará um upload de FTP para o site de teste. Sempre que você se comprometer com o master, ele disparará um upload de FTP para o site de produção. Observe que isso usará minutos de compilação, portanto, você pode querer fazer a maioria das alterações locais em uma ramificação fora do main-dev e, em seguida, mesclar com o main-dev quando terminar o dia.

A fusão do main-dev com o master trará todas as mudanças de preparação ao vivo. Você pode verificar o status de pipelines e implantações no repositório em Bitbucket.org.

Sincronizando bancos de dados do WordPress entre instalações

Observe que o acima apenas sincronizará arquivos (temas, plugins, etc). Sincronizar o banco de dados entre produção e teste torna-se uma questão diferente, pois muitas vezes os clientes estão fazendo alterações no site ativo que não são refletidas no site de teste e vice-versa.

Para sincronizar bancos de dados nas instalações do WordPress, existem várias opções. Tradicionalmente, você pode atualizar bancos de dados importando/exportando via phpmyadmin . Isso é complicado, pois não pode atualizar certas coisas que precisam ser atualizadas, como links permanentes no conteúdo do post. Usando esse método, uma ferramenta favorita é o plug-in Velvet Blues Update URLs, que você pode usar para pesquisar/substituir quaisquer instâncias do URL do site antigo (por exemplo, https://staging.clientsite.com) para o novo URL do site ( por exemplo, https://clientsite.com). Você também pode usar isso com caminhos e strings relativos. Esse método acaba deixando muito espaço para erro humano - se uma string substituída for escrita incorretamente, pode fazer com que todo o site quebre e não seja possível usar o plug-in/acessar o painel.

Embora um plug-in como o All-in-One WP Migration ofereça um recurso de pesquisa/substituição pronto para uso e seja incrivelmente fácil de usar, ele também traz arquivos, desfazendo assim os valores de todo o fluxo de trabalho do Pipelines. Além disso, como reimporta todos os wp-uploads, pode resultar em arquivos enormes e tempos de carregamento (portanto, não é adequado para mover alterações entre instalações). Um plugin como este é melhor reservado para backups de todo o site para fins de arquivamento/segurança.

VersionPress parece ser uma solução interessante, mas ainda não foi comprovada em muitos ambientes de produção. Por enquanto, plugins como WP Sync DB ou WP Migrate DB Pro parecem ser as melhores soluções para gerenciamento de banco de dados. Eles permitem puxar/enviar bancos de dados em instalações, oferecendo a opção de atualizar automaticamente URLs e caminhos. Eles podem migrar apenas determinadas tabelas, como wp_posts apenas para conteúdo de postagem, sem perder tempo na reimportação de usuários e configurações de todo o site. Eu gosto de sempre puxar ao vivo para garantir que nenhum dado de produção seja substituído. Aqui está um exemplo de configuração se você estiver usando o WP Sync DB (mais orientações disponíveis no github do WP Sync DB):

1. No site ao vivo: Configure o WP Sync DB com a configuração “Permitir pull deste repositório” habilitada.
2. No site de teste: Configure o WP Sync DB com as configurações de Pull from Live. Dê o nome de “ao vivo para encenação”.
3. Na configuração do seu desenvolvedor local: Configure o WP Sync DB com as configurações de Pull from Live. Dê o nome de “live-to-dev”.

Você também pode configurar uma regra de envio "dev-to-staging" e verificar a configuração do site de teste para permitir que o banco de dados seja substituído.

Empacotando

Descobri que esses métodos tendem a funcionar para a maioria dos casos de uso, tanto no desenvolvimento de um novo site WordPress quanto no redesenho/refiguração de um site já ativo.

Ele permite implantações de código que mantêm todas as versões do site atualizadas sem adição de tempo/esforço de desenvolvimento e lógica de migração de banco de dados intencional e segura para trabalhar entre sites. A atualização de plug-ins também é feita no controle de origem, para que as atualizações de plug-in possam ser verificadas com segurança no teste antes de se comprometer com o site ativo, minimizando assim as interrupções do site de produção.

Embora certamente haja espaço para melhorias para trazer mais um fluxo de trabalho de controle de origem para o gerenciamento de banco de dados, até que uma ferramenta como VersionPress seja mais usada em ambientes de produção, esse método de pull / push seletivo do banco de dados via WP Sync DB ou WP Migrate DB Pro parece para ser o método mais seguro de lidar com isso. Curioso para saber o que funciona para o seu fluxo de trabalho do WordPress, ou se depois de tudo isso você preferir apenas pegar seu laço e codificá-lo!