doc-locale/fr-fr/ci/environments/deployments.md
{{< details >}}
{{< /details >}}
Lorsque vous déployez une version de votre code dans un environnement, vous créez un déploiement. Il n'y a généralement qu'un seul déploiement actif par environnement.
GitLab :
Si vous disposez d'un service de déploiement tel que Kubernetes associé à votre projet, vous pouvez l'utiliser pour faciliter vos déploiements.
Une fois un déploiement créé, vous pouvez le déployer progressivement auprès des utilisateurs.
Vous pouvez créer un job qui nécessite qu'une personne démarre manuellement le déploiement. Par exemple :
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
environment:
name: production
url: https://example.com
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
when: manual
L'action when: manual :
<environment>.deploy_prod doit être déclenché manuellement.Vous pouvez trouver Exécution ({{< icon name="play" >}}) dans les vues des pipelines, des environnements, des déploiements et des jobs.
GitLab peut suivre les merge requests nouvellement incluses par déploiement. Lorsqu'un déploiement réussit, le système calcule les diff de commits entre le dernier déploiement et le déploiement précédent. Vous pouvez récupérer les informations de suivi via l'API Deployment ou les consulter dans un pipeline post-merge sur les pages de merge request.
Pour activer le suivi, configurez votre environnement de façon à ce que l'une ou l'autre des conditions suivantes soit remplie :
Le nom d'environnement n'utilise pas de dossiers avec / (environnements de longue durée ou de niveau supérieur).
Le niveau d'environnement est soit production soit staging.
Voici quelques exemples de configurations utilisant le mot-clé environment dans .gitlab-ci.yml :
# Trackable
environment: production
environment: production/aws
environment: development
# Non Trackable
environment: review/$CI_COMMIT_REF_SLUG
environment: testing/aws
Les modifications de configuration s'appliquent uniquement aux nouveaux déploiements. Les enregistrements de déploiement existants ne comportent pas de merge requests liées ou déliées.
Une référence dans le dépôt Git est sauvegardée pour chaque déploiement, de sorte que connaître l'état de vos environnements actuels est à portée d'une commande git fetch.
Dans votre configuration Git, ajoutez au bloc [remote "<your-remote>"] une ligne fetch supplémentaire :
fetch = +refs/environments/*:refs/remotes/origin/environments/*
Lorsqu'un nouveau déploiement se produit dans votre projet, GitLab crée une référence Git spéciale vers le déploiement. Ces références Git étant alimentées depuis le dépôt GitLab distant, certaines opérations Git, telles que git-fetch et git-pull, peuvent devenir plus lentes à mesure que le nombre de déploiements dans votre projet augmente.
Pour maintenir l'efficacité de vos opérations Git, GitLab ne conserve que les références de déploiement récentes (jusqu'à 50 000) et supprime le reste des anciennes références de déploiement. Les déploiements archivés restent disponibles, dans l'interface utilisateur ou via l'API, à des fins d'audit. De plus, vous pouvez toujours récupérer le commit déployé depuis le dépôt en spécifiant le SHA du commit (par exemple, git checkout <deployment-sha>), même après l'archivage.
[!note] GitLab conserve tous les commits sous forme de refs
keep-aroundafin que les commits déployés ne soient pas supprimés par le ramasse-miettes, même s'ils ne sont pas référencés par les références de déploiement.
Lorsque vous restaurez un déploiement sur un commit spécifique, un nouveau déploiement est créé. Ce déploiement possède son propre identifiant de job unique. Il pointe vers le commit vers lequel vous effectuez la restauration.
Pour que la restauration réussisse, le processus de déploiement doit être défini dans le script du job.
Seuls les jobs de déploiement sont exécutés. Dans les cas où un job précédent génère des artefacts qui doivent être régénérés lors du déploiement, vous devez exécuter manuellement les jobs nécessaires depuis la page des pipelines. Par exemple, si vous utilisez Terraform et que vos commandes plan et apply sont séparées en plusieurs jobs, vous devez exécuter manuellement les jobs pour déployer ou effectuer une restauration.
En cas de problème avec un déploiement, vous pouvez le réessayer ou le restaurer.
Pour réessayer ou restaurer un déploiement :
[!note] Si vous avez empêché les jobs de déploiement obsolètes dans votre projet, les boutons de restauration peuvent être masqués ou désactivés. Dans ce cas, consultez les nouvelles tentatives de job pour les déploiements de restauration.
Lorsque vous travaillez avec des déploiements, vous pouvez rencontrer les problèmes suivants.
GitLab supprime les anciennes références de déploiement pour maintenir les performances de votre dépôt Git.
Si vous devez restaurer des références Git archivées sur GitLab Self-Managed, demandez à un administrateur d'exécuter la commande suivante dans la console Rails :
Project.find_by_full_path(<your-project-full-path>).deployments.where(archived: true).each(&:create_ref)
GitLab pourrait abandonner cette prise en charge à l'avenir pour des raisons de performance. Vous pouvez ouvrir un ticket dans le GitLab Issue Tracker pour discuter du comportement de cette fonctionnalité.