Como sincronizar o seu ambiente de desenvolvimento local com a produção

Quando a sua configuração de desenvolvimento local não corresponde ao seu servidor de produção, você está basicamente a programar às cegas.

Pode pensar que tudo funciona. Provavelmente funciona — na sua máquina. Mas não é aí que importa.

Ter um processo confiável para sincronizar o desenvolvimento local com a produção não é apenas algo bom de se ter. É o que diferencia os profissionais das pessoas que cruzam os dedos toda vez que fazem uma implementação.

Nesta publicação, vou apresentar métodos comprovados para manter os seus ambientes sincronizados. Você encontrará um que se adapta ao seu fluxo de trabalho!

Eis as principais conclusões:

• A sincronização de ambientes elimina problemas de compatibilidade e detecta erros antes que os utilizadores os vejam.
• Você pode usar o Duplicator para um fluxo de trabalho de sincronização local fácil para iniciantes ou o GitHub + WP-CLI para controle de linha de comando.
• Sempre baixe o banco de dados da produção e envie apenas as alterações de código para evitar sobrescrever os dados ativos.
• Os sites WordPress têm três partes para sincronizar: código (Git), base de dados (WP-CLI) e ficheiros multimédia (rsync)
• Faça sempre uma cópia de segurança antes de sincronizar qualquer coisa, use ambientes de teste para fazer testes e mantenha um ficheiro .gitignore adequado.

Índice

Por que sincronizar os seus ambientes local e de produção?

Provavelmente conseguiria sobreviver sem sincronizar ambientes. Muitas pessoas fazem isso. Elas apenas lidam com bugs surpresa ocasionais, problemas de produção aleatórios que não ocorreram localmente e a incerteza incómoda sempre que enviam uma atualização.

Mas porquê passar por isso?

Manter os seus ambientes local e de produção em sincronia elimina muitos problemas. Veja o que você realmente ganha ao fazer isso da maneira certa.

Detecte erros antes que eles entrem em produção

Um ambiente local sincronizado reflete a configuração real do seu servidor de produção. Ele terá a mesma versão do PHP, estrutura de banco de dados e plug-ins nas mesmas versões.

Isso é mais importante do que você imagina.

Quando trabalha numa configuração local que corresponde à produção, os problemas de compatibilidade surgem imediatamente. Detecta-os na sua secretária, não na frente dos utilizadores. Essa é a diferença entre um pequeno inconveniente e um problema real.

Uma área de testes realista

Testar com dados fictícios é adequado para criar funcionalidades iniciais. Mas, em algum momento, é necessário ver como as coisas realmente se comportam.

O conteúdo real dos utilizadores é confuso. Os catálogos de produtos têm casos extremos estranhos.

O seu site local precisa desses dados reais para lhe dar uma visão precisa do que está a acontecer.

A sincronização a partir da produção fornece as publicações, os utilizadores e os produtos reais com os quais o seu código irá interagir. Já não precisa de adivinhar; está a testar com base na realidade.

Sem problemas de compatibilidade

Todo programador já disse, pelo menos uma vez, «Mas funcionou na minha máquina». A esta altura, isso já se tornou praticamente um meme.

Mas também é um sintoma de ambientes incompatíveis. Quando a sua configuração local é basicamente idêntica à produção, essa desculpa desaparece. Se funciona localmente, funciona ao vivo.

Esse tipo de confiança muda a forma como trabalha. Deixa de questionar cada implementação.

Melhorar a colaboração em equipa

Quando se trabalha sozinho, é possível lidar com um processo desorganizado. Adicione um segundo programador à equação e as coisas complicam-se rapidamente.

Um processo de sincronização consistente significa que todos começam a partir da mesma base. Todos estão a testar com o mesmo banco de dados, usando a mesma estrutura de conteúdo e executando a mesma configuração de ambiente.

Sem isso, acabas com três versões diferentes de «local» e ninguém tem a certeza de qual delas está mais próxima da produção. Isso não é colaboração; é caos.

Como sincronizar o seu ambiente local com a produção

Pode fazer isso manualmente. Exporte a base de dados através do phpMyAdmin, faça o download, importe-a localmente e localize e substitua manualmente todos os URLs no ficheiro SQL. Em seguida, aceda ao seu servidor via FTP, comprima a pasta uploads, faça o download e extraia-a localmente...

Estou exausto só de escrever isso.

Os métodos manuais são tediosos e arriscados. Se falhar uma substituição de URL, o seu site local começará a apontar para recursos de produção. Se se esquecer de atualizar corretamente uma matriz serializada, corromperá a sua base de dados.

Existe uma maneira melhor. Veja como sincronizar os seus ambientes locais de desenvolvimento e produção:

• Duplicator: plugin de migração com substituição automática de URL e instaladores guiados — perfeito para iniciantes ou sincronizações rápidas
• GitHub + WP-CLI: Controlo por linha de comando para sincronizar código via Git, base de dados via exportações WP-CLI e mídia via rsync — ideal para programadores que desejam um controlo granular

Sincronize sites locais e de produção com o Duplicator

Este é o método mais simples, especialmente se não se sentir confortável a viver no terminal.

O Duplicator cria um instantâneo completo do seu site e fornece um instalador que lida com todas as partes complicadas automaticamente. Não terá de se preocupar com substituições manuais de URL ou dores de cabeça com a configuração da base de dados.

Transferência da produção para o local (fluxo de trabalho comum)

Isso é o que você fará com mais frequência. Você quer obter o estado atual do seu site ao vivo e trabalhar com ele localmente.

Comece instalando o Duplicator Pro no seu site de produção e crie um novo backup completo do site. Pense nisso como tirar uma foto instantânea de todo o seu site neste exato momento.

A criação do backup demora alguns minutos, dependendo do tamanho do seu site. Quando estiver concluída, terá dois ficheiros: um arquivo (normalmente um ficheiro .daf ou .zip) e um script de instalação (um ficheiro .php). Faça o download de ambos.

Agora vá para o seu ambiente local. Crie um diretório vazio onde deseja que a sua cópia local fique. Coloque os dois ficheiros — o arquivo e o instalador — nesse diretório vazio.

Abra o seu navegador e navegue até esse diretório. Algo como http://localhost/mysite/installer.php. O assistente de instalação do Duplicator será iniciado.

O assistente orienta-o na ligação à sua base de dados local e trata automaticamente de todas as substituições de URL.

Ele sabe que o seu site de produção estava em https://mysite.com e que o seu site local está em http://localhost/mysite. Ele corrige todas as referências na base de dados sem que você precise fazer nada.

Cinco minutos depois, você terá uma cópia local perfeita do seu site de produção.

Enviando do ambiente local para o ambiente de produção

Este fluxo de trabalho segue na direção oposta. Está a pegar no seu site local e a implementá-lo na produção.

Tenha cuidado aqui. Isto é realmente apenas para lançamentos de novos sites ou reformulações completas. Se tem um site ativo com utilizadores ativos, provavelmente não vai querer fazer isto. Vai sobrescrever as publicações, comentários e encomendas recentes deles.

Se precisar enviar o local para produção, o processo é semelhante, mas invertido.

Primeiro — e não me canso de repetir isso — faça um backup completo do seu site de produção antes de fazer qualquer outra coisa.

Em seguida, crie uma cópia de segurança do seu site local usando o Duplicator e faça o download. Carregue ambos os ficheiros de cópia de segurança para o seu servidor de produção via FTP ou arraste e solte o arquivo na página Importar.

Mais uma vez: faça isso apenas se tiver certeza de que deseja substituir completamente a produção. Para garantir que você possa reverter facilmente quaisquer alterações inesperadas, certifique-se de definir um ponto de recuperação.

O Duplicator fornecerá uma URL de recuperação que restaura um backup recente, mesmo que o seu site esteja completamente danificado.

Sincronize sites locais e de produção com GitHub e WP-CLI

Se estiver familiarizado com a linha de comando, este método oferece mais controlo e se encaixa num fluxo de trabalho baseado em Git.

A questão sobre os sites WordPress é a seguinte: eles são compostos por três partes distintas que precisam ser sincronizadas separadamente.

• Código: os seus ficheiros de tema, plugins e ficheiros principais do WordPress. É isso que o Git gere.
• Base de dados: todo o seu conteúdo, definições e configurações. O Git não mexe nisso. Precisa do WP-CLI.
• Mídia: tudo na sua pasta /wp-content/uploads/. Também não está no Git. Precisa do rsync ou de uma ferramenta semelhante.

É fundamental compreender essa separação. O Git por si só não é suficiente.

O fluxo de trabalho para extrair da produção

Vamos ver como transferir o seu site de produção para o local.

Para o código, é simples. Se o seu tema e plugins personalizados estiverem num repositório Git, basta executar:

git pull origin main

O seu código local agora corresponde à produção.

Para o banco de dados, aceda ao seu servidor de produção via SSH e exporte o banco de dados usando o WP-CLI:

wp db export production-backup.sql

Faça o download desse ficheiro .sql para o seu computador local. Em seguida, importe-o localmente:

wp db import production-backup.sql

Mas ainda não terminou. A sua base de dados ainda contém todos os URLs de produção. Precisa substituí-los pelos seus URLs locais:

wp search-replace 'https://mysite.com' 'http://localhost/mysite'

Este comando de pesquisa e substituição procura em todas as tabelas e campos, atualizando os URLs sempre que eles aparecem. Ele até mesmo lida corretamente com dados serializados, o que é fundamental para o WordPress.

Ignore esta etapa e o seu site local tentará carregar imagens da produção, redirecioná-lo para o site ativo e, em geral, comportar-se como se não soubesse onde está hospedado.

Para ficheiros multimédia, use o rsync. Ele foi criado para sincronizar diretórios grandes com eficiência.

rsync -avz user@mysite.com:/path/to/wp-content/uploads/ ./wp-content/uploads/

Os sinalizadores -avz significam «modo arquivo, saída detalhada, comprimir durante a transferência». Este comando apenas descarrega ficheiros que foram alterados, pelo que as sincronizações subsequentes são rápidas.

Execute estas três etapas (extrair código, importar base de dados, sincronizar mídia) e terá uma cópia local completa da produção.

Melhores práticas para garantir uma sincronização suave e segura

Pode ter as melhores ferramentas do mundo, mas isso não importa se as usar de forma errada.

Já vi programadores destruírem bases de dados de produção porque fizeram push quando deveriam ter feito pull. Já vi pessoas ignorarem backups porque «é só uma sincronização rápida» e depois passarem o fim de semana a recuperar dados.

Não seja essa pessoa.

Essas práticas recomendadas podem ser a diferença entre um fluxo de trabalho tranquilo e um erro que pode acabar com a sua carreira.

Faça sempre uma cópia de segurança primeiro

Antes de sincronizar qualquer coisa em qualquer direção, faça um backup. Na única vez que você deixar de fazer isso, algo dará errado.

O Duplicator facilita isso — ele é um plugin de migração e backup. O primeiro passo em toda migração push ou pull será um backup completo do site, protegendo o seu site.

Se algo acontecer, clique no botão Restaurar com um clique.

Ou carregue ambos os ficheiros de cópia de segurança de volta para o mesmo servidor. Execute o instalador e siga as instruções de recuperação.

Se estiver a utilizar ferramentas de linha de comando, execute um rápido wp db export antes de fazer qualquer outra coisa.

Cinco minutos para criar um backup podem poupar dias de trabalho de recuperação.

Puxe para baixo, empurre o código para cima

Este é o fluxo de trabalho profissional padrão: transfira a base de dados e os ficheiros de mídia da produção para o local. Envie apenas as alterações de código para a produção através do Git.

Você raramente deve enviar o seu banco de dados local para produção, a menos que esteja lançando um site totalmente novo.

Porquê? Porque a produção tem dados reais que estão sempre a mudar. Se substituir a base de dados de produção pela sua cópia local, toda essa atividade recente desaparece.

Use um ambiente de teste

O fluxo de trabalho ideal não é Local » Produção. É Local » Preparação » Produção.

Um ambiente de teste é uma cópia do seu site de produção que fica num servidor real, mas não é acessível ao público. É o seu campo de testes final antes das alterações serem implementadas.

Desenvolva localmente. Em seguida, teste em ambiente de teste com a configuração real do servidor e dados recentes de produção. Somente depois que tudo estiver verificado no ambiente de teste, implemente na produção.

Isso adiciona uma margem de segurança. Se algo falhar na preparação, nenhum utilizador verá. Você detecta e corrige o problema antes que ele se torne relevante.

Nem todos os projetos precisam de preparação, especialmente sites pequenos. Mas para qualquer coisa com tráfego real ou funcionalidade de comércio eletrónico, vale a pena configurar.

Use um ficheiro .gitignore

Se estiver a usar o Git, precisa indicar o que não deve ser rastreado.

O seu ficheiro wp-config.php contém credenciais de base de dados que são diferentes em cada ambiente. Não deve estar sob controlo de versão.

A sua pasta /wp-content/uploads/ pode conter gigabytes de imagens e ficheiros. Esses ficheiros também não pertencem ao Git — é para isso que serve o rsync.

Crie um ficheiro .gitignore na raiz do seu repositório e adicione, no mínimo, o seguinte:

wp-config.php

.htaccess

wp-content/uploads/

*.log

Isso mantém o seu repositório limpo e evita que você acidentalmente envie informações confidenciais ou sobrecarregue o seu repositório com ficheiros binários.

Perguntas mais frequentes (FAQs)

Aperfeiçoe o seu fluxo de trabalho de sincronização do WordPress

Ir além dos métodos manuais é um dos pontos de viragem na sua carreira de desenvolvimento. Deixa de ser alguém que copia ficheiros e cruza os dedos. Torna-se alguém com um processo.

Um fluxo de trabalho repetível — quer esteja a utilizar uma ferramenta como o Duplicator ou a executar comandos no terminal — substitui a ansiedade da implementação por confiança.

O seu eu futuro agradecerá na próxima vez que precisar testar um recurso com dados reais de produção, baixar o conteúdo mais recente ou fazer uma implementação sem stress.

Pronto para parar de lidar com ferramentas de linha de comando e se preocupar se perdeu alguma etapa? O Duplicator Pro oferece um kit de ferramentas completo e confiável para migrar e fazer backup do seu site.

Crie um backup completo do site, envie-o diretamente para o armazenamento na nuvem e implemente-o em um novo local com um instalador simples e guiado que cuida de todo o trabalho pesado. Confira o Duplicator Pro para simplificar o seu fluxo de trabalho hoje mesmo!

Já que está aqui, acho que vai gostar destes outros recursos WordPress escolhidos a dedo:

• Como usar a CLI do WordPress: Domine a linha de comando
• Como mover um site WordPress ativo para um host local (a maneira mais fácil)
• Como mover um site WordPress local para um servidor ativo
• Codificar de forma mais inteligente, não mais difícil: Ferramentas para desenvolvedores WordPress para todos os profissionais
• Como um programador migra facilmente lojas online com 150 000 produtos