doc-locale/fr-fr/ci/review_apps/_index.md
{{< details >}}
{{< /details >}}
Les environnements éphémères sont des environnements de test temporaires qui sont créés automatiquement pour chaque branche ou merge request. Vous pouvez prévisualiser et valider les modifications sans avoir à configurer un environnement de développement local.
Basés sur les environnements dynamiques, les environnements éphémères fournissent un environnement unique pour chaque branche ou merge request.
Ces environnements contribuent à rationaliser le workflow de développement en :
[!note] Si vous disposez d'un cluster Kubernetes, vous pouvez configurer les environnements éphémères automatiquement à l'aide de Auto DevOps.
Un workflow d'environnement éphémère pourrait ressembler à :
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart TD
accTitle: Review app workflow
accDescr: Diagram showing how review apps fit into the GitLab development workflow.
subgraph Development["Development"]
TopicBranch["Create topic branch"]
Commit["Make code changes"]
CreateMR["Create merge request"]
end
subgraph ReviewAppCycle["Review app cycle"]
direction LR
Pipeline["CI/CD pipeline runs"]
ReviewApp["Review app deployed"]
Testing["Review and testing"]
Feedback["Feedback provided"]
NewCommits["Address feedback
with new commits"]
end
subgraph Deployment["Deployment"]
Approval["Merge request approved"]
Merge["Merged to default branch"]
Production["Deployed to production"]
end
TopicBranch --> Commit
Commit --> CreateMR
CreateMR --> Pipeline
Pipeline --> ReviewApp
ReviewApp --> Testing
Testing --> Feedback
Feedback --> NewCommits
NewCommits --> Pipeline
Testing --> Approval
Approval --> Merge
Merge --> Production
Configurez les environnements éphémères lorsque vous souhaitez fournir un environnement de prévisualisation de votre application pour chaque branche ou merge request.
Prérequis :
Pour configurer les environnements éphémères dans votre projet :
Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre projet.
Dans la barre latérale gauche, sélectionnez Version > Éditeur de pipeline.
Dans votre fichier .gitlab-ci.yml, ajoutez un job qui crée un environnement dynamique. Vous pouvez utiliser une variable CI/CD prédéfinie pour différencier chaque environnement. Par exemple, en utilisant la variable CI/CD prédéfinie CI_COMMIT_REF_SLUG :
review_app:
stage: deploy
script:
- echo "Deploy to review app environment"
# Add your deployment commands here
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_COMMIT_REF_SLUG.example.com
rules:
- if: $CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
facultatif. Ajoutez when: manual au job pour ne déployer les environnements éphémères que manuellement.
facultatif. Ajoutez un job pour arrêter l'environnement éphémère lorsqu'il n'est plus nécessaire.
Saisissez un message de commit et sélectionnez Valider les modifications.
GitLab fournit un modèle intégré configuré par défaut pour les pipelines de merge request.
Pour utiliser et personnaliser ce modèle :
Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre projet.
Dans la barre latérale gauche, sélectionnez Opération > Environnements.
Sélectionnez Activer les applications de revue.
Dans la boîte de dialogue Activer les applications de revue qui apparaît, copiez le modèle YAML :
deploy_review:
stage: deploy
script:
- echo "Add script here that deploys the code to your infrastructure"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
Sélectionnez Version > Éditeur de pipeline.
Collez le modèle dans votre fichier .gitlab-ci.yml.
Personnalisez le modèle en fonction de vos besoins de déploiement :
Par exemple, pour un déploiement sur Heroku :
deploy_review:
stage: deploy
image: ruby:latest
script:
- apt-get update -qy
- apt-get install -y ruby-dev
- gem install dpl
- dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$HEROKU_APP_NAME.herokuapp.com
on_stop: stop_review_app
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
Cette configuration met en place un déploiement automatisé sur Heroku chaque fois qu'un pipeline s'exécute pour une merge request. Elle utilise l'outil de déploiement Ruby dpl pour gérer le processus et crée un environnement éphémère dynamique accessible via l'URL spécifiée.
Saisissez un message de commit et sélectionnez Valider les modifications.
Vous pouvez configurer vos environnements éphémères pour qu'ils soient arrêtés manuellement ou automatiquement afin de préserver les ressources.
Pour plus d'informations sur l'arrêt des environnements pour les environnements éphémères, consultez Arrêt d'un environnement.
Pour configurer les environnements éphémères afin qu'ils s'arrêtent automatiquement lorsque la merge request associée est fusionnée ou que la branche est supprimée :
on_stop à votre job de déploiement.environment:action: stop.when: manual au job d'arrêt pour permettre d'arrêter manuellement l'environnement éphémère à tout moment.Par exemple :
# In your .gitlab-ci.yml file
deploy_review:
# Other configuration...
environment:
name: review/${CI_COMMIT_REF_NAME}
url: https://${CI_ENVIRONMENT_SLUG}.example.com
on_stop: stop_review_app # References the stop_review_app job
stop_review_app:
stage: deploy
script:
- echo "Stop review app"
# Add your cleanup commands here
environment:
name: review/${CI_COMMIT_REF_NAME}
action: stop
when: manual # Makes this job manually triggerable
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
Pour configurer les environnements éphémères afin qu'ils s'arrêtent automatiquement après une période de temps, ajoutez le mot-clé auto_stop_in à votre job de déploiement :
# In your .gitlab-ci.yml file
review_app:
script: deploy-review-app
environment:
name: review/$CI_COMMIT_REF_SLUG
auto_stop_in: 1 week # Stops after one week of inactivity
rules:
- if: $CI_MERGE_REQUEST_ID
Pour déployer et accéder aux environnements éphémères :
Ces projets illustrent différentes implémentations d'environnements éphémères :
Autres exemples d'environnements éphémères :
Les cartes de routes vous permettent de naviguer directement depuis les fichiers sources vers leurs pages publiques correspondantes dans l'environnement éphémère. Cette fonctionnalité facilite la prévisualisation de modifications spécifiques dans vos merge requests.
Lorsqu'elles sont configurées, les cartes de routes ajoutent des liens contextuels vous permettant d'afficher la version de l'environnement éphémère des fichiers correspondant à vos modèles de correspondance. Ces liens apparaissent dans :
Pour configurer les cartes de routes :
.gitlab/route-map.yml.La carte de routes est un tableau YAML dans lequel chaque entrée fait correspondre un chemin source à un chemin public.
Chaque correspondance dans la carte de routes suit ce format :
- source: 'path/to/source/file' # Source file in repository
public: 'path/to/public/page' # Public page on the website
Vous pouvez utiliser deux types de correspondance :
Pour la correspondance par motif avec des expressions régulières :
^ et $ sont implicites).() qui peuvent être référencés dans le chemin public.\N dans l'ordre d'occurrence (\1, \2, etc.)./) en \/ et les points (.) en \..GitLab évalue les correspondances dans l'ordre de définition. La première expression source qui correspond détermine le chemin public.
L'exemple suivant montre une carte de routes pour Middleman, un générateur de sites statiques utilisé pour le site web de GitLab :
# Team data
- source: 'data/team.yml' # data/team.yml
public: 'team/' # team/
# Blogposts
- source: /source\/posts\/([0-9]{4})-([0-9]{2})-([0-9]{2})-(.+?)\..*/ # source/posts/2017-01-30-around-the-world-in-6-releases.html.md.erb
public: '\1/\2/\3/\4/' # 2017/01/30/around-the-world-in-6-releases/
# HTML files
- source: /source\/(.+?\.html).*/ # source/index.html.haml
public: '\1' # index.html
# Other files
- source: /source\/(.*)/ # source/images/blogimages/around-the-world-in-6-releases-cover.png
public: '\1' # images/blogimages/around-the-world-in-6-releases-cover.png
Dans cet exemple :
source/index.html.haml correspond à /source\/(.+?\.html).*/ plutôt qu'à l'expression générique /source\/(.*)/. Cela produit un chemin public de index.html au lieu de index.html.haml.Utilisez les cartes de routes pour naviguer directement depuis les fichiers sources vers leurs pages correspondantes dans votre environnement éphémère.
Prérequis :
.gitlab/route-map.yml.Pour afficher les pages mappées depuis le widget de merge request :
Pour afficher une page mappée depuis un fichier :
Pour afficher les pages mappées depuis un commit :
[!note] Les pipelines de résultats fusionnés créent un commit interne qui fusionne votre branche avec la branche cible. Pour accéder aux liens des environnements éphémères pour ces pipelines, utilisez le commit de l'onglet Pipelines, et non celui de l'onglet Validation.