Implantações modernas para seus sites WordPress

Se você é como eu, sua primeira experiência ao enviar arquivos para um servidor web foi através de um gerenciador de arquivos baseado na web como o cPanel ou um cliente de protocolo de transferência de arquivos (FTP) como Transmit ou Filezilla. Conecte-se ao servidor, arraste seu(s) arquivo(s) e aguarde a conclusão da transferência.

Fácil, certo?

No entanto, assim que comecei a trabalhar com algo mais complexo do que arquivos HTML estáticos, a implantação do meu código tornou-se muito mais complexa: o que acontece se eu perder um arquivo exigido por outros, ou um ponto e vírgula em uma inclusão global e ele exibir uma tela branca no site inteiro? E se uma etapa crucial for perdida durante o processo?

Esses problemas de “codificação de cowboys” só pioram à medida que mais pessoas, ambientes e dependências se envolvem. Como resultado, fica cada vez mais difícil continuar progredindo enquanto faz malabarismos com todas essas partes móveis. Pior de tudo, liberar código se torna um grande negócio e uma fonte constante de ansiedade.

À medida que nossos aplicativos, sites e lojas se modernizam, também devemos modernizar nossas implantações. Do controle de versão à entrega contínua, um processo de lançamento moderno pode aliviar a ansiedade em torno das implantações.

Acompanhamento de alterações com controle de versão

O primeiro passo para se afastar das atualizações ad-hoc e da codificação cowboy é colocar seu site sob controle de versão, usando uma ferramenta como o Git.

Usar o controle de versão significa que você poderá ver o que mudou, quem fez as alterações e até mesmo trabalhar em vários conjuntos de alterações ao mesmo tempo usando ramificações. Como resultado, o trabalho não está sendo substituído e quaisquer conflitos entre arquivos são claramente destacados.

Se você nunca trabalhou com Git antes, não tenha medo: escrevemos uma introdução ao Git e um post sobre fluxos de trabalho Git mais avançados.

Decidindo o que rastrear

À medida que movemos nosso site sob controle de versão, o que não acompanhamos é quase tão importante quanto o que fazemos:

De um modo geral, o controle de versão é para rastrear o código-fonte, não os ativos gerados por ferramentas ou processos . Isso inclui coisas como CSS e JavaScript concatenados/minificados, dependências externas etc. Coletivamente, nos referimos a esses itens como artefatos .

Por exemplo, se você estiver usando um pré-processador CSS como o Sass, os arquivos CSS gerados não devem ser rastreados sob controle de versão. Além de serem facilmente reproduzíveis, são difíceis de ler e uma fonte comum de conflitos de mesclagem quando vários desenvolvedores estão envolvidos.

Quando se trata de dependências (bibliotecas, plugins WordPress, etc.), aproveite ferramentas como Composer e WPackagist em vez de agrupar códigos pelos quais você não é responsável em seu repositório.

Além disso, um repositório Git nunca deve conter coisas como senhas, chaves SSH privadas ou qualquer outra informação confidencial que seja considerada secreta , pois todo desenvolvedor com uma cópia do repositório teria essas informações confidenciais em seus computadores.

Estruturando seu repositório

Ao configurar um repositório Git para um site WordPress ou WooCommerce, geralmente é melhor tratar wp-content/ como a raiz do repositório, já que você geralmente não tocará em arquivos acima desse diretório.

Plugins e temas que seu site usa, mas você não está mantendo o código, devem ser carregados via Composer, pois são dependências externas. Da mesma forma, arquivos CSS e JavaScript processados ​​devem ser excluídos por meio do arquivo .gitignore, pois esses artefatos serão criados para nós como parte de nosso processo de lançamento.

Temos um modelo de repositório gratuito disponível no GitHub para você começar.

Uma introdução ao CI/CD

Quando se trata de implantação de software, há dois termos importantes a serem entendidos: Integração Contínua (CI) e Entrega Contínua (CD).

Esses dois termos estão intimamente relacionados, tanto que muitas vezes são chamados coletivamente de “CI/CD”, e o caminho pelo qual nossas mudanças fluem torna-se o “pipeline CI/CD”. Esse pipeline geralmente assume o seguinte formato:

1. Construa a versão: instale as dependências (Composer, npm, etc.), então crie artefatos (Webpack, Grunt, Sass, etc.)
2. Teste a compilação: execute testes de unidade, verifique os padrões de codificação, execute a análise estática do código etc.
3. Implantar a versão em um ou mais ambientes

A Integração Contínua é o processo de testar continuamente nosso código para garantir que as alterações não interrompam a funcionalidade existente, para que nossas novas alterações se integrem de maneira limpa à base de código existente. Sempre que novas alterações são enviadas, verificações são executadas para garantir que não estamos “quebrando a compilação”.

Para que a integração contínua seja útil, essas verificações devem ser automatizadas. Por exemplo, se você tiver um conjunto de testes de unidade, poderá optar por executar esse conjunto de testes toda vez que uma nova solicitação pull for aberta, alertando-o sobre possíveis interrupções antes que o código chegue à produção.

No entanto, a integração contínua não se limita a testes de unidade, pois há várias verificações “sem código” que podem ser executadas automaticamente em seu código, incluindo:

• Verificações de padrões de codificação (PHP_CodeSniffer, PHP Coding Standards Fixer)
• Análise de código estático (PHPStan, Salmo)

Executar essas verificações automaticamente em cada push também garante que todo o código seja executado pelas mesmas verificações, evitando que o código que não passa seja liberado.

A Entrega Contínua , por outro lado, é a ideia de que devemos ser capazes de “entregar” (implantar) nosso código a qualquer momento. Para conseguir isso, devemos ter um processo de implantação com script que, com o clique de um botão, mova nosso código para produção sem problemas.

Ter suas implantações com script significa que você pode implantar de forma regular e consistente ; cada implantação deve funcionar da mesma forma que a anterior. Como resultado, sua equipe pode implantar mais regularmente com um nível mais alto de confiança e menos preocupações de que alguém tenha perdido uma etapa ao longo do caminho. Para algumas equipes, não é incomum implantar dezenas (ou até centenas) de vezes por dia!

Dependendo do seu site, você pode até querer olhar para “o outro CD”, Continuous Deployment ; é muito semelhante à entrega contínua, mas nesse modelo cada push para uma ramificação é implantado automaticamente. Isso pode ser extremamente poderoso ao usar um esquema de controle de versão ramificado (como o Github Flow), mas pode ser indesejável se você precisar agendar janelas de lançamento ou fazer todo o trabalho no branch principal.

Implantando um site WordPress ou WooCommerce com CI/CD

Agora que entendemos a terminologia básica, vamos dar uma olhada na implantação de um site WordPress ou WooCommerce típico:

Para este exercício, usaremos o Branch, uma ferramenta de CI/CD projetada em torno das necessidades dos desenvolvedores do WordPress das mesmas pessoas por trás do WP Pusher. O melhor de tudo é que o Branch tem suporte integrado para implantação no Nexcess!

Para começar, inscreva-se no Branch conectando sua conta do GitHub, GitLab ou Bitbucket e criando seu primeiro site.

Em seguida, vamos querer configurar todas as etapas necessárias para construir nosso site. O Branch oferece várias “receitas” para ações comuns (instalar dependências do Composer, executar o Webpack, etc.), mas também nos dá a capacidade de adicionar qualquer número de etapas personalizadas.

Uma vez que delineamos as etapas necessárias para construir nosso site, podemos passar para a próxima etapa do nosso pipeline: testes.

Se você já possui um conjunto de testes automatizados para o seu site, basta dizer ao Branch para executar os comandos necessários. Mesmo que você ainda não tenha testes, o Branch facilita muito a adição de linting, padrões de codificação e verificações de compatibilidade.

Agora que instalamos nossas dependências, construímos tudo e passamos em nossos testes, é hora de colocar nosso código em produção!

Branch contém receitas para implantação no Nexcess (assim como em outros grandes provedores de hospedagem), e conectar as duas plataformas é indolor:

1. Selecione seu site no painel da filial, clique em "Configurações" e pegue a chave SSH pública do site da filial
2. Adicione esta chave pública à lista de chaves no portal Nexcess

Assim que a Branch conseguir se comunicar com seu site Nexcess, podemos selecionar a receita de implantação “Nexcess” e preencher alguns detalhes:

1. O nome do host e o nome de usuário do site (disponível no portal Nexcess na tela "Acesso") do seu site)
2. A raiz da Web na qual estamos implantando. Se nosso repositório git for destinado a servir como o diretório wp-content/, esse valor deve ser “public_html/wp-content”.
3. Os arquivos que desejamos implantar (geralmente o padrão, “*”, é suficiente)
4. A ramificação git a ser implantada neste ambiente

A configuração “Git branch” é especialmente importante, pois permite especificar diferentes implantações para diferentes branches. Por exemplo, você pode ter uma ramificação de “staging” que é implantada em seu ambiente de staging, permitindo que você teste as alterações antes de torná-las ativas.

Vale a pena notar que o Branch usa o modelo de implantação contínua por padrão, em que o pipeline é executado com cada push para o branch especificado. Se você preferir um modelo de entrega contínua (onde alguma ação manual deve ser executada), você pode considerar manter uma ramificação de “produção” que só é mesclada quando você estiver pronto para o lançamento.

Neste ponto, o Branch deve ser configurado para construir e implantar seu repositório git no Nexcess! Você pode acionar sua primeira implantação clicando no botão "Executar implantação" na página "Pipelines" do seu site ou enviando para seu repositório Git.

Personalizando seu processo de liberação

Um dos recursos realmente interessantes do Branch é a capacidade de configurar etapas adicionais após uma implantação bem-sucedida, como limpar automaticamente o cache de objetos do seu site após uma implantação. Isso pode ser feito usando a receita WP-CLI em "Outro".

O host e o nome de usuário geralmente serão os mesmos que usamos na etapa de implantação, e você pode encadear quantos comandos forem necessários.

Conclusão

Se você ainda está lutando com palhaçadas de codificação de caubói e/ou lançamentos cheios de ansiedade, dê uma olhada no Branch e facilite as implantações!