Les environnements Gitlab-CI

Pendant le développement d’un logiciel, il peut y avoir de nombreuses étapes jusqu’à ce qu’il soit prêt pour la production. Vous voulez certainement d’abord tester votre code, puis le déployer dans un environnement de test ou de préproduction avant de le publier sur la production.

GitLab-CI a introduit les environments pour permettre de suivre facilement les déploiements pour chacun d’eux. Pour chaque déploiement, vous pouvez voir le commit associé ainsi aue la branche pour laquelle il a été créé. GitLab-CI permet de faire des rollback pour remettre vos environments à l’état avant déploiement.

Il est possible d’indiquer pour chaque environment une url permettant de se rendre directement sur l’application déployée.

Nous verrons qu’il est possible de restreindre des environnements à des branches spécifiques.

Il existe deux types d’environnement:

• Les environnements statiques ont des noms statiques comme staging, testing, development, ou encore production.
• Les environnements dynamiques ont des noms dynamiques utilisant des variables CI/CD

Création d’environnements statiques

Il est possible de créer des environnements statiques soit :

• dans l’interface de gitlab : Operations > Environments > New Environment
• dans votre fichier .gitlab-ci.yml

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  environment:
    name: staging
    url: https://staging.example.com

Choissisez un nom claire permettant d’iddentifier facilement le niveau de votre environnemen.

Introduit dans la version 13.10 de gitlab, il est possible de choisir des noms en dehors de ceux indiqué ci-dessus en ajoutant le mot clé deployment_tier. Cette clé indique le niveau de l’environnement :

deploy:
  script: echo
  environment:
    name: customer-portal
    deployment_tier: production

On peut donc enfin crée des environments multi-clients.

Création d’environnements dynamiques

Cette fois ces environnements ne sont créés que dans le fichier .gitlab-ci.yml:

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com

Variables CI/CD propre aux environments

Lorsque vous créer un environment, vous indiquez son nom et son URL. Si vous souhaitez les utiliser dans vos scripts alors ils sont accessibles via les noms de variables suivants :

• $CI_ENVIRONMENT_NAME.
• $CI_ENVIRONMENT_SLUG. un nom d’environement propre et unique qui peut être utilisé dans les DNS ou les URL.
• $CI_ENVIRONMENT_URL.

Il est possible de surcharger la variable $CI_ENVIRONMENT_NAME mais la variable $CI_ENVIRONMENT_SLUG restera inchangé pour éviter les effets de bords.

Restreindre un environnement à une ou des branches spécifiques

Avec l’ajout de rules gitlab-ci il est possible de restreindre des environnements à des branches définies.

Par exemple si nous souhaitons déployer sur l’environment review\$CI_COMMIT_REF_NAME ci-dessus toutes les branches à l’exeption de la banche master :

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app on $CI_ENVIRONMENT_SLUG"
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com
  only:
    - branches
  except:
    - master

Par contre si on ne souhaite déployer que sur la production que la branche master:

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy on prod"
  environment:
    name: production
    url: https://www.example.com
  only:
    - master
  when: manual

Vous pouvez aussi ajouter la condition when: manual pour ne pas déclencher automatiquement ce déploiement en production.

Stopper un environment

Il est possible de stopper un environment mais pour cela il faut que dans votre ci contienne une étiquette on_stop: nom de l'étape et une action: stop associé:

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review:
  stage: deploy
  script:
    - echo "Remove review app"
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

Il est également possible de stopper un environment au bout d’un certain temps via l’ajout de l’étiquette auto_stop_in: 1 week

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    on_stop: stop_review_app
    auto_stop_in: 1 week
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review_app:
  script: stop-review-app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

Si vous souhaiter que cette durée soit prolongé il faut se rendre dans l’interface de gitlab : Operations > Environments et d’épingler celui-ci.

Faire un rollback d’un environment

Comme dis plus haut il est possible de faire un rollback d’environment. Pour que cela fonctionne correctement il faut que vos scripts le gère correctement.