
Vår gjest, utvikleren av verktøy for utviklere fra Pantheon, forklarer hvordan man kan automatisere WordPress-deploys med GitLab CI/CD.
I jeg jobber med relasjoner til utviklere, så jeg leter alltid etter nye måter å hjelpe WordPress- og Drupal-utviklere med å løse problemer med automatisering i arbeidsprosessene. Derfor liker jeg å eksperimentere med nye verktøy og kombinere dem for effektivt arbeid.
Jeg ser ofte at utviklere sliter med én mellomserver.
Det er ikke noe særlig moro å vente på tur for å bruke mellomserveren, eller sende kunder en URL merket: 'Se her, men ikke her ennå'.
— et av de kule verktøyene fra Pantheon — løser dette problemet, fordi de lar deg opprette miljøer for Git-grener ved forespørsel. Hvert multidev-miljø har sin egen URL og database, slik at utviklere kan jobbe i ro og mak, teste kvaliteten og få godkjenning uten å tråkke hverandre på tærne.
Men Pantheon har ikke verktøy for versjonskontroll eller kontinuerlig integrasjon og deploy (CI/CD). Men det er en fleksibel plattform som kan integrere hvilke som helst verktøy.
Jeg har også lagt merke til at team bruker ett sett med verktøy for utvikling, og et annet for bygging og deploy.
For eksempel har de ulike verktøy for versjonskontroll og CI/CD. Man må styre og bytte mellom verktøyene for å redigere koden og diagnostisere problemer.
På det finnes et komplett sett med verktøy for utvikling: for versjonskontroll, billetter, merge-forespørsel, bransjens beste CI/CD pipeline, containerregister og så videre. Jeg har ennå ikke kommet over applikasjoner som har så mye for å styre utviklingsarbeidsflyten.
Jeg elsker automatisering, så jeg har undersøkt hvordan man kan koble Pantheon til GitLab, slik at commits til hovedgrenen på GitLab deployeres til hovedutviklingsmiljøet i Pantheon. Også merge-forespørslene på GitLab kan opprette og deployere koden til multidev-miljøer i Pantheon.
I denne guiden vil jeg vise hvordan man kan sette opp forbindelsen mellom GitLab og Pantheon, og optimalisere arbeidsflyten til WordPress og Drupal.
Man kan selvfølgelig , men vi skal gjøre alt manuelt for å grave litt i og i fremtiden bruke dette verktøyet ikke bare for deploy.
Innledning
For this post, it is important to understand that Pantheon breaks each site into three elements: code, database, and files.
The code includes CMS files, such as the core, plugins, and WordPress themes. These files are managed in , hosted by Pantheon, meaning we can deploy code from GitLab to Pantheon using Git.
Files in Pantheon refer to media files, meaning images for the site. They are usually uploaded by users, and Git ignores them.
, learn more about eller at pantheon.io.
Assumptions
My project on Pantheon and GitLab is called pantheon-gitlab-blog-demo. The project name must be unique. Here we will work with a WordPress site. We could also use Drupal, but some adjustments will be needed.
I will use , but you can work in , if you prefer.
Creating a project
First, we create a (we'll get back to this).
Now . Then we install WordPress for the site dashboard.
If you are itching to make changes, such as removing or adding plugins, hold off. The site is not yet connected to GitLab, and we want all code changes to go through GitLab.
Once we install WordPress, we return to the Pantheon site dashboard and switch the development mode to Git.
Initial commit on GitLab
Now we need to transfer the initial WordPress code from the Pantheon site to GitLab. To do this, we clone the code from the Git repository of the Pantheon site locally, and then push it to the GitLab repository.
To make it easier and safer, so we won't have to enter a password every time we clone the Pantheon Git repository. At the same time, we already .
To do this, we clone the Pantheon site locally, copying the command from the Clone with Git section on the site dashboard.
If you need help, refer to the .
Now let's change git remote origin, to point to GitLab instead of Pantheon. This can be done .
Let's go to the GitLab project and copy the repository URL from the Clone dropdown menu on the project details page. We will choose the Clone with SSH option, since we have already set up the SSH key.
Som standard git remote for the local copy of the code repository is origin. This can be changed with git remote set-url origin [GitLab repository URL], where we replace the brackets with the actual URL.
Finally, we run git push origin master --force, for å sende WordPress-koden fra Pantheon-nettstedet til GitLab.
Parameteren –force kreves bare én gang. Deretter i kommandoene
git pushpå GitLab vil den ikke være der.
Setter opp legitimasjon og variabler
Husker du hvordan vi lokalt la til SSH-nøkkelen for å autentisere mot Pantheon og GitLab? SSH-token kan brukes for autentisering mot GitLab og Pantheon.
GitLab har utmerket dokumentasjon. La oss se på .
Nå skal vi gjennomføre de to første trinnene: vi skal opprette et nytt SSH-nøkkelpar lokalt med ssh-keygen og legge til den private nøkkelen som en variabel i prosjektet..
Deretter setter vi SSH_PRIVATE_KEY som i prosjektsinnstillingene.
I det tredje og fjerde trinnet oppretter vi en fil .gitlab-ci.yml med følgende innhold:
before_script:
# Se 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"La oss ikke commite filen ennå .gitlab-ci.yml, senere må vi legge til noe mer i den.
Nå utfører vi det femte trinnet og legger til den offentlige nøkkelen vi opprettet i første trinn til tjenestene som du trenger tilgang til i byggeomgivelsene..
I vårt tilfelle ønsker vi å få tilgang til Pantheon fra GitLab. Følg instruksene i Pantheon-dokumentasjonen om og fullfør dette trinnet.
Husk: den private SSH-nøkkelen er i GitLab, den offentlige nøkkelen er i Pantheon.
La oss konfigurere noen flere miljøvariabler. Den første heter PANTHEON_SITE. Verdien er navnet på Pantheon-nettstedet ditt på maskinen.
Navnet på maskinen er angitt på slutten av Clone with Git-kommandoen. Du har allerede klonet nettstedet lokalt, så dette vil være navnet på katalogen til det lokale depotet.
Videre setter vi opp miljøvariabelen PANTHEON_GIT_URL. Dette er Git-repositoriet for Pantheon-nettstedet, som vi allerede har brukt.
Vi skriver bare URL-en til SSH-repositoriet, uten
git cloneog navnet på nettstedet på maskinen i slutten.
Puh. Det er gjort, nå kan vi avslutte filen vår. .gitlab-ci.yml.
Vi lager en deploymentsoppgave.
Det vi først skal gjøre med GitLab CI, ligner veldig på det vi gjorde med Git-repositoriene tidligere. Men denne gangen legger vi til Pantheon-repositoriet som en annen ekstern Git-kilde, og deretter sender vi koden fra GitLab til Pantheon.
For dette setter vi opp deploy og deploy:dev, siden vi skal deploye til utviklingsmiljøet på Pantheon. Som et resultat vil filen .gitlab-ci.yml se slik ut:
steg:
- distribuera
förberedelse_script:
# Se 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"
distribuera:dev:
steg: distribuera
miljö:
namn: dev
url: https://dev-$PANTHEON_SITE.pantheonsite.io/
script:
- git remote add pantheon $PANTHEON_GIT_URL
- git push pantheon master --force
endast:
- masterVariabler SSH_PRIVATE_KEY, PANTHEON_SITE og PANTHEON_GIT_URL ska se bekanta ut – vi har ställt in dessa miljövariabler tidigare. Med dessa variabler kan vi använda värdena i filen .gitlab-ci.yml flera gånger, och uppdatera dem behöver vi bara göra på ett ställe.
Till sist, låt oss lägga till, kommitta och skicka filen .gitlab-ci.yml till GitLab.
Vi kontrollerar distributionen
Om vi har gjort allt rätt kommer uppgiften deploy:dev att köras framgångsrikt i GitLab CI/CD och skicka kommittén .gitlab-ci.yml till Pantheon. Låt oss ta en titt.
Vi skickar grenar av merge-förfrågningar till Pantheon
Här kommer vi använda min favoritfunktion på Pantheon – , där man kan skapa ytterligare Pantheon-miljöer för Git-grenar på begäran.
, så detta avsnitt behöver man kanske inte utföra. Men om du har tillgång kan du avsevärt öka produktiviteten genom att ställa in automatisk skapande av multidev-miljöer på Pantheon från GitLab-mmerge-förfrågningar.
Först gör vi en ny Git-gren lokalt med hjälp av git checkout -b multidev-support. Nu gör vi några ändringar igen i .gitlab-ci.yml.
Jag gillar att ange numret på merge-förfrågan i namnet på Pantheon-miljön. Till exempel, den första merge-förfrågan – mr-1, den andra – mr-2 och så vidare.
Merge-förfrågan förändras, så vi behöver dynamiskt bestämma namnen på grenarna i Pantheon. På GitLab är det enkelt – man måste använda .
Vi kan ta $CI_MERGE_REQUEST_IID, för att ange numret på merge-förfrågan. Låt oss få allt detta att fungera tillsammans med de globala miljövariabler som vi angav tidigare, och lägga till en ny uppgift deploy:multidev i slutet av filen .gitlab-ci.yml.
deploy:multidev:
steg: distribuera
miljö:
namn: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Checka ut källa-grenen för merge-förfrågan
- git checkout $CI_COMMIT_REF_NAME
# Lägg till Pantheon git-repository som en extra fjärrförbindelse
- git remote add pantheon $PANTHEON_GIT_URL
# Skicka merge-förfrågan källa-gren till Pantheon
- git push pantheon $CI_COMMIT_REF_NAME:mr-$CI_MERGE_REQUEST_IID --force
endast:
- merge_requestsDet kommer att likna vår uppgift deploy:dev, endast grenen skickas till Pantheon istället för master.
Vi har lagt till och kommittat den uppdaterade filen .gitlab-ci.yml, och nu ska vi skicka den nya grenen till GitLab med git push -u origin multidev-support.
La oss nå opprette en ny merge request fra grenen multidev-support, ved å klikke på Opprett merge request.
Når vi har opprettet merge request, ser vi hvordan CI/CD-oppgaven utføres deploy:multidev.
Se—en ny gren er sendt til Pantheon. Men hvis vi går til multidev-delen på dashboardet for nettstedet på Pantheon, vil vi ikke se noen ny miljø der
La oss se på delen Git Branches.
Til slutt har grenen vår mr-1 kommet til Pantheon. La oss opprette et miljø fra grenen mr-1.
Vi har opprettet multidev-miljøet, nå går vi tilbake til GitLab og ser på delen Operations > Environments. Vi vil se oppføringer for dev og mr-1.
Dette er fordi vi la til en oppføring miljø med navnet name og url i CI/CD-oppgavene. Hvis vi klikker på ikonet for det åpne miljøet, vil vi gå til URL-en for multidev-miljøet på Pantheon.
La oss automatisere opprettelsen av multidev
I prinsippet kan vi stoppe her og bare huske å opprette et multidev-miljø for hver merge request, men denne prosessen kan automatiseres.
I Pantheon er det et kommandolinjeverktøy , hvor vi kan jobbe med plattformen automatisk. I Terminus kan vi opprette multidev-miljøer fra kommandolinjen— perfekt for .
Vi trenger en ny merge request for å teste dette. La oss opprette en ny gren med git checkout -b auto-multidev-creation.
For å bruke Terminus i GitLab CI/CD-oppgavene, trenger vi en maskintoken for autentisering i Terminus og et containerbilde med Terminus.
, lagrer den på et sikkert sted og legger den til som en global miljøvariabel i GitLab med navnet PANTHEON_MACHINE_TOKEN.
Hvis du har glemt hvordan du legger til GitLab-miljøvariabler, gå tilbake til der vi definerte
PANTHEON_SITE.
Vi oppretter en Dockerfile med Terminus
Hvis du ikke bruker Docker eller ikke er så glad i filer Dockerfile, ta bildet mitt registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest og hopp over dette avsnittet.
, hvor du kan bygge og laste opp Dockerfile for prosjektet vårt. La oss opprette en Dockerfile med Terminus for å jobbe med Pantheon.
Terminus er et kommandolinjeverktøy i PHP, så la oss starte med PHP-bildet. Jeg installerer Terminus via Composer, så jeg tar utgangspunkt i . Vi oppretter Dockerfile i katalogen for det lokale depotet med følgende innhold:
# 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"Følg instruksjonene for å bygge og sende bilder fra avsnittet Bygg og last opp bilder i , for å bygge bildet fra Dockerfile og sende det til GitLab.
Åpne delen Registry i GitLab-prosjektet. Hvis alt har gått etter planen, vil bildet vårt være der. Noter deg linken til bilde-taggen— den trenger vi for filen .gitlab-ci.yml.
Seksjon script i oppgåva deploy:multidev begynner å vokse, så la oss flytte den til en egen fil. Vi oppretter en ny fil 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..."
fiSkriptet ligger i en privat katalog og . Vi har et skript for vår multidev-logikk. La oss nå oppdatere delen deploy:multidev av filen .gitlab-ci.yml, slik at det blir slik:
deploy:multidev:
stage: deploy
environment:
name: multidev/mr-$CI_MERGE_REQUEST_IID
url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
script:
# Kjør multidev distribusjonsskriptet
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsVi må forsikre oss om at oppgavene våre kjøres i det opprettede tilpassede bildet, så vi legger til definisjonen image for registrerings-URL-en i .gitlab-ci.yml. Til slutt har vi fått en slik fil .gitlab-ci.yml:
image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest
stages:
- deploy
before_script:
# Se 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:
# Kjør multidev distribusjonsskriptet
- "/bin/bash ./private/multidev-deploy.sh"
only:
- merge_requestsVi legger til, kommitterer og sender private/multidev-deploy.sh og .gitlab-ci.yml. Nå går vi tilbake til GitLab og venter på at CI/CD-oppgaven skal fullføres. Ha tålmodighet: multidev kan ta flere minutter å opprette.
Deretter går vi for å se listen over multidev på Pantheon. Å, mirakler! Multidev-miljøet mr-2 er allerede her.
Konklusjon
Teamet mitt fikk mye mer glede når vi begynte å åpne merge requests og opprette miljøer automatisk.
Med de kraftige verktøyene fra GitLab og Pantheon kan du automatisk koble GitLab til Pantheon.
Siden vi bruker GitLab CI/CD, har arbeidsflyten vår mye rom for vekst. Her er noen ideer for å komme i gang:
- Legg til en byggetrinn.
- Legg til automatisert testing.
- Legg til en oppgave for å sikre at kode-standarder følges.
- Legg til .
Skriv hva du mener om GitLab, Pantheon og automatisering.
P.S. Visste du at Terminus, Pantheons kommandolinjeverktøy, ?
Vi i Pantheon har jobbet hardt med versjon 2 av vår med støtte for GitLab. Hvis du ikke vil bruke tid på oppsett for hvert prosjekt, prøv dette pluginet og hjelp oss med å teste beta v2. For Terminus-teamet build:project:create du trenger bare Pantheon-tokenet og GitLab-tokenet. Det vil sette opp et av eksempelprosjektene med Composer og automatisk testing, opprette et nytt prosjekt i GitLab, en ny nettside på Pantheon, og koble dem sammen med miljøvariabler og SSH-nøkler.
Om forfatteren
Andrew Taylor lager verktøy for utviklere i .
Kilde: habr.com
