Cum să conectați GitLab și Pantheon și să optimizați fluxurile de lucru Drupal și WordPress

Creatorul nostru invitat de instrumente pentru dezvoltatori de la Pantheon vorbește despre cum să automatizezi implementările WordPress folosind GitLab CI/CD.

В Panteon Lucrez în relații cu dezvoltatorii, așa că caut mereu noi modalități de a ajuta dezvoltatorii WordPress și Drupal să rezolve problemele de automatizare în fluxurile lor de lucru. Pentru a face acest lucru, îmi place să experimentez cu noi instrumente și să le combin unele cu altele pentru a funcționa eficient.

Văd adesea dezvoltatori care se luptă cu un singur server de procesare.

Este o plăcere să aștepți rândul tău să folosești un server intermediar sau să trimiți clienților o adresă URL cu nota: „Uită-te aici, dar nu te uita aici încă”.

Medii multidev - unul dintre instrumentele cool Pantheon - rezolvă această problemă, deoarece cu ele puteți crea medii pentru ramurile Git la cerere. Fiecare mediu multidev are propria adresă URL și bază de date, astfel încât dezvoltatorii pot lucra în liniște, pot verifica calitatea și pot obține aprobare fără a se călca unul pe celălalt.

Dar Pantheon nu are instrumente pentru controlul versiunilor sau integrarea și implementarea continuă (CI/CD). Dar este o platformă flexibilă cu care poți integra orice instrumente.

De asemenea, am observat că echipele folosesc anumite instrumente pentru dezvoltare și altele diferite pentru asamblare și implementare.

De exemplu, au instrumente diferite pentru controlul versiunilor și CI/CD. Trebuie să vă jucați și să comutați între instrumente pentru a edita codul și a diagnostica problemele.

Pe GitLab există un set complet de instrumente de dezvoltare: pentru controlul versiunilor, tichete, solicitări de îmbinare, o conductă CI/CD de cea mai bună calitate, un registru de containere și toate astea. Nu am întâlnit încă o aplicație care să ofere atât de multe pentru a vă gestiona fluxul de lucru de dezvoltare.

Îmi place automatizarea, așa că am învățat cum să conectez Pantheon la GitLab, astfel încât angajamentele către ramura principală pe GitLab să fie implementate în mediul principal de dezvoltare din Pantheon. Iar solicitările de îmbinare pe GitLab pot crea și implementa cod în medii multidev din Pantheon.

În acest tutorial, vă voi prezenta cum să configurați o conexiune între GitLab și Pantheon și să vă optimizați fluxul de lucru WordPress și Drupal.

Desigur, este posibil, oglindă depozitul GitLab, dar vom face totul cu mâinile noastre pentru a ne adânci GitLab CI iar în viitor utilizați acest instrument nu numai pentru implementare.

Introducere

Pentru această postare, trebuie să înțelegeți că Pantheon descompune fiecare site în trei elemente: cod, bază de date și fișiere.

Codul include fișiere CMS, cum ar fi nucleul WordPress, pluginuri și teme. Aceste fișiere sunt gestionate în Arhivele Git, găzduit de Pantheon, ceea ce înseamnă că putem implementa cod din GitLab în Pantheon cu Git.
Fișierele din Pantheon sunt fișiere media, adică imagini pentru site. De obicei, acestea sunt încărcate de utilizatori și Git le ignoră.

Creaza un cont gratuit, afla mai multe despre Fluxul de lucru Pantheon sau înscrieți-vă pentru un demo la pantheon.io.

Ipoteze

Proiectul meu pe Pantheon și GitLab se numește pantheon-gitlab-blog-demo. Numele proiectului trebuie să fie unic. Aici vom lucra cu un site WordPress. Puteți lua Drupal, dar va trebui să schimbați unele lucruri.

voi folosi Linia de comandă Gitși poți lucra în interfata grafica, dacă dorești.

Creați un proiect

Mai întâi, să creăm Proiectul GitLab (vom reveni la asta mai târziu).

acum crearea unui site web WordPress pe Pantheon. Apoi instalăm WordPress pentru tabloul de bord al site-ului.

Dacă mâinile vă mâncărim să schimbați ceva, de exemplu, să eliminați sau să adăugați pluginuri, aveți răbdare. Site-ul nu este încă conectat la GitLab și dorim ca toate modificările codului să treacă prin GitLab.

Odată ce instalăm WordPress, reveniți la tabloul de bord al site-ului Pantheon și schimbați modul de dezvoltare la Git.

Comitarea inițială pe GitLab

Acum trebuie să transferați codul WordPress inițial de pe site-ul Pantheon în GitLab. Pentru a face acest lucru, clonăm local codul din depozitul Git al site-ului Pantheon, apoi îl trimitem la depozitul GitLab.

Pentru a fi mai ușor și mai sigur, adăugați o cheie SSH la Pantheon și nu va trebui să introducem o parolă de fiecare dată când clonăm un depozit Pantheon Git. În același timp deja adăugați o cheie SSH la GitLab.

Pentru a face acest lucru, clonează site-ul web Pantheon local prin copierea comenzii din câmpul Clonează cu Git de pe tabloul de bord al site-ului.

Dacă aveți nevoie de ajutor, citiți documentația începerea cu Git pentru Pantheon.

Acum să ne schimbăm git remote originpentru a indica GitLab în loc de Pantheon. Poate fi realizat командой git remote.

Să mergem la proiectul GitLab și să copiem adresa URL a depozitului din meniul derulant Clonare de pe pagina cu detaliile proiectului. Să alegem opțiunea Clonează cu SSH, pentru că am configurat deja cheia SSH.

În mod implicit git remote pentru o copie locală a depozitului de coduri - origin. Acest lucru poate fi schimbat c git remote set-url origin [URL репозитория GitLab], unde în loc de paranteze introducem adresa URL reală.

În sfârșit, lansăm git push origin master --forcepentru a împinge codul WordPress de la Pantheon în GitLab.

Opțiunea –force este necesară o singură dată. Apoi în echipe git push nu va fi pe GitLab.

Configurarea acreditărilor și variabilelor

Vă amintiți cum am adăugat o cheie SSH local pentru a vă conecta la Pantheon și GitLab? Tokenul SSH poate fi folosit pentru a autoriza GitLab și Pantheon.

GitLab are o documentație excelentă. Să vedem secțiune despre cheile SSH atunci când utilizați executorul Docker din documentul despre utilizarea cheilor SSH cu GitLab CI/CD.

Acum vom parcurge primii doi pași: Să creăm o nouă pereche de chei SSH local cu ssh-keygen și să adăugăm cheia privată ca variabilă la proiect.

Atunci o să întrebăm SSH_PRIVATE_KEY ca Variabila de mediu GitLab CI/CD în setările proiectului.
În al treilea și al patrulea pas vom crea un fișier .gitlab-ci.yml cu conținut ca acesta:

before_script:
  # See 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"

Să nu comitem încă fișierul .gitlab-ci.yml, atunci va trebui să adăugați altceva.

Acum efectuăm al cincilea pas și adăugați cheia publică pe care ați creat-o în primul pas la serviciile la care aveți nevoie de acces în mediul de construcție.

În cazul nostru, dorim să accesăm Pantheon din GitLab. Urmăm instrucțiunile din documentul Pantheon pe adăugarea unei chei SSH la Pantheon și efectuați acest pas.

Rețineți: SSH privat este în GitLab, SSH deschis este în Pantheon.

Să mai setăm câteva variabile de mediu. Primul se numește PANTHEON_SITE. Valoarea sa este numele site-ului Pantheon de pe mașina dvs.

Numele de pe mașină este listat la sfârșitul comenzii Clone with Git. Ați clonat deja site-ul local, așa că acesta va fi numele directorului de depozit local.

Apoi, să setăm variabila de mediu PANTHEON_GIT_URL. Aceasta este adresa URL a depozitului Git pentru site-ul Pantheon pe care l-am folosit deja.

Introduceți numai adresa URL a depozitului SSH, fără git clone și numele site-ului de pe mașină la sfârșit.

Uf. Gata, acum ne putem termina dosarul .gitlab-ci.yml.

Creați o sarcină de implementare

Ceea ce vom face inițial cu GitLab CI este foarte asemănător cu ceea ce am făcut cu depozitele Git în trecut. Dar de data aceasta, să adăugăm depozitul Pantheon ca o a doua sursă Git la distanță, apoi să împingem codul din GitLab în Pantheon.

Pentru a face acest lucru, să configuram etapă deploy и sarcină deploy:dev, pentru că ne vom implementa în mediul de dezvoltare de pe Pantheon. Fișierul rezultat .gitlab-ci.yml Acesta va arăta în felul următor:

stages:
- deploy

before_script:
  # See 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

variabile SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL ar trebui să pară familiar - am configurat aceste variabile de mediu mai devreme. Cu aceste variabile vom putea folosi valorile din fișier .gitlab-ci.yml de multe ori și vor trebui actualizate doar într-un singur loc.

În cele din urmă, adăugați, confirmați și trimiteți fișierul .gitlab-ci.yml pe GitLab.

Verificarea implementării

Dacă am făcut totul corect, sarcina deploy:dev va rula cu succes în GitLab CI/CD și va trimite un commit .gitlab-ci.yml la Panteon. Să aruncăm o privire.

Se trimite fire de solicitare de îmbinare către Pantheon

Aici vom folosi funcția mea preferată Pantheon − multidev, unde puteți crea medii suplimentare Pantheon pentru ramurile Git la cerere.

Accesul la multidev este limitat, astfel încât această secțiune poate fi omisă. Dar dacă aveți acces, puteți crește serios productivitatea prin configurarea creării automate a mediilor multidev pe Pantheon din solicitările de îmbinare GitLab.

Mai întâi, să facem o nouă ramură Git local folosind git checkout -b multidev-support. Acum să schimbăm ceva din nou .gitlab-ci.yml.

Îmi place să includ numărul cererii de îmbinare în numele mediului Pantheon. De exemplu, prima solicitare de îmbinare este mr-1, al doilea - mr-2 etc.

Solicitarea de îmbinare se modifică, așa că trebuie să determinăm în mod dinamic numele ramurilor Pantheon. Este ușor pe GitLab - trebuie doar să îl utilizați variabile de mediu predefinite.

Putem lua $CI_MERGE_REQUEST_IIDpentru a specifica numărul cererii de îmbinare. Să aplicăm toate acestea împreună cu variabilele de mediu globale pe care le-am specificat mai devreme și să adăugăm o nouă sarcină deploy:multidev la sfârșitul fișierului .gitlab-ci.yml.

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # 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:mr-$CI_MERGE_REQUEST_IID --force
  only:
    - merge_requests

Va fi similar cu sarcina noastră deploy:dev, doar filiala este trimisă la Pantheon, nu la master.

Am adăugat și am comis fișierul actualizat .gitlab-ci.yml, iar acum să introducem o nouă ramură către GitLab cu git push -u origin multidev-support.

Acum să creăm o nouă solicitare de îmbinare din ramură multidev-supportdând clicuri Creați cerere de îmbinare.

După ce am creat o solicitare de îmbinare, ne uităm la modul în care este executată sarcina CI/CD deploy:multidev.

Uite, un subiect nou a fost trimis la Pantheon. Dar dacă mergem la secțiunea multidev de pe tabloul de bord al site-ului Pantheon, nu vom vedea noul mediu acolo

Să ne uităm la secțiunea Git Branches.

Drept urmare, firul nostru mr-1 a ajuns la Panteon. Să creăm un mediu dintr-o ramură mr-1.

Am creat un mediu multidev, acum să ne întoarcem la GitLab și să ne uităm la secțiune Operațiuni > Medii. Vom vedea intrări pentru dev и mr-1.

Acest lucru se datorează faptului că am adăugat o intrare environment Cu nume name и url în sarcini CI/CD. Dacă facem clic pe pictograma mediului deschis, vom fi duși la adresa URL a mediului multidev de pe Pantheon.

Automatizați crearea de multidev

În principiu, vă puteți opri aici și nu uitați să creați un mediu multidev pentru fiecare cerere de îmbinare, dar acest proces poate fi automatizat.

Pantheon are un instrument de linie de comandă Terminus, unde puteți lucra automat cu platforma. Terminus vă permite să creați medii multidev din linia de comandă - ideal pentru GitLab CI.

Avem nevoie de o nouă solicitare de îmbinare pentru a testa acest lucru. Să creăm o nouă ramură folosind git checkout -b auto-multidev-creation.

Pentru a utiliza Terminus în sarcinile GitLab CI/CD, aveți nevoie de un token de mașină pentru autentificare cu Terminus și de o imagine de container cu Terminus.

Crearea unui jeton de mașină Pantheon, salvați-l într-un loc sigur și adăugați-l ca variabilă de mediu globală în GitLab cu numele PANTHEON_MACHINE_TOKEN.

Dacă ați uitat cum să adăugați variabile de mediu GitLab, reveniți la locul în care am definit PANTHEON_SITE.

Crearea unui Dockerfile cu Terminus

Dacă nu utilizați Docker sau nu vă plac fișierele Dockerfile, ia-mi imaginea registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest și sări peste această secțiune.

GitLab are un registru de containere, unde putem construi și plasa fișierul Dockerfile pentru proiectul nostru. Să creăm un Dockerfile cu Terminus pentru a lucra cu Pantheon.

Terminus este un instrument de linie de comandă PHP, așa că să începem cu imaginea PHP. Instalez Terminus prin Composer, așa că voi folosi imagine oficială Docker Composer. Noi creăm Dockerfile în directorul de depozit local cu următorul conținut:

# 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"

Urmați instrucțiunile pentru asamblarea și trimiterea imaginilor din secțiune Construiți și împingeți imagini в documentația de înregistrare a containerelorpentru a colecta o imagine din Dockerfile și împingeți-l în GitLab.

Deschideți secțiunea Registru în proiectul GitLab. Dacă totul a decurs conform planului, imaginea noastră va fi acolo. Notați un link către eticheta de imagine - avem nevoie de el pentru fișier .gitlab-ci.yml.

Secțiune script in problema deploy:multidev începe să crească, așa că să-l mutăm într-un fișier separat. Creați un fișier nou 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..."
fi

Scriptul se află într-un director privat și nu permite accesul web la Pantheon. Avem un script pentru logica noastră multidev. Să actualizăm acum secțiunea deploy:multidev fişier .gitlab-ci.ymlastfel incat sa iasa asa:

deploy:multidev:
  stage: deploy
  environment:
    name: multidev/mr-$CI_MERGE_REQUEST_IID
    url: https://mr-$CI_MERGE_REQUEST_IID-$PANTHEON_SITE.pantheonsite.io/
  script:
    # Run the multidev deploy script
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Trebuie să ne asigurăm că sarcinile noastre sunt îndeplinite în imaginea personalizată creată, așa că haideți să adăugăm o definiție image de la adresa URL de registry la .gitlab-ci.yml. Drept urmare, am ajuns să avem un fișier ca acesta .gitlab-ci.yml:

image: registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest

stages:
- deploy

before_script:
  # See 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:
    # Run the multidev deploy script
    - "/bin/bash ./private/multidev-deploy.sh"
  only:
    - merge_requests

Adaugă, comite și trimite private/multidev-deploy.sh и .gitlab-ci.yml. Acum revenim la GitLab și așteptăm finalizarea sarcinii CI/CD. Aveți răbdare: crearea multidev poate dura câteva minute.

Apoi ne uităm la lista multidev de pe Pantheon. O minune! Mediu multidev mr-2 deja aici.

Concluzie

Echipa mea s-a distrat mult mai mult când am început să deschidem cereri de îmbinare și să creăm medii automat.

Cu instrumentele puternice ale GitLab și Pantheon, puteți conecta automat GitLab la Pantheon.

Deoarece folosim GitLab CI/CD, fluxul nostru de lucru va avea loc să crească. Iată câteva idei pentru a începe:

• Adăugați un pas de construcție.
• Adăugați testarea automată.
• Adăugați o sarcină pentru a vă asigura că sunt îndeplinite standardele de cod.
• Adăugați a testarea dinamică a securității aplicațiilor.

Spuneți-ne ce părere aveți despre GitLab, Pantheon și automatizare.

PS Știați că Terminus, instrumentul de linie de comandă al lui Pantheon, poate fi extins prin pluginuri?

Noi, cei de la Pantheon, am făcut o treabă bună cu versiunea 2 a noastră plugin pentru instrumentele de construire Terminus cu suport GitLab. Dacă nu doriți să vă deranjați cu setările pentru fiecare proiect, încercați acest plugin și ajutați-ne să testăm versiunea beta v2. Pentru echipa Terminus build:project:create Ai nevoie doar de un token Pantheon și un token GitLab. Ea va implementa unul dintre exemplele de proiecte cu Composer și testare automată, va crea un nou proiect în GitLab, un nou site Pantheon și le va conecta folosind variabile de mediu și chei SSH.

Despre autor

Andrew Taylor creează instrumente pentru dezvoltatori în Panteon.

Sursa: www.habr.com