Bereitstellung von Heroku-Apps für Staging- und Produktionsumgebungen mit GitLab CI/CD

Tutorials

GitLab

In einem vorherigen Artikel haben wir untersucht, wie man Deployments auf Heroku mit GitLab CI/CD automatisieren kann. Diese Konfiguration deployte die App in ihre Produktionsumgebung jedes Mal, wenn wir Code zur main-Branch gepusht haben.

In diesem Artikel werden wir eine etwas feinere Herangehensweise betrachten: Was ist, wenn wir mehrere Umgebungen haben? Die meisten Ingenieurorganisationen nutzen mindestens drei Umgebungen: eine lokale Entwicklungsumgebung, eine Staging-Umgebung und eine Produktionsumgebung.

Zusätzlich følgen einige Ingenieurteams einer Gitflow-Branching-Strategie, bei der sie einen dev-Branch und einen main-Branch haben. Diese Strategie ist mittlerweile in Ungnade gefallen und wurde durch trunk-based development ersetzt, aber es ist nicht ungewöhnlich, Organisationen zu finden, die diese Praxis immer noch befolgen.

Heute werden wir uns ansehen, wie man GitLab CI/CD konfiguriert, um unsere App in unsere Staging-Umgebung zu deployen, wenn wir zu dem Branch dev pushen, und unsere App in unsere Produktionsumgebung zu deployen, wenn wir zu dem Branch main pushen.

Erste Schritte

Bevor wir beginnen, benötigen wir zwei Dinge: ein Heroku-Konto und ein GitLab-Konto.

Heroku ist ein großartiger Ort, um Ihre Apps zu hosten und zu deployen. Als Platform as a Service (PaaS) ermöglicht Heroku Ihnen, sich auf das Erstellen cooler Dinge zu konzentrieren, während viel der Infrastrukturkomplexität abstrahiert wird. Sie können hier ein Heroku-Konto erstellen.

GitLab ist ein großartiger Ort, um Ihren Code zu speichern. Neben der reinen Quellcodeverwaltung bietet GitLab auch native CI/CD-Fähigkeiten, sodass Sie Pipelines einrichten können, um Ihren Code zu testen und zu deployen, ohne ein weiteres Drittanbieter-Tool benötigen zu müssen. Sie können hier ein GitLab-Konto erstellen.

Die in diesem Artikel gezeigte Demо-App nutzt sowohl GitLab als auch Heroku. Sie können alle den Code in diesem GitLab-Repo hier finden.

Unsere App lokal ausführen

Sie können die App lokal ausführen, indem Sie das Repository klonen, die Abhängigkeiten installieren und den Startbefehl ausführen. Geben Sie im Terminal Folgendes ein:

$ git clone https://gitlab.com/tylerhawkins1/heroku-gitflow-staging-production-gitlab-cicd-demo.git
$ cd heroku-gitflow-staging-production-gitlab-cicd-demo
$ npm install
$ npm start

Nach dem Starten der App besuchen Sie diesen lokalen Host in Ihrem Browser, und Sie werden die App lokal ausgeführt sehen:

Demo Heroku App

Unsere App auf Heroku bereitstellen

Nun die App lokal läuft, stellen wir sie auf Heroku bereit, damit Sie darauf überall zugreifen können, nicht nur auf Ihrem Computer.

Denken Sie daran, dass wir Ihre App sowohl in einer Staging-Umgebung als auch in einer Produktionsumgebung bereitstellen werden. Das bedeutet, dass wir zwei Heroku-Apps basierend auf demselben GitLab-Repository haben.

Falls Sie noch nicht das Heroku CLI auf Ihrem Computer installiert haben, müssen Sie dies vor dem Weitermachen installieren.

Nach der Installation des Heroku CLI führen Sie die folgenden Befehle von Ihrem Terminal aus, um den main-Zweig auszuchecken, eine neue Produktions-Heroku-App zu erstellen, sie in Ihre Produktionsumgebung zu bereitstellen und sie in Ihrem Browser zu öffnen:

$ git checkout main
$ heroku create heroku-gitlab-ci-cd-production --remote heroku-production
$ git push heroku-production main
$ heroku open --remote heroku-production

Jetzt sollten Sie die gleiche App sehen, aber dieses Mal unter einer Heroku-URL anstatt auf localhost. Gute Arbeit — Sie haben Ihre Heroku-App in die Produktion bereitgestellt!

Aber wir sind noch nicht fertig. Wir müssen auch Ihre Staging-App konfigurieren und bereitstellen. Tun Sie dies, indem Sie die unten gezeigte ähnliche Reihe von Befehlen ausführen:

$ git checkout dev
$ heroku create heroku-gitlab-ci-cd-staging --remote heroku-staging
$ git push heroku-staging main
$ heroku open --remote heroku-staging

Jetzt wird dieselbe App erneut bereitgestellt, aber diesmal unter einer anderen URL, die als Ihr Staging-Umgebung dienen wird. Jetzt sind beide Ihrer Umgebungen konfiguriert!

Beachten Sie die Unterschiede und Gemeinsamkeiten zwischen den Befehlen für die Produktions-App und die Staging-App:

Die Produktions-App verwendet den main-Zweig und die Staging-App verwendet den dev-Zweig.
Die Produktions-App heißt heroku-gitlab-ci-cd-production und die Staging-App heißt heroku-gitlab-ci-cd-staging.
Der Git-Remote der Produktions-App heißt heroku-production und der Git-Remote der Staging-App heißt heroku-staging.
Both the production app and the staging app’s git remotes use a main branch, since Heroku only deploys the app when code is pushed to its main branch.

Denken Sie daran, dass dieser main-Zweig unterschiedlich ist von Ihrem Satz von main– und dev-Zweigen. Der main-Zweig, den Sie hier pushen, ist der main-Zweig auf Ihrem Git-Remote — in diesem Fall Heroku.

Wenn Sie sich in Ihrem lokalen main-Zweig befinden und git push heroku-production main ausführen, pushes您的 main-Zweig zu dem main-Zweig der Heroku-Produktionsanwendung. Und wenn Sie sich in Ihrem lokalen dev-Zweig befinden und git push heroku-staging main ausführen, pushes您的 dev-Zweig zu dem main-Zweig der Heroku-Staging-Anwendung.

Änderungen an unserer App vornehmen

Jetzt, wo unsere Heroku-App läuft, was ist, wenn wir einige Änderungen vornehmen möchten? Nach einer groben Annahme der Gitflow-Branching-Strategie könnten wir folgendes tun:

Den dev-Zweig auschecken
Änderungen am Code vornehmen
Die Änderungen hinzufügen, committen und zum dev-Zweig pushen
Diese Änderungen zur Staging-Heroku-Anwendung deployen, indem Sie git push heroku-staging main ausführen
Den main-Zweig auschecken
Den dev-Zweig in den main-Zweig mergen
Diese Änderungen zur Produktions-Heroku-Anwendung deployen, indem Sie git push heroku-production main ausführen

(Wenn wir wirklich Gitflow befolgen würden, hätten wir einen Feature-Zweig erstellt, um ihn in dev zu mergen, und einen Release-Zweig, um ihn in main zu mergen, aber wir haben diese Schritte weggelassen, um es einfach zu halten.)

Jetzt wäre es doch schön, wenn wir die Deployment in eine unserer Umgebungen automatisieren könnten, anstatt sie ständig manuell zu deployen.

Daher kommt GitLab CI/CD ins Spiel.

Kontinuierliche Integration/Kontinuierliche Bereitstellung

Kontinuierliche Integration (CI) dreht sich darum, häufig zu committen und den Build ständig in einem guten Zustand zu halten. Typischerweise überprüfen Sie, ob der Build in einem guten Zustand ist, indem Sie Prüfungen in einer CI-Pipeline ausführen. Diese Prüfungen können Linter, Unit-Tests und/oder End-to-End-Tests umfassen.

Kontinuierliche Bereitstellung (CD) geht darum, häufig zu deployen. Wenn die Prüfungen in der CI-Pipeline bestehen, wird der Build bereitgestellt. Wenn die Prüfungen in der CI-Pipeline scheitern, wird der Build nicht bereitgestellt.

Mit GitLab CI/CD können wir unsere CI-Pipeline so konfigurieren, dass genau dies geschieht — wir führen unsere Tests aus und stellen unsere App auf Heroku bereit, wenn alle Tests bestehen. Am wichtigsten für unsere Konfiguration ist, dass wir Regeln innerhalb unserer CI-Pipeline festlegen können, um anzugeben, wo die App bereitgestellt werden soll.

Konfiguration von GitLab CI/CD

Wir können eine CI-Pipeline in GitLab programmatisch mit einer .gitlab-ci.yml-Datei erstellen. Unsere Datei sieht so aus:

YAML

image: node:20.10.0

cache:
  paths:
    - node_modules/

before_script:
  - node -v
  - npm install

stages:
  - test
  - deploy

unit-test-job:
  stage: test
  script:
    - npm test

deploy-job:
  stage: deploy
  variables:
    HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
    - if: $CI_COMMIT_REF_NAME =~ /dev/
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_STAGING
  script:
    - apt-get update -yq
    - apt-get install -y ruby-dev
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY

GitLab CI-Pipelines bestehen aus Stufen und Jobs. Jede Stufe kann einen oder mehrere Jobs enthalten. In unserer Pipeline haben wir zwei Stufen: test und deploy. In der test-Stufe führen wir unsere Unit-Tests im unit-test-job aus. In der deploy-Stufe stellen wir unsere App auf Heroku im deploy-job bereit.

Wir können nur zur nächsten Stufe übergehen, wenn alle Jobs in der vorherigen Stufe bestehen. Das bedeutet, wenn die Unit-Tests scheitern, wird die App nicht bereitgestellt, was eine gute Sache ist! Wir würden nicht unsere App bereitstellen wollen, wenn sie in einem schlechten Zustand ist.

Sie werden bemerken, dass die deploy-Stufe eine rules-Sektion mit etwas bedingter Logik hat. Hier geben wir an, in welche Umgebung unsere App deployed werden soll. Wenn wir im main-Branch sind, deployen wir unsere Produktions-App. Wenn wir im dev-Branch sind, deployen wir unsere Staging-App.

Sie werden auch bemerken, dass die deploy-Stufe mehrere Variablen wie $HEROKU_APP_NAME_PRODUCTION, $HEROKU_APP_NAME_STAGING und $HEROKU_API_KEY referenziert. Diese werden als CI/CD-Variablen in GitLab gespeichert.

Wenn Sie dies in Ihrem eigenen GitLab-Konto einrichten, müssen Sie zuerst Ihren API-Schlüssel in Ihrem Heroku-Konto finden. Innerhalb Ihrer Heroku-Konto-Einstellungen sollten Sie einen Abschnitt für Ihren API-Schlüssel sehen. Wenn Sie noch keinen API-Schlüssel generiert haben, tun Sie das jetzt.

Als nächstes klicken Sie in Ihrem GitLab-Projekt auf Einstellungen > CI/CD > Variables. Erweitern Sie diesen Abschnitt und fügen Sie drei neue Variablen hinzu:

Der Wert für $HEROKU_API_KEY wird der API-Schlüssel aus Ihrem Heroku-Konto sein.
Der Wert für $HEROKU_APP_NAME_PRODUCTION wird der Name Ihrer Produktions-Heroku-App sein. Der Name meiner Produktions-App ist heroku-gitlab-ci-cd-production, aber da Heroku-App-Namen universell eindeutig sind, wird Ihrer etwas anderes sein.
Der Wert für $HEROKU_APP_NAME_STAGING wird der Name Ihrer Staging-Heroku-App sein. Der Name meiner Staging-App ist heroku-gitlab-ci-cd-staging. Wiederhole, da Heroku-App-Namen universell einzigartig sind, wird yours anders sein.

Das bedeutet, dass Ihr GitLab CI-Pipeline bereit zum Starten ist! Lassen Sie es uns ausprobieren.

Deployment unserer Heroku-App in die Staging-Umgebung

Lassen Sie uns den dev-Zweig überprüfen und eine Änderung am Code unserer App vornehmen. Ich habe eine einfache Änderung im Überschriftentext vorgenommen und mehrere neue Zeilen zum Text in der Benutzeroberfläche hinzugefügt. Sie können eine ähnliche Änderung in Ihrem Code vornehmen.

Jetzt diese Änderung hinzufügen,.commit und zur dev-Zweig pushes. Dies wird den GitLab CI-Pipeline starten. Sie können die Pipeline innerhalb von GitLab anzeigen und den Fortschritt in Echtzeit sehen.

Falls alles gut geht, sollten Sie sehen, dass sowohl die test– als auch die deploy-Stufen bestanden haben. Gehen Sie jetzt Ihre gehostete Heroku-App unter der Staging-Umgebung URL ansehen. Der GitLab CI-Pipeline hat die Bereitstellung der App für Sie übernommen, sodass Sie nun Ihre Änderungen im Staging-Umfeld live sehen!

Mit einer eingerichteten Staging-Umgebung haben Sie einen großartigen Ort, um Ihren Code manuell in einer gehosteten Umgebung zu testen. Dies ist auch ein perfekter Ort, um QA-Tester oder Produktmanager Änderungen zu überprüfen, bevor sie in die Produktion gehen.

Jetzt überprüfen Sie die URL Ihrer Produkt-App. Sie werden feststellen, dass sie immer noch die alte Benutzeroberfläche ohne die neuesten Änderungen anzeigt. Dies liegt daran, dass der GitLab CI-Pipeline die Änderungen nur in die Staging-Umgebung und nicht in die Produktionsumgebung bereitgestellt hat.

Wir haben überprüft, dass der Code in unserer Staging-Umgebung gut aussieht, also lassen Sie uns diesen in unsere Produktionsumgebung übernehmen.

Deployment unserer Heroku-App in die Produktionsumgebung

Lassen Sie uns den main-Zweig überprüfen und dann den dev-Zweig in Ihren main-Zweig integrieren. Sie könnten dies über einen Pull Request erledigen oder indem Sie git merge dev ausführen und dann git push.

Dies wird den GitLab CI-Pipeline erneut starten, aber dieses Mal wird er sich auf das Deployment Ihrer Produktions-App vorbereiten.

Sie können auch alle Pipeline-Läufe auf der Pipelines-Seite in GitLab ansehen, um die verschiedenen Builds für Ihre dev– und main-Zweige zu sehen:

Sobald die Pipeline abgeschlossen ist, besuchen Sie die URL Ihrer Produktions-Heroku-App. Sie sollten nun Ihre Änderungen auch in der Produktion deployed sehen. Großartige Arbeit!

Schlussfolgerung

A good CI pipeline allows you to ship new features quickly and confidently without manually managing the deployment process. Having multiple environments configured for local development, staging, and production gives you more control over where and when code is released.

Heroku und GitLab CI/CD ermöglichen es Ihnen, all dies zu automatisieren, um Ihre DevOps-Prozesse zu erleichtern!

Source:
https://dzone.com/articles/deploying-heroku-apps-to-staging-and-production