Il nostro creatore di strumenti per sviluppatori ospiti presso Pantheon parla di come automatizzare le distribuzioni di WordPress utilizzando GitLab CI/CD.
В Lavoro nelle relazioni con gli sviluppatori, quindi sono sempre alla ricerca di nuovi modi per aiutare gli sviluppatori WordPress e Drupal a risolvere i problemi di automazione nei loro flussi di lavoro. Per fare questo mi piace sperimentare nuovi strumenti e combinarli tra loro per lavorare in modo efficace.
Vedo spesso sviluppatori alle prese con un singolo server di staging.
È un vero piacere aspettare il tuo turno per utilizzare un server intermedio o inviare ai clienti un URL con la nota: "Guarda qui, ma non guardare ancora qui".
- uno dei fantastici strumenti Pantheon - risolve questo problema, perché con loro puoi creare ambienti per i rami Git su richiesta. Ogni ambiente multidev ha il proprio URL e database, quindi gli sviluppatori possono lavorare tranquillamente, verificare la qualità e ottenere l'approvazione senza intralciarsi a vicenda.
Ma Pantheon non dispone di strumenti per il controllo della versione o per l'integrazione e la distribuzione continua (CI/CD). Ma è una piattaforma flessibile con la quale puoi integrare qualsiasi strumento.
Ho anche notato che i team utilizzano determinati strumenti per lo sviluppo e diversi per l'assemblaggio e la distribuzione.
Ad esempio, hanno diversi strumenti per il controllo della versione e CI/CD. Devi armeggiare e passare da uno strumento all'altro per modificare il codice e diagnosticare i problemi.
Su esiste un set completo di strumenti di sviluppo: per il controllo della versione, ticket, richieste di unione, una pipeline CI/CD migliore della categoria, un registro dei contenitori e tutto il resto. Non ho ancora trovato un'applicazione che offra così tanto per gestire il flusso di lavoro di sviluppo.
Adoro l'automazione, quindi ho imparato come connettere Pantheon a GitLab in modo che i commit sul ramo principale su GitLab vengano distribuiti nell'ambiente di sviluppo principale in Pantheon. E le richieste di unione su GitLab possono creare e distribuire codice in ambienti multidev in Pantheon.
In questo tutorial ti spiegherò come impostare una connessione tra GitLab e Pantheon e ottimizzare il flusso di lavoro WordPress e Drupal.
Certo che è possibile, , ma faremo tutto con le nostre mani per approfondire e in futuro utilizzare questo strumento non solo per la distribuzione.
Introduzione
Per questo post, devi capire che Pantheon suddivide ogni sito in tre elementi: codice, database e file.
Il codice include file CMS come core di WordPress, plugin e temi. Questi file sono gestiti in , ospitato da Pantheon, il che significa che possiamo distribuire codice da GitLab a Pantheon con Git.
I file in Pantheon sono file multimediali, ovvero immagini per il sito. In genere vengono caricati dagli utenti e Git li ignora.
, scopri di più su o su pantheon.io.
assunzioni
Il mio progetto su Pantheon e GitLab si chiama pantheon-gitlab-blog-demo. Il nome del progetto deve essere univoco. Qui lavoreremo con un sito WordPress. Puoi prendere Drupal, ma dovrai cambiare alcune cose.
userò e puoi lavorare , se lo desidera.
Crea un progetto
Per prima cosa, creiamo (torneremo su questo più tardi).
Ora . Quindi installiamo WordPress per la dashboard del sito.
Se le tue mani non vedono l'ora di cambiare qualcosa, ad esempio rimuovere o aggiungere plugin, sii paziente. Il sito non è ancora connesso a GitLab e vogliamo che tutte le modifiche al codice passino attraverso GitLab.
Una volta installato WordPress, torna alla dashboard del sito Web Pantheon e modifica la modalità di sviluppo in Git.
Commit iniziale su GitLab
Ora devi trasferire il codice WordPress iniziale dal sito Pantheon a GitLab. Per fare ciò cloniamo il codice dal repository Git del sito Pantheon in locale, per poi inviarlo al repository GitLab.
Per renderlo più semplice e sicuro, e non dovremo inserire una password ogni volta che cloniamo un repository Git Pantheon. Già allo stesso tempo .
Per fare ciò, clona localmente il sito Pantheon copiando il comando dal campo Clona con Git nella dashboard del sito.
Se hai bisogno di aiuto, leggi la documentazione .
Ora cambiamo git remote originper puntare a GitLab invece che a Pantheon. Si può fare .
Andiamo al progetto GitLab e copiamo l'URL del repository dal menu a discesa Clone nella pagina dei dettagli del progetto. Scegliamo l'opzione Clona con SSH, perché abbiamo già configurato la chiave SSH.
Per impostazione predefinita git remote per una copia locale del repository del codice - origin. Questo può essere cambiato c git remote set-url origin [URL репозитория GitLab], dove al posto delle parentesi inseriamo l'URL effettivo.
Infine, lanciamo git push origin master --forceper spingere il codice WordPress da Pantheon a GitLab.
L'opzione –force è necessaria solo una volta. Poi a squadre
git pushnon sarà su GitLab.
Impostazione di credenziali e variabili
Ricordi come abbiamo aggiunto una chiave SSH localmente per accedere a Pantheon e GitLab? Il token SSH può essere utilizzato per autorizzare GitLab e Pantheon.
GitLab ha un'eccellente documentazione. Vediamo .
Completeremo ora i primi due passaggi: Creiamo una nuova coppia di chiavi SSH localmente con ssh-keygen e aggiungiamo la chiave privata come variabile al progetto.
Allora chiederemo SSH_PRIVATE_KEY come nelle impostazioni del progetto.
Nel terzo e quarto passaggio creeremo un file .gitlab-ci.yml con contenuti come questo:
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"Non committiamo ancora il file .gitlab-ci.yml, allora dovrai aggiungerci qualcos'altro.
Ora eseguiamo il quinto passaggio e aggiungi la chiave pubblica che hai creato nel primo passaggio ai servizi a cui devi accedere nell'ambiente di compilazione.
Nel nostro caso, vogliamo accedere a Pantheon da GitLab. Seguiamo le istruzioni contenute nel documento Pantheon su ed eseguire questo passaggio.
Ricorda: SSH privato è in GitLab, SSH aperto è in Pantheon.
Impostiamo alcune altre variabili d'ambiente. Il primo si chiama PANTHEON_SITE. Il suo valore è il nome del sito Pantheon sul tuo computer.
Il nome sulla macchina è elencato alla fine del comando Clona con Git. Hai già clonato il sito localmente, quindi questo sarà il nome della directory del repository locale.
Successivamente, impostiamo la variabile di ambiente PANTHEON_GIT_URL. Questo è l'URL del repository Git per il sito Pantheon che abbiamo già utilizzato.
Inserisci solo l'URL del repository SSH, senza
git clonee alla fine il nome del sito sulla macchina.
Uff. Fatto, ora possiamo finire il nostro file .gitlab-ci.yml.
Creare un'attività di distribuzione
Ciò che inizialmente faremo con GitLab CI è molto simile a ciò che abbiamo fatto in passato con i repository Git. Ma questa volta aggiungiamo il repository Pantheon come seconda sorgente Git remota e quindi inviamo il codice da GitLab a Pantheon.
Per fare ciò, configuriamo deploy и deploy:dev, perché eseguiremo il deploy nell'ambiente di sviluppo su Pantheon. Il file risultante .gitlab-ci.yml sarà simile a questa:
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:
- mastervariabili SSH_PRIVATE_KEY, PANTHEON_SITE и PANTHEON_GIT_URL dovrebbe sembrare familiare: abbiamo impostato queste variabili d'ambiente in precedenza. Con queste variabili potremo utilizzare i valori presenti nel file .gitlab-ci.yml molte volte e dovranno essere aggiornati solo in un unico posto.
Infine, aggiungi, conferma e invia il file .gitlab-ci.yml su GitLab.
Verifica della distribuzione
Se abbiamo fatto tutto correttamente, il compito deploy:dev verrà eseguito correttamente in GitLab CI/CD e invierà un commit .gitlab-ci.yml al Pantheon. Diamo un'occhiata.
Invio di thread di richiesta di unione a Pantheon
Qui utilizzeremo la mia funzionalità Pantheon preferita − , dove puoi creare ambienti Pantheon aggiuntivi per i rami Git su richiesta.
, quindi questa sezione può essere saltata. Ma se hai accesso, puoi aumentare seriamente la produttività impostando la creazione automatica di ambienti multidev su Pantheon dalle richieste di unione di GitLab.
Per prima cosa creiamo un nuovo ramo Git localmente utilizzando git checkout -b multidev-support. Ora cambiamo di nuovo qualcosa in .gitlab-ci.yml.
Mi piace includere il numero della richiesta di unione nel nome dell'ambiente Pantheon. Ad esempio, la prima richiesta di unione è mr-1, secondo - mr-2 eccetera.
La richiesta di unione cambia, quindi dobbiamo determinare dinamicamente i nomi dei rami del Pantheon. È facile su GitLab: devi solo usarlo .
Possiamo prendere $CI_MERGE_REQUEST_IIDper specificare il numero della richiesta di unione. Applichiamo tutto questo insieme alle variabili di ambiente globali che abbiamo specificato in precedenza e aggiungiamo una nuova attività deploy:multidev alla fine del file .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_requestsSarà simile al nostro compito deploy:dev, solo il ramo viene inviato al Pantheon, non a master.
Abbiamo aggiunto e confermato il file aggiornato .gitlab-ci.yml, e ora eseguiamo il push di un nuovo ramo su GitLab con git push -u origin multidev-support.
Ora creiamo una nuova richiesta di unione dal ramo multidev-supportpremendo Crea richiesta di unione.
Dopo aver creato una richiesta di unione, esaminiamo come viene eseguita l'attività CI/CD deploy:multidev.
Guarda, un nuovo thread è stato inviato a Pantheon. Ma se andiamo alla sezione multidev sulla dashboard del sito Pantheon, non vedremo il nuovo ambiente lì
Diamo un'occhiata alla sezione Rami Git.
Di conseguenza, il nostro thread mr-1 arrivato al Pantheon. Creiamo un ambiente da un ramo mr-1.
Abbiamo creato un ambiente multidev, ora torniamo a GitLab e guardiamo la sezione Operazioni > Ambienti. Vedremo le voci per dev и mr-1.
Questo perché abbiamo aggiunto una voce environment Con nome name и url in attività CI/CD. Se clicchiamo sull'icona dell'ambiente aperto, verremo indirizzati all'URL dell'ambiente multidev su Pantheon.
Automatizza la creazione di multidev
In linea di principio, puoi fermarti qui e ricordarti semplicemente di creare un ambiente multidev per ogni richiesta di fusione, ma questo processo può essere automatizzato.
Pantheon ha uno strumento da riga di comando , dove puoi lavorare automaticamente con la piattaforma. Terminus ti consente di creare ambienti multidev dalla riga di comando, ideale per .
Abbiamo bisogno di una nuova richiesta di unione per testarlo. Creiamo un nuovo ramo utilizzando git checkout -b auto-multidev-creation.
Per utilizzare Terminus nelle attività CI/CD GitLab, è necessario un token macchina per l'autenticazione con Terminus e un'immagine del contenitore con Terminus.
, salvalo in un luogo sicuro e aggiungilo come variabile d'ambiente globale in GitLab con il nome PANTHEON_MACHINE_TOKEN.
Se hai dimenticato come aggiungere le variabili di ambiente GitLab, torna a dove abbiamo definito
PANTHEON_SITE.
Creazione di un Dockerfile con Terminus
Se non usi Docker o non ti piacciono i file Dockerfile, prendi la mia immagine registry.gitlab.com/ataylorme/pantheon-gitlab-blog-demo:latest e salta questa sezione.
, dove possiamo creare e posizionare il Dockerfile per il nostro progetto. Creiamo un Dockerfile con Terminus per lavorare con Pantheon.
Terminus è uno strumento da riga di comando PHP, quindi iniziamo con l'immagine PHP. Sto installando Terminus tramite Composer, quindi userò . Noi creiamo Dockerfile nella directory del repository locale con il seguente contenuto:
# 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"Segui le istruzioni per il montaggio e l'invio delle immagini dalla sezione Costruisci e invia immagini в da cui raccogliere un'immagine Dockerfile e inviarlo a GitLab.
Apertura della sezione registro nel progetto GitLab. Se tutto è andato secondo i piani, la nostra immagine sarà lì. Annota un collegamento al tag immagine: ne abbiamo bisogno per il file .gitlab-ci.yml.
Sezione script nel problema deploy:multidev sta iniziando a crescere, quindi spostiamolo in un file separato. Crea un nuovo file 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..."
fiLo script è in una directory privata e . Abbiamo uno script per la nostra logica multidev. Aggiorniamo ora la sezione deploy:multidev файла .gitlab-ci.ymlin modo che risulti così:
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_requestsDobbiamo assicurarci che le nostre attività vengano eseguite nell'immagine personalizzata creata, quindi aggiungiamo una definizione image dall'URL del registro a .gitlab-ci.yml. Di conseguenza, ci siamo ritrovati con un file come questo .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_requestsAggiungi, conferma e invia private/multidev-deploy.sh и .gitlab-ci.yml. Ora torniamo a GitLab e aspettiamo il completamento dell'attività CI/CD. Sii paziente: la creazione di multidev può richiedere diversi minuti.
Poi andiamo a dare un'occhiata all'elenco multidev su Pantheon. Oh miracolo! Ambiente multisviluppo mr-2 già qui.
conclusione
Il mio team si è divertito molto di più quando abbiamo iniziato ad aprire richieste di unione e a creare ambienti automaticamente.
Con i potenti strumenti di GitLab e Pantheon, puoi connettere GitLab a Pantheon automaticamente.
Poiché utilizziamo GitLab CI/CD, il nostro flusso di lavoro avrà spazio per crescere. Ecco un paio di idee per iniziare:
- Aggiungi un passaggio di creazione.
- Aggiungi test automatizzati.
- Aggiungi un'attività per garantire il rispetto degli standard del codice.
- Inserisci .
Fammi sapere cosa ne pensi di GitLab, Pantheon e dell'automazione.
PS Sapevi che Terminus, lo strumento da riga di comando di Pantheon, ?
Noi di Pantheon abbiamo fatto un buon lavoro sulla versione 2 del ns con il supporto di GitLab. Se non vuoi preoccuparti delle impostazioni per ogni progetto, prova questo plugin e aiutaci a testare la versione beta v2. Per la squadra del Termine build:project:create Hai solo bisogno di un token Pantheon e un token GitLab. Distribuirà uno dei progetti di esempio con Composer e test automatizzati, creerà un nuovo progetto in GitLab, un nuovo sito Pantheon, e li collegherà utilizzando variabili di ambiente e chiavi SSH.
Chi l'Autore
Andrew Taylor crea strumenti per gli sviluppatori in .
Fonte: habr.com