Ok, pessoal. É hora de 'confessar.

Se você for como eu, você passou a primeira etapa do seu Desenvolvimento WordPress anos de “codificação cowboy” - isto é, fazer mudanças descontroladamente em sites ativos, testá-los com urgência e ativá-los com FTP, muitas vezes resultando em 500 mensagens de erro interno do servidor e quebras em todo o site, todos visíveis para seus estimados visitantes.

Embora isso fosse absolutamente emocionante com a adrenalina bombeando pelos seus 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 cair e ninguém estiver lá para ouvi-la, ela faz algum barulho? Depende da teoria da humanidade que você subscreve.

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

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

Entre em 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 ao vivo assim que tudo estiver funcionando corretamente. Embora isso acalmasse os visitantes, começou a fazer com que nós, desenvolvedores, fizéssemos algum barulho. De repente, precisávamos controlar 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 mudar 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 foram 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. Usar o controle de versão para instalações do WordPress agilizou e limpou instantaneamente o desenvolvimento, já que as horas não eram mais gastas fazendo backup em um sistema por desenvolvedor, mas sim na codificação. As alterações foram salvas e eu pude finalmente adicionar mensagens significativas ao meu trabalho, mundos de diferença de “my-theme-4-v2.”

Embora a base de código fosse muito mais limpa, ainda restava o problema das implantações reais e da garantia de que o site em questão estava usando o código mais recente - insira a oportunidade para erro humano. Ainda depender de uploads de FTP manuais sobrescrevendo o código anterior não parecia bem. Embora existissem outros serviços de CI / CD, muitos deles vinham com um preço substancial e grande quantidade de configuração - reconfiguração do servidor, contando com 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 vêm com ele.

Embora configurações semelhantes a este tutorial possam ser feitas com GitHub / GitLab e outros serviços, eu coloquei meus ovos na cesta Atlassian desde o início devido aos seus repositórios privados gratuitos (que foi apenas uma oferta recente do GitHub). Quando Bitbucket apresentou seu Pipelines e implantações serviços, permitiu que um novo código fosse implantado automaticamente em sites de teste ou produção (ou qualquer outro site intermediário) sem recarregar 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 tecla adicionais, com o status de tudo visível em um painel. Isso garante que tudo permaneça sincronizado e, de relance, permite que você saiba exatamente qual código cada site está executando. Além disso, o preços para os 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 excedentes'.

Demorou um pouco para descobrir como usar melhor os branches e outros recursos de controle de origem neste novo modelo e os detalhes da configuração do Bitbucket Pipelines. Este é o processo que uso para iniciar novos projetos WordPress. Não vou entrar em todos os detalhes sobre como configurar a instalação do git e do WordPress, já que ótimos recursos para isso estão apenas a uma pesquisa do Google. No final, o fluxo de conteúdo será mais ou menos assim:

A Rotina de Depoyment Alexa Green WordPress

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

No servidor do cliente

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

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

Em Bitbucket.com

Configure um novo repositório. Inclua um .README para nos colocar em prática.

No repositório, Configurações> Pipelines> Configurações então verifique Habilitar pipelines .

Dentro Configurações> Pipelines> Variáveis ​​de repositório , digite 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 Configure bitbucket-pipelines.yml botão. Selecione PHP como o idioma na página seguinte. 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 URLs / servidores FTP com os URLs / servidores 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 Enviar 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 acessá-lo através de Pipelines> Configurações e Veja bitbucket-pipelines.yml ) Você vai querer substituir os dois lugares onde está escrito git ftp init com git ftp push e salvar / confirmar. Isso garantirá que apenas os arquivos alterados sejam enviados, economizando minutos de construçã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 main-dev ramo.

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

Adicione um .gitignore que se parece com isso. Essencialmente, queremos que o Git ignore tudo, exceto wp-content (para evitar problemas de instalação entre as instalações). Você também pode querer 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

Salvar e confirmar .gitignore.

Faça alterações e comprometa-se de acordo.

Sempre que você se comprometer com 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, então você pode querer fazer a maioria das mudanças locais em um branch fora do main-dev e então mesclar para main-dev quando terminar o dia.

Mesclar main-dev no master colocará todas as alterações de teste ativas. Você pode verificar o status de pipelines e implantações no repo em Bitbucket.org.

Sincronizando Bancos de Dados WordPress em Instalações

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

Para sincronizar bancos de dados em 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 permalinks no conteúdo da postagem. Usando este método, uma ferramenta favorita é o Plug-in de URLs de atualização do Velvet Blues , que você pode usar para pesquisar / substituir quaisquer instâncias do antigo URL do site (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. Este 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 capaz de usar o plugin / acessar o painel.

Enquanto um plugin como Migração All-in-One WP oferece um recurso de busca / substituição pronto para uso e é incrivelmente amigável, ele também traz arquivos, desfazendo assim os valores de todo o nosso fluxo de trabalho de Pipelines. Além disso, como ele reimporta todos os uploads wp, 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 uma solução interessante, mas ainda não foi comprovada em muitos ambientes de produção. Por enquanto, plug-ins 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 entre as instalações, oferecendo a opção de atualizar URLs e caminhos automaticamente. Eles podem migrar apenas algumas tabelas, como wp_posts para postar conteúdo apenas, sem perder tempo com a reimportação de usuários e configurações em todo o site. Gosto de sempre fazer pull do live para garantir que nenhum dado de produção seja sobrescrito. Aqui está um exemplo de configuração se você estiver usando WP Sync DB (mais orientações disponíveis em o github WP Sync DB ):

1. No site ao vivo: Configure WP Sync DB com a configuração “Allow Pull from this repository” habilitada.
2. No site de teste: Configure o WP Sync DB com as configurações Pull from Live. Nomeie-o como “live-to-staging”.
3. Em sua configuração de dev local: Configure o WP Sync DB com as configurações Pull from Live. Nomeie-o '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 sobrescrito.

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 para redesenhar / reconfigurar 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 segura e intencional para trabalhar entre sites. A atualização de plug-ins também é feita no controle de origem, portanto, as atualizações de plug-ins podem ser verificadas com segurança na preparação antes de enviar para o site ativo, minimizando assim as interrupções do site de produção.

Embora certamente haja espaço para melhorias para trazer mais fluxo de trabalho de controle de origem para o gerenciamento de banco de dados, até que uma ferramenta como o VersionPress seja mais usada em ambientes de produção, esse método de pulls / pushs seletivos 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 WordPress, ou se depois de tudo isso, você prefere apenas pegar seu laço e codificá-lo!

Compreender o básico

O WordPress tem controle de versão?

O WordPress não tem nenhum controle de versão integrado, portanto, é necessária uma solução personalizada.

Você pode usar o GitHub com WordPress?

Você pode usar o GitHub ou outra solução de controle de versão (GitLab, Bitbucket) com WordPress, que permite usar os recursos de desenvolvimento modernos de controle de versão com WordPress.

Qual é a diferença entre Bitbucket e Bitbucket Server?

Bitbucket e Bitbucket Server são soluções de controle de versão. O Bitbucket é a oferta padrão e requer configuração mínima, enquanto o Bitbucket Server fornece às equipes mais personalização e controle.

Por que usamos Bitbucket?

O Bitbucket é uma solução de controle de versão confiável da Atlassian e fornece repositórios privados gratuitos ilimitados muito antes do GitHub. Ele se integra com seu serviço de CI / CD Pipelines (permitindo a configuração de integração contínua e implantação em minutos) e seu software Jira, a questão nº 1 e ferramenta de rastreamento de projeto.

Qual é o objetivo do controle de versão?

O controle de versão permite que os desenvolvedores e equipes atualizem o código com segurança e vejam as alterações rapidamente. Ele mantém backups de código antigo e permite que os desenvolvedores 'ramifiquem' o código principal para trabalhar em certos recursos ou correções de bugs, e apenas se fundir com a versão de trabalho e implantar quando tudo for aprovado.

Como funciona o controle de versão?

O controle de versão registra as alterações em um arquivo (ou conjunto de arquivos) para que seu histórico possa ser revisado posteriormente, se necessário. Ele pode destacar as diferenças entre as diferentes versões para que os desenvolvedores possam ver rapidamente o que mudou.