Het Implementeren van Heroku-apps naar Stagings- en Productieomgevingen met GitLab CI/CD

In een eerder artikel hebben we onderzocht hoe we deployments naar Heroku kunnen automatiseren met behulp van GitLab CI/CD. Die setup deplooyde de app naar zijn productieomgeving elke keer dat we code pushten naar de main branch.

In dit artikel zullen we een iets genuanceerdere aanpak overwegen: Wat als we meerdere omgevingen hebben? De meeste ingenieursorganisaties gebruiken minstens drie omgevingen: een lokale ontwikkelomgeving, een testomgeving en een productieomgeving.

Bovendien volgen sommige ingenieursteams een Gitflow branching strategy, waarbij ze een dev branch en een main branch hebben. Deze strategie is in onbruik geraakt en vervangen door trunk-based development, maar het is niet ongebruikelijk om organisaties te vinden die deze praktijk nog steeds volgen.

Vandaag gaan we kijken hoe we GitLab CI/CD configureren om onze app naar onze staging-omgeving te deployen wanneer we naar de dev-branch pushen en onze app naar onze productieomgeving te deployen wanneer we naar de main-branch pushen.

aan de slag

Voordat we beginnen, hebben we twee dingen nodig: een Heroku-account en een GitLab-account.

Heroku is een geweldige plek om je apps te hosten en te deployen. Als een platform as a service (PaaS) stelt Heroku je in staat om je te concentreren op het bouwen van leuke dingen, terwijl veel van de infrastructuurcomplexiteit wordt afgehandeld. Je kunt een Heroku-account hier aanmaken.

GitLab is een geweldige plek om je code op te slaan. Naast het feit dat het een hulpmiddel voor source code management is, biedt GitLab ook native CI/CD-mogelijkheden, zodat je pipelines kunt instellen om je code te testen en te deployen zonder een andere third-party tool nodig te hebben. Je kunt een GitLab-account hier aanmaken.

De demo-app die in dit artikel wordt getoond, maakt gebruik van zowel GitLab als Heroku. Je kunt alle code in de GitLab-repo hier vinden.

Onze App Lokaal Uitvoeren

Je kunt de app lokaal uitvoeren door de repo te klonen, afhankelijkheden te installeren en het startcommando uit te voeren. In je terminal voer je het volgende uit:

$ 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

Na het starten van de app, ga naar deze lokale host in je browser, en je zult de app lokaal draaiend zien:

Demo Heroku app

Onze App naar Heroku Deployment

Nu de app lokaal draait, laten we hem deployen naar Heroku zodat je hem overal kunt bereiken, niet alleen op je machine.

Onthoud dat we je app gaan deployen naar zowel een staging-omgeving als een productie-omgeving. Dit betekent dat we twee Heroku-apps zullen hebben gebaseerd op dezelfde GitLab repo.

Als je nog geen Heroku CLI geïnstalleerd hebt op je machine, moet je dat installeren voordat je verder gaat.

Na het installeren van de Heroku CLI, voer je de volgende commando’s uit je terminal uit om de main branch te controleren, een nieuwe productie Heroku-app te maken, deze naar je productie-omgeving te deployen en deze in je browser te openen:

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

Daarmee zou je dezelfde app moeten zien, maar deze keer draaiend op een Heroku URL in plaats van op localhost. Goed werk — je hebt je Heroku-app naar productie gedeployed!

Maar, we zijn nog niet klaar. We moeten ook je staging-app configureren en deployen. Hiervoor voer je dezelfde reeks commando’s uit die hieronder wordt getoond:

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

Nu wordt dezelfde app opnieuw gedeployd, maar deze keer naar een andere URL die dient als je testomgeving. Nu zijn beide omgevingen van je app geconfigureerd!

Merk de verschillen en overeenkomsten op tussen de opdrachten voor de productie-app en de test-app:

1. De productie-app gebruikt de main branch, en de test-app gebruikt de dev branch.
2. De productie-app heet heroku-gitlab-ci-cd-production, en de test-app heet heroku-gitlab-ci-cd-staging.
3. De git remote van de productie-app heet heroku-production, en de git remote van de test-app heet heroku-staging.
4. 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.

Houd er rekening mee dat deze main branch verschilt van je set van main en dev branches. De main branch waar je naar pusht hier is de main branch op je git remote — in dit geval, Heroku.

Zoals je bent op je lokale main branch en je voert git push heroku-production main uit, stuur je je main branch naar de main branch van de Heroku productie-app. En wanneer je op je lokale dev branch bent en je voert git push heroku-staging main uit, stuur je je dev branch naar de main branch van de Heroku staging-app.

Wijzigingen Aan Onze App Maken

Nu we onze Heroku-app draaiend hebben, wat als we wat wijzigingen willen aanbrengen? Volgens een ruwe afbeelding van de Gitflow branching strategie, kunnen we het volgende doen:

1. Controleer de dev branch uit
2. Maak wijzigingen in de code
3. Voeg toe, commit en push deze wijzigingen naar de dev branch
4. Deploy deze wijzigingen naar de staging Heroku-app door git push heroku-staging main uit te voeren
5. Controleer de main branch uit
6. Voeg de dev branch samen met de main branch
7. Deploy deze wijzigingen naar de productie Heroku-app door git push heroku-production main uit te voeren

(Als we echt Gitflow zouden volgen, zouden we een feature branch hebben gemaakt om samen te voegen met dev, en een release branch om samen te voegen met main, maar we hebben deze stappen weggelaten om het eenvoudig te houden.)

Nu, zou het niet fijn zijn als we de deploy naar een van onze omgevingen konden automatiseren in plaats van ze steeds handmatig te moeten deployen?

Dit is waar GitLab CI/CD om de hoek komt kijken.

Continue Integratie/Continue Uitrol

Continue integratie (CI) draait om vaak committen en de build in een goede staat houden op elk moment. Typisch zou je verifiëren dat de build in een goede staat is door controles uit te voeren in een CI-pijplijn. Deze controles kunnen linters, eenheidstests en/of end-to-end tests omvatten.

Continue uitrol (CD) draait om vaak uit te rollen. Als de controles in de CI-pijplijn slagen, dan wordt de build uitgerold. Als de controles in de CI-pijplijn falen, dan wordt de build niet uitgerold.

Met GitLab CI/CD kunnen we onze CI-pijplijn configureren om exact dit te doen — onze tests uitvoeren en dan onze app naar Heroku uitrollen als alle tests slagen. Het belangrijkste voor onze setup is dat we regels binnen onze CI-pijplijn kunnen configureren om aan te geven waar de app moet worden uitgerold.

Configureren GitLab CI/CD

We kunnen een CI-pijplijn in GitLab programmatisch maken met behulp van een .gitlab-ci.yml bestand. Ons bestand ziet er zo uit:

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 pijplijnen bestaan uit stadia en jobs. Elk stadium kan één of meerdere jobs bevatten. In onze pijplijn hebben we twee stadia: test en deploy. In het test stadium voeren we onze eenheidstests uit in de unit-test-job. In het deploy stadium rollen we onze app uit naar Heroku in de deploy-job.

We kunnen alleen doorstromen naar het volgende stadium als alle jobs in het vorige stadium slagen. Dat betekent dat als de eenheidstests falen, dan wordt de app niet uitgerold, wat een goed ding is! We zouden onze app niet willen uitrollen als deze in een slechte staat is.

U zult opmerken dat de deploy-fase een rules-sectie heeft met enkele conditionele logica. Dit is waar we specificeren naar welke omgeving onze app moet worden gedeployed. Als we op de main-tak zijn, dan deployen we onze productie-app. Als we op de dev-tak zijn, dan deployen we onze staging-app.

U zult ook opmerken dat de deploy-fase verwijst naar verschillende variabelen genaamd $HEROKU_APP_NAME_PRODUCTION, $HEROKU_APP_NAME_STAGING en $HEROKU_API_KEY. Deze zijn opgeslagen als CI/CD-variabelen binnen GitLab.

Als u dit instelt in uw eigen GitLab-account, moet u eerst uw API-sleutel vinden in uw Heroku-account. Binnen uw Heroku-accountinstellingen zou u een sectie voor uw API-sleutel moeten zien. Als u nog geen API-sleutel heeft gegenereerd, genereer er dan nu een.

Heroku API key

Vervolgens, in uw GitLab-project, klikt u op Instellingen > CI/CD > variabelen. Vouw die sectie uit en voeg drie nieuwe variabelen toe:

1. De waarde voor $HEROKU_API_KEY zal de API-sleutel zijn van uw Heroku-account.
2. De waarde voor $HEROKU_APP_NAME_PRODUCTION zal de naam zijn van uw productie-Heroku-app. De naam van mijn productie-app is heroku-gitlab-ci-cd-production, maar aangezien Heroku-appnamen universeel uniek zijn, zal die van u anders zijn.
3. De waarde voor $HEROKU_APP_NAME_STAGING zal de naam zijn van uw staging Heroku-app. De naam van mijn staging-app is heroku-gitlab-ci-cd-staging. Opnieuw, aangezien Heroku-appnamen universeel uniek zijn, zal die van u iets anders zijn.

GitLab CI/CD variables

Daarmee is uw GitLab CI pipeline klaar om te gebruiken! Laten we het uitproberen.

Onze Heroku-app naar de Staging-omgeving deploying

Laten we de dev-tak bekijken en een wijziging aanbrengen in de code van onze app. Ik heb een eenvoudige wijziging aangebracht in de koptekst en meerdere nieuwe regels toegevoegd aan de tekst in de UI. U kunt een vergelijkbare wijziging aanbrengen in uw code.

Nu de wijziging toevoegen, committen en naar de dev-tak pushen. Dit zal de GitLab CI pipeline starten. U kunt de pipeline binnen GitLab bekijken en de voortgang in real-time zien.

GitLab CI pipeline build for the dev branch

Als alles goed gaat, zou u moeten zien dat zowel de test– als de deploy-stages zijn doorgegaan. Nu kunt u uw gehostde Heroku-app bekijken op het URL van de staging-omgeving. De GitLab CI pipeline heeft het deployen van de app voor u verzorgd, dus u zult nu uw wijzigingen live in de staging-omgeving zien!

Demo Heroku app with updated copy

Met een staging-omgeving ingesteld, heeft u nu een geweldige plek om uw code handmatig te testen in een gehostde omgeving. Dit is ook een perfecte plek voor QA-testers of productmanagers om wijzigingen te verifiëren voordat ze naar productie gaan.

Nu kunt u de URL van uw productie-app controleren. U zult merken dat het nog steeds de oude UI laat zien zonder de meest recente wijzigingen. Dit komt omdat de GitLab CI pipeline de wijzigingen alleen naar de staging-omgeving heeft gedeployed, niet naar de productie-omgeving.

We hebben verificerd dat de code er goed uitziet in onze staging-omgeving, dus laten we deze promoveren naar onze productieomgeving.

Onze Heroku-app naar de productieomgeving deployen

Laten we de main-tak bekijken en vervolgens de dev-tak samenvoegen met jouw main-tak. Je kunt dit doen via een pull request of door git merge dev uit te voeren en dan git push.

Dit zal de GitLab CI-pijplijn opnieuw starten, maar deze keer zal het zich voorbereiden op het deployen van jouw productie-app.

GitLab CI pipeline build for the main branch

Je kunt ook alle pijplijnruns bekijken op de Pipelines-pagina in GitLab om de verschillende builds voor jouw dev– en main-takens te zien:

All GitLab CI pipeline builds

Une fois que la pipeline est terminée, bezoek het URL-adres van jouw productie Heroku-app. Je zou nu jouw wijzigingen ook in productie moeten zien. Goed gedaan!

Conclusie

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 en GitLab CI/CD stellen je in staat om al dit automatisch te maken, waardoor jouw DevOps-processen een flits zijn!