Nosso convidado, criador de ferramentas para desenvolvedores da Pantheon, fala sobre como automatizar implantações do WordPress com o GitLab CI/CD.
Em Eu trabalho com relações com desenvolvedores, então estou sempre em busca de novas maneiras de ajudar os desenvolvedores de WordPress e Drupal a resolver problemas de automação nos fluxos de trabalho. Para isso, adoro experimentar novas ferramentas e combiná-las para uma eficiência maior.
Vejo frequentemente desenvolvedores lutando com um servidor intermediário.
Não é uma experiência agradável esperar a sua vez de usar o servidor intermediário ou enviar aos clientes uma URL com a anotação: 'Aqui é onde você deve olhar, e aqui não deve olhar ainda'.
— uma das ótimas ferramentas da Pantheon — resolve esse problema, pois é possível criar ambientes sob ramos do Git sob demanda. Cada ambiente multidev tem sua própria URL e banco de dados, permitindo que os desenvolvedores trabalhem tranquilamente, verifiquem a qualidade e obtenham aprovação, sem pisarem nos pés uns dos outros.
Mas na Pantheon não há ferramentas para controle de versões ou integração e implantação contínuas (CI/CD). Em vez disso, é uma plataforma flexível que permite integrar qualquer ferramenta.
Ainda percebi que, para desenvolvimento, as equipes usam um conjunto de ferramentas, e para compilar e implantar, utilizam outras.
Por exemplo, eles têm ferramentas diferentes para controle de versões e CI/CD. É necessário se aventurar e alternar entre ferramentas para editar código e diagnosticar problemas.
Sobre Há um conjunto completo de ferramentas de desenvolvimento: para controle de versões, tickets, solicitações de mesclagem, um pipeline CI/CD de primeira linha, repositório de contêineres e tudo mais. Até agora, não encontrei aplicativos que ofereçam tanto para gerenciar o fluxo de trabalho de desenvolvimento.
Eu amo automação, então estudei como conectar a Pantheon ao GitLab, para que os commits na branch principal do GitLab fossem implantados no ambiente de desenvolvimento principal da Pantheon. Além disso, solicitações de mesclagem no GitLab podem criar e implantar código em ambientes multidev na Pantheon.
Neste guia, vou mostrar como configurar a conexão entre o GitLab e a Pantheon e otimizar o fluxo de trabalho do WordPress e Drupal.
Claro que podemos , mas faremos tudo manualmente para explorar o e no futuro utilizar essa ferramenta não apenas para implantações.
Introdução
Para entender este post, é necessário saber que Pantheon divide cada site em três elementos: código, banco de dados e arquivos.
O código inclui arquivos CMS, como o núcleo, plugins e temas do WordPress. Esses arquivos são gerenciados em , hospedado no Pantheon, ou seja, podemos fazer o deploy do código do GitLab para o Pantheon usando o Git.
Arquivos no Pantheon referem-se a arquivos de mídia, como imagens para o site. Geralmente, eles são enviados pelos usuários, e o Git os ignora.
, descubra mais sobre ou em pantheon.io.
Suposições
Meu projeto no Pantheon e GitLab se chama pantheon-gitlab-blog-demo. O nome do projeto deve ser único. Aqui trabalharemos com um site WordPress. Podemos usar o Drupal também, mas serão necessárias algumas modificações.
Vou usar , mas você pode trabalhar na , se preferir.
Criamos o projeto
Primeiro, vamos criar (ainda falaremos sobre isso).
Agora, . Depois, instalaremos o WordPress para o painel do site.
Se você está ansioso para fazer alterações, como remover e adicionar plugins, aguarde um pouco. O site ainda não está conectado ao GitLab, e queremos que todas as alterações de código passem pelo GitLab.
Depois de instalar o WordPress, voltamos ao painel do site Pantheon e mudamos o modo de desenvolvimento para Git.
O commit inicial no GitLab
Agora precisamos transferir o código inicial do WordPress do Pantheon para o GitLab. Para isso, clonamos o código do repositório Git do site Pantheon localmente e depois o enviamos ao repositório GitLab.
Para facilitar e aumentar a segurança, e não teremos que digitar a senha toda vez que clonarmos o repositório Git do Pantheon. Aproveitamos e .
Para isso, clonamos o site Pantheon localmente, copiando o comando do campo Clone with Git do painel do site.
Se precisar de ajuda, consulte a documentação .
Agora vamos modificar git remote origin, para apontar para o GitLab em vez do Pantheon. Isso pode ser feito com .
Vamos para o projeto GitLab e copiamos a URL do repositório no menu suspenso Clone na página de detalhes do projeto. Selecionamos a opção Clone with SSH, pois já configuramos a chave SSH.
Por padrão git remote para a cópia local do repositório do código — origin. Isso pode ser alterado com git remote set-url origin [URL do repositório GitLab], onde, em vez de colchetes, inserimos a URL real.
Por fim, executamos git push origin master --force, para enviar o código do WordPress do site Pantheon para o GitLab.
O parâmetro –force deve ser usado somente uma vez. Depois, nas comandos
git pushnão estará no GitLab.
Configurando as credenciais e variáveis
Lembra como adicionamos a chave SSH localmente para nos autorizar no Pantheon e no GitLab? O token SSH pode ser usado para autorização no GitLab e no Pantheon.
O GitLab possui uma ótima documentação. Vamos dar uma olhada .
Agora vamos completar os primeiros dois passos: vamos criar um novo par de chaves SSH localmente com ssh-keygen e adicionar a chave privada como variável no projeto.
Depois, definiremos SSH_PRIVATE_KEY como nas configurações do projeto.
No terceiro e quarto passos, criaremos o arquivo .gitlab-ci.yml com o seguinte conteúdo:
before_script:
# Veja https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add > /dev/null
- mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
- git config --global user.email "$GITLAB_USER_EMAIL"
- git config --global user.name "Gitlab CI"Por enquanto, não vamos cometer o arquivo .gitlab-ci.yml, pois será necessário adicionar mais algumas coisas depois.
Agora, vamos executar o quinto passo e adicionar a chave pública, que criamos no primeiro passo, aos serviços que você precisa de acesso no ambiente de construção.
Neste caso, queremos acessar o Pantheon a partir do GitLab. Vamos seguir as instruções no documento Pantheon sobre e vamos realizar este passo.
Lembre-se: a chave SSH privada fica no GitLab, a pública vai para o Pantheon.
Vamos configurar mais algumas variáveis de ambiente. A primeira é chamada PANTHEON_SITE. O valor dela é o nome do site Pantheon na sua máquina.
O nome na máquina aparece no final do comando Clone with Git. Você já clonou o site localmente, então isso será o nome do diretório do repositório local.
Depois, vamos configurar a variável de ambiente PANTHEON_GIT_URL. Este é o URL do repositório Git para o site Pantheon que já usamos.
Vamos inserir apenas a URL do repositório SSH, sem
git clonee sem o nome do site na máquina no final.
Ufa. Isso foi feito, agora podemos concluir nosso arquivo .gitlab-ci.yml.
Vamos criar a tarefa de deployment
O que iremos fazer inicialmente com o GitLab CI é muito parecido com o que fizemos antes com repositórios Git. Mas desta vez, adicionaremos o repositório Pantheon como uma segunda origem remota do Git e, em seguida, enviaremos o código do GitLab para o Pantheon.
Para isso, vamos configurar deploy e deploy:dev, pois estaremos fazendo o deployment no ambiente de desenvolvimento no Pantheon. Como resultado, o arquivo .gitlab-ci.yml ficará assim:
estágios:
- implantar
antes_script:
# Veja https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add > /dev/null
- mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
- git config --global user.email "$GITLAB_USER_EMAIL"
- git config --global user.name "Gitlab CI"
implantar:dev:
estágio: implantar
ambiente:
nome: dev
url: https://dev-$PANTHEON_SITE.pantheonsite.io/
script:
- git remote add pantheon $PANTHEON_GIT_URL
- git push pantheon master --force
apenas:
- masterVariáveis SSH_PRIVATE_KEY, PANTHEON_SITE e PANTHEON_GIT_URL devem parecer familiares — configuramos essas variáveis de ambiente antes. Com essas variáveis, poderemos usar os valores no arquivo .gitlab-ci.yml várias vezes, e a atualização delas precisará ser feita apenas em um só lugar.
Finalmente, vamos adicionar, comitar e enviar o arquivo .gitlab-ci.yml para o GitLab.
Verificando a implantação
Se fizemos tudo certo, a tarefa deploy:dev será concluída com sucesso no GitLab CI/CD e enviará o commit .gitlab-ci.yml para o Pantheon. Vamos dar uma olhada.
Enviando branches de merge requests para o Pantheon
Aqui vamos usar minha função favorita do Pantheon — , onde é possível criar ambientes adicionais do Pantheon para branches Git sob demanda.
, então esta seção pode ser ignorada. Mas se você tiver acesso, pode aumentar significativamente a eficiência configurando a criação automática de ambientes multidev no Pantheon a partir de merge requests do GitLab.
Primeiro, vamos criar uma nova branch Git localmente usando git checkout -b multidev-support. Agora, vamos fazer algumas alterações novamente em .gitlab-ci.yml.
Eu gosto de incluir o número do merge request no nome do ambiente Pantheon. Por exemplo, o primeiro merge request — mr-1, o segundo — mr-2 e assim por diante.
O número do merge request muda, então precisamos determinar dinamicamente os nomes das branches do Pantheon. No GitLab, isso é simples — precisamos usar .
Podemos usar $CI_MERGE_REQUEST_IID, para indicar o número de merge request. Vamos aplicar tudo isso junto com as variáveis de ambiente globais que definimos anteriormente e adicionar uma nova tarefa deploy:multidev no final do arquivo .gitlab-ci.yml.
implantar:multidev:
estágio: implantar
ambiente:
nome: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Checkout da branch de origem do merge request
- git checkout $CI_COMMIT_REF_NAME
# Adiciona o repositório git do Pantheon como um remote adicional
- git remote add pantheon $PANTHEON_GIT_URL
# Push da branch de origem do merge request para o Pantheon
- git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
apenas:
- merge_requestsVai se parecer com nossa tarefa deploy:dev, apenas a branch será enviada ao Pantheon, em vez de master.
Adicionamos e comitamos o arquivo atualizado .gitlab-ci.yml, agora vamos enviar a nova branch para o GitLab com git push -u origin multidev-support.
Agora, vamos criar uma nova solicitação de merge a partir do branch multidev-support, clicando em Criar solicitação de merge.
Após criar a solicitação de merge, vamos verificar como a tarefa CI/CD está se desenvolvendo deploy:multidev.
Veja — um novo branch foi enviado para o Pantheon. Mas se formos para a seção multidev no painel do site no Pantheon, não veremos o novo ambiente lá
Vamos conferir a seção Git Branches.
No final, nosso branch mr-1 chegou ao Pantheon. Vamos criar um ambiente a partir do branch mr-1.
Criamos um ambiente multidev, agora vamos voltar para o GitLab e olhar a seção Operations > Environments. Vamos ver registros para dev e mr-1.
Isso é porque adicionamos um registro environment com o nome nome e url nas tarefas CI/CD. Se clicarmos no ícone do ambiente aberto, seremos levados ao URL do ambiente multidev no Pantheon.
Automatizando a criação do multidev
Basicamente, podemos parar por aqui e simplesmente não esquecer de criar um ambiente multidev para cada solicitação de merge, mas esse processo pode ser automatizado.
No Pantheon, há uma ferramenta de linha de comando , onde podemos interagir com a plataforma de forma automática. No Terminus, é possível criar ambientes multidev a partir da linha de comando — perfeito para .
Precisamos de uma nova solicitação de merge para testar isso. Vamos criar um novo branch usando git checkout -b auto-multidev-creation.
Para usar o Terminus nas tarefas do GitLab CI/CD, é necessário um token de máquina para autenticação no Terminus e uma imagem de contêiner com o Terminus.
, salvando-o em um lugar seguro e adicionando como uma variável de ambiente global no GitLab com o nome PANTHEON_MACHINE_TOKEN.
Se você esqueceu como adicionar variáveis de ambiente no GitLab, volte para onde definimos
PANTHEON_SITE.
Criando um Dockerfile com o Terminus
Se você não estiver usando Docker ou não gostar de arquivos Dockerfile, pegue minha imagem registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest e pule esta parte.
, onde você pode compilar e armazenar o Dockerfile para o nosso projeto. Vamos criar um arquivo Dockerfile com o Terminus para trabalhar com o Pantheon.
O Terminus é uma ferramenta de linha de comando em PHP, então vamos começar com uma imagem PHP. Estou instalando o Terminus via Composer, então vou usar . Criamos Dockerfile no diretório do repositório local com o seguinte conteúdo:
# Use the official Composer image as a parent image
FROM composer:1.8
# Update/upgrade apk
RUN apk update
RUN apk upgrade
# Make the Terminus directory
RUN mkdir -p /usr/local/share/terminus
# Install Terminus 2.x with Composer
RUN /usr/bin/env COMPOSER_BIN_DIR=/usr/local/bin composer -n --working-dir=/usr/local/share/terminus require pantheon-systems/terminus:"^2"Siga as instruções para compilar e enviar imagens na seção Build and push images em , para compilar a imagem de Dockerfile e enviá-la ao GitLab.
Abrimos a seção Registry no projeto GitLab. Se tudo correr conforme o planejado, lá estará nossa imagem. Anote o link para o tag da imagem — isso será necessário para o arquivo .gitlab-ci.yml.
Seção script na tarefa deploy:multidev começa a crescer, então vamos movê-lo para um arquivo separado. Criamos um novo arquivo private/multidev-deploy.sh:
#!/bin/bash
# Store the mr- environment name
export PANTHEON_ENV=mr-$CI_MERGE_REQUEST_IID
# Authenticate with Terminus
terminus auth:login --machine-token=$PANTHEON_MACHINE_TOKEN
# Checkout the merge request source branch
git checkout $CI_COMMIT_REF_NAME
# Add the Pantheon Git repository as an additional remote
git remote add pantheon $PANTHEON_GIT_URL
# Push the merge request source branch to Pantheon
git push pantheon $CI_COMMIT_REF_NAME:$PANTHEON_ENV --force
# Create a function for determining if a multidev exists
TERMINUS_DOES_MULTIDEV_EXIST()
{
# Stash a list of Pantheon multidev environments
PANTHEON_MULTIDEV_LIST="$(terminus multidev:list ${PANTHEON_SITE} --format=list --field=id)"
while read -r multiDev; do
if [[ "${multiDev}" == "$1" ]]
then
return 0;
fi
done <<< "$PANTHEON_MULTIDEV_LIST"
return 1;
}
# If the mutltidev doesn't exist
if ! TERMINUS_DOES_MULTIDEV_EXIST $PANTHEON_ENV
then
# Create it with Terminus
echo "No multidev for $PANTHEON_ENV found, creating one..."
terminus multidev:create $PANTHEON_SITE.dev $PANTHEON_ENV
else
echo "The multidev $PANTHEON_ENV already exists, skipping creating it..."
fiO script está no diretório privado e . Temos um script para nossa lógica de multidev. Agora vamos atualizar a seção deploy:multidev do arquivo .gitlab-ci.yml, para que fique assim:
deploy:multidev:
stage: deploy
environment:
name: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Execute o script de deploy multidev
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsPrecisamos garantir que nossas tarefas sejam executadas na imagem personalizada criada, então vamos adicionar a definição image com a URL do registro em .gitlab-ci.yml. No final, temos um arquivo assim .gitlab-ci.yml:
image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest
stages:
- deploy
before_script:
# Veja https://docs.gitlab.com/ee/ci/ssh_keys/README.html
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | tr -d 'r' | ssh-add - > /dev/null
- mkdir -p $HOME/.ssh && echo "StrictHostKeyChecking no" >> "$HOME/.ssh/config"
- git config --global user.email "$GITLAB_USER_EMAIL"
- git config --global user.name "Gitlab CI"
deploy:dev:
stage: deploy
environment:
name: dev
url: https://dev-$PANTHEON_SITE.pantheonsite.io/
script:
- git remote add pantheon $PANTHEON_GIT_URL
- git push pantheon master --force
only:
- master
deploy:multidev:
stage: deploy
environment:
name: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Execute o script de deploy multidev
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsAdicionamos, comitamos e enviamos private/multidev-deploy.sh e .gitlab-ci.yml. Agora voltamos para o GitLab e aguardamos a execução da tarefa CI/CD. Aguarde: o multidev pode levar alguns minutos para ser criado.
Depois, vamos ver a lista de multidev no Pantheon. Oh, maravilha! O ambiente multidev mr-2 já está aqui.
Conclusão
Minha equipe se divertiu muito mais quando começamos a abrir merge requests e criar ambientes automaticamente.
Com as poderosas ferramentas do GitLab e Pantheon, você pode conectar o GitLab ao Pantheon automaticamente.
Como estamos usando GitLab CI/CD, nosso fluxo de trabalho terá muito a crescer. Aqui estão algumas ideias para começar:
- Adicione uma etapa de build.
- Adicione testes automatizados.
- Adicione uma tarefa para garantir a conformidade com os padrões de código.
- Adicione .
Escreva o que você pensa sobre GitLab, Pantheon e automação.
P.S. Você sabia que o Terminus, a ferramenta de linha de comando do Pantheon, ?
Trabalhamos duro na Pantheon para a versão 2 do nosso com suporte ao GitLab. Se você não quer se preocupar em configurar para cada projeto, experimente este plugin e nos ajude a testar a beta v2. Para a equipe Terminus build:project:create apenas precisa do token Pantheon e do token GitLab. Ele irá implantar um dos exemplos de projeto com Composer e testes automáticos, criar um novo projeto no GitLab, um novo site no Pantheon e conectá-los com variáveis de ambiente e chaves SSH.
Sobre o autor
Andrew Taylor cria ferramentas para desenvolvedores em .
Fonte: habr.com
