Déploiement d’applications Heroku vers les environnements d’étape et de production avec GitLab CI/CD

Tutoriels

GitLab

Dans un article précédent, nous avons exploré comment automatiser les déploiements sur Heroku en utilisant GitLab CI/CD. Cette configuration déployait l’application dans son environnement de production chaque fois que nous poussions du code sur la branche main.

Dans cet article, nous considérons une approche légèrement plus nuancée : Que se passe-t-il si nous avons plusieurs environnements ? La plupart des organisations d’ingénierie utilisent au moins trois environnements : un environnement de développement local, un environnement de préproduction et un environnement de production.

De plus, certaines équipes d’ingénierie suivent une stratégie de branches Gitflow, où elles ont une branche dev et une branche main. Cette stratégie est tombée en désuétude et a été remplacée par la méthode de développement basée sur le tronc, mais il n’est pas rare de trouver des organisations qui suivent encore cette pratique.

Aujourd’hui, nous allons voir comment configurer GitLab CI/CD pour déployer notre application sur notre environnement de pré-production lorsque nous poussons sur la branche dev et déployer notre application sur notre environnement de production lorsque nous poussons sur la branche main.

Démarrer

Avant de commencer, nous aurons besoin de deux choses : un compte Heroku et un compte GitLab.

Heroku est un excellent endroit pour héberger et déployer vos applications. En tant que plateforme en tant que service (PaaS), Heroku vous permet de vous concentrer sur la création de choses sympas tout en abstractissant une grande partie de la complexité de l’infrastructure. Vous pouvez créer un compte Heroku ici.

GitLab est un excellent endroit pour stocker votre code. Au-delà d’être simplement un outil de gestion de code source, GitLab offre également des capacités CI/CD natives, ce qui vous permet de configurer des pipelines pour tester et déployer votre code sans nécessiter un autre outil tiers. Vous pouvez créer un compte GitLab ici.

L’application de démonstration présentée dans cet article utilise à la fois GitLab et Heroku. Vous pouvez trouver tout le code dans le dépôt GitLab ici.

Lancer Notre Application Localement

Vous pouvez exécuter l’application localement en克隆ant le dépôt, en installant les dépendances et en exécutant la commande de démarrage. Dans votre terminal, faites ce qui suit :

$ 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

Après avoir démarré l’application, visitez ce hôte local dans votre navigateur, et vous verrez l’application s’exécuter localement :

Demo application Heroku

Déploiement de notre application sur Heroku

Depuis que l’application s’exécute localement, déploions-la sur Heroku afin que vous puissiez y accéder depuis n’importe où, et pas seulement sur votre machine.

Rappelez-vous que nous allons déployer votre application à la fois dans un environnement de pré-production et un environnement de production. Cela signifie que nous aurons deux applications Heroku basées sur le même dépôt GitLab.

Si vous n’avez pas déjà installé le CLI Heroku sur votre machine, vous devrez l’installer avant de continuer.

Après avoir installé le CLI Heroku, exécutez les commandes suivantes depuis votre terminal pour vérifier le branchement main, créer une nouvelle application Heroku de production, la déployer dans votre environnement de production et l’ouvrir dans votre navigateur :

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

Avec cela, vous devriez voir la même application, mais cette fois en cours d’exécution sur une URL Heroku plutôt que sur localhost. Bon travail — vous avez déployé votre application Heroku en production !

Mais, nous ne sommes pas encore terminés. Nous devons également configurer et déployer votre application de pré-production. Pour ce faire, exécutez cette série similaire de commandes montrées ci-dessous :

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

Maintenant, vous allez déployer à nouveau la même application, mais cette fois à une URL différente qui servira d’environnement de préproduction. Nous avons maintenant configuré les deux environnements !

Remarquez les différences et similitudes entre les commandes pour l’application de production et l’application de préproduction :

L’application de production utilise la branche main, et l’application de préproduction utilise la branche dev.
L’application de production s’appelle heroku-gitlab-ci-cd-production, et l’application de préproduction s’appelle heroku-gitlab-ci-cd-staging.
Le dépôt distant git de l’application de production s’appelle heroku-production, et celui de l’application de préproduction s’appelle heroku-staging.
Les dépôts distants git des applications de production et de préproduction utilisent tous deux une branche main, car Heroku ne déploie l’application que lorsque du code est poussé sur sa branche principale.

Gardez à l’esprit que cette branche main est différente de votre ensemble de branches main et dev. La branche main que vous poussez ici est la branche main de votre dépôt distant – dans ce cas, Heroku.

Lorsque vous êtes sur votre branche locale main et que vous exécutez git push heroku-production main, vous poussez votre branche main vers la branche main de l’application de production Heroku. Et lorsque vous êtes sur votre branche locale dev et que vous exécutez git push heroku-staging main, vous poussez votre branche dev vers la branche main de l’application de préproduction Heroku.

Faire des Modifications à Notre App

Jetzt que nous avons notre application Heroku en ligne et fonctionnelle, que se passe-t-il si nous voulons faire quelques modifications ? En suivant une approximation grossière de la stratégie de branche Gitflow, nous pourrions faire ce qui suit :

Check out de la branche dev
Faire des modifications au code
Ajouter, commiter et pousser ces modifications vers la branche dev
Déployer ces modifications vers l’application de préproduction Heroku en exécutant git push heroku-staging main
Check out de la branche main
Fusionner la branche dev dans la branche main
Déployer ces modifications vers l’application de production Heroku en exécutant git push heroku-production main

(Si nous suivions vraiment Gitflow, nous aurions créé une branche de fonction pour fusionner dans dev, et une branche de version pour fusionner dans main, mais nous avons omis ces étapes pour garder les choses simples.)

Ne serait-il pas agréable de pouvoir automatiser le déploiement vers l’un ou l’autre de nos environnements plutôt que d’avoir à les déployer manuellement tout le temps ?

C’est là que GitLab CI/CD entre en jeu.

Intégration continue/Déploiement continu

L’intégration continue (CI) consiste à commiter souvent et à maintenir le build dans un état bon à tout moment. Typiquement, vous vérifieriez que le build est dans un état bon en exécutant des vérifications dans un pipeline CI. Ces vérifications peuvent inclure des linters, des tests unitaires et/ou des tests bout en bout.

Le déploiement continu (CD) consiste à déployer fréquemment. Si les vérifications dans le pipeline CI passent, alors le build est déployé. Si les vérifications dans le pipeline CI échouent, alors le build n’est pas déployé.

Avec GitLab CI/CD, nous pouvons configurer notre pipeline CI pour faire exactement cela — exécuter nos tests puis déployer notre application sur Heroku si les tests passent tous. Le plus important pour notre configuration, nous pouvons définir des règles dans notre pipeline CI pour spécifier où l’application doit être déployée.

Configuration de GitLab CI/CD

Nous pouvons créer un pipeline CI dans GitLab de manière programmatique en utilisant un fichier .gitlab-ci.yml. Notre fichier ressemble à cela :

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

Les pipelines CI GitLab consistent en des étapes et des jobs. Chaque étape peut contenir un ou plusieurs jobs. Dans notre pipeline, nous avons deux étapes : test et deploy. Dans l’étape test, nous exécutons nos tests unitaires dans le unit-test-job. Dans l’étape deploy, nous déployons notre application sur Heroku dans le deploy-job.

Nous ne pouvons passer à l’étape suivante que si tous les jobs de l’étape précédente passent. Cela signifie que si les tests unitaires échouent, alors l’application ne sera pas déployée, ce qui est une bonne chose ! Nous ne voudrions pas déployer notre application si elle était dans un mauvais état.

Vous remarquerez que l’étape deploy possède une section rules avec une logique conditionnelle en place. C’est ici que nous spécifions dans quel environnement notre application doit être déployée. Si nous sommes sur la branche main, alors nous déployons notre application de production. Si nous sommes sur la branche dev, alors nous déployons notre application d’exploitation.

Vous remarquerez également que l’étape deploy fait référence à plusieurs variables appelées $HEROKU_APP_NAME_PRODUCTION, $HEROKU_APP_NAME_STAGING, et $HEROKU_API_KEY. Ceux-ci sont stockés en tant que variables CI/CD au sein de GitLab.

Si vous mettez ceci en place dans votre propre compte GitLab, vous devrez d’abord trouver votre clé API dans votre compte Heroku. Dans les paramètres de votre compte Heroku, vous devriez voir une section pour votre clé API. Si vous n’avez pas encore généré de clé API, générez-en une maintenant.

Ensuite, dans votre projet GitLab, cliquez sur Paramètres > CI/CD > Variables. Développez cette section et ajoutez trois nouvelles variables:

La valeur pour $HEROKU_API_KEY sera la clé API de votre compte Heroku.
La valeur pour $HEROKU_APP_NAME_PRODUCTION sera le nom de votre application Heroku de production. Le nom de mon application de production est heroku-gitlab-ci-cd-production, mais comme les noms d’applications Heroku sont universellement uniques, le vôtre sera différent.
La valeur pour $HEROKU_APP_NAME_STAGING sera le nom de votre application Heroku de pré-production. Le nom de mon application de pré-production est heroku-gitlab-ci-cd-staging. Encore une fois, comme les noms d’applications Heroku sont universellement uniques, le vôtre sera différent.

Avec cela, votre pipeline GitLab CI est prêt à être utilisé ! Mettons-le à l’épreuve.

Déploiement de notre application Heroku dans l’environnement de pré-production

Mettons-nous sur la branche dev et apportons une modification au code de notre application. J’ai fait une modification simple au texte de l’en-tête et ajouté plusieurs nouvelles lignes au texte dans l’interface utilisateur. Vous pouvez faire une modification similaire dans votre code.

Jetzt hinzufügen, committen und diese Änderung zur dev-Branche pushen. Dies wird den GitLab CI-Pipeline starten. Sie können den Pipeline-Verlauf in GitLab ansehen und den Fortschritt in Echtzeit verfolgen.

Si tout se passe bien, vous devriez voir que les étapes test et deploy ont toutes deux réussi. Maintenant, allez vérifier votre application Heroku hébergée à l’URL de l’environnement de pré-production. Le pipeline GitLab CI s’est occupé du déploiement de l’application pour vous, donc vous devriez maintenant voir vos modifications en direct dans l’environnement de pré-production !

Avec un environnement de pré-production configuré, vous avez maintenant un excellent endroit pour tester manuellement votre code dans un environnement hébergé. C’est également un endroit parfait pour que les testeurs QA ou les gestionnaires de produit vérifient les modifications avant qu’elles ne soient mises en production.

Jetzt überprüfen Sie die URL Ihrer Produktionsanwendung. Sie werden bemerken, dass sie immer noch die alte Benutzeroberfläche ohne die letzten Änderungen anzeigt. Dies liegt daran, dass der GitLab CI-Pipeline die Änderungen nur in das Testumfeld und nicht in das Produktionsumfeld deployiert hat.

Nous avons vérifié que le code fonctionne bien dans notre environnement de pré-production, donc passons-le à notre environnement de production.

Déploiement de notre application Heroku dans l’environnement de production

Laissons vérifier la branche main puis fusionnons la branche dev dans votre branche main. Vous pouvez le faire via une demande de fusion (pull request) ou en exécutant git merge dev puis git push.

Cela lancera à nouveau le pipeline GitLab CI, mais cette fois, il se prépare à déployer votre application de production.

Vous pouvez également voir toutes les exécutions du pipeline sur la page Pipelines dans GitLab pour voir les différents builds pour vos branches dev et main:

Une fois que le pipeline est terminé, visitez l’URL de votre application Heroku de production. Vous devriez maintenant voir vos modifications également déployées en production. Excellent travail !

Conclusion

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 et GitLab CI/CD vous permettent d’automatiser tout cela pour rendre vos processus DevOps un jeu d’enfant !

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