

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Comprendre les DevOps environnements
<a name="understanding-the-devops-environments"></a>

Pour comprendre les stratégies de branchement, vous devez comprendre l'objectif et les activités de chaque environnement. La mise en place de plusieurs environnements vous permet de séparer les activités de développement en plusieurs étapes, de surveiller ces activités et d'empêcher le lancement involontaire de fonctionnalités non approuvées. Vous pouvez en avoir un ou plusieurs Comptes AWS dans chaque environnement. 

La plupart des organisations ont défini plusieurs environnements à utiliser. Cependant, le nombre d'environnements peut varier en fonction de l'organisation et des politiques de développement logiciel. Cette série de documentation part du principe que vous disposez des cinq environnements courants suivants qui couvrent votre pipeline de développement, bien qu'ils puissent porter des noms différents :
+ **Sandbox** : environnement dans lequel les développeurs écrivent du code, commettent des erreurs et réalisent des travaux de validation de concept.
+ **Développement** : environnement dans lequel les développeurs intègrent leur code pour s'assurer qu'il fonctionne comme une seule et même application cohérente.
+ **Tests** : environnement dans lequel les équipes d'assurance qualité ou les tests d'acceptation ont lieu. Les équipes effectuent souvent des tests de performance ou d'intégration dans cet environnement.
+ **Stage** : environnement de préproduction dans lequel vous confirmez que le code et l'infrastructure fonctionnent comme prévu dans des circonstances équivalentes à celles de la production. Cet environnement est configuré pour être aussi similaire que possible à l'environnement de production.
+ **Production** : environnement qui gère le trafic provenant de vos utilisateurs finaux et de vos clients.

Cette section décrit chaque environnement en détail. Il décrit également les étapes de création, les étapes de déploiement et les critères de sortie pour chaque environnement afin que vous puissiez passer au suivant. L'image suivante montre ces environnements dans l'ordre.

![\[DevOps Environnements courants dans un ordre séquentiel\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/choosing-git-branch-approach/images/devops-environments.png)


**Topics**
+ [Environnement Sandbox](sandbox-environment.md)
+ [Environnement de développement](development-environment.md)
+ [Environnement de test](testing-environment.md)
+ [Environnement de mise en scène](staging-environment.md)
+ [Environnement de production](production-environment.md)

# Environnement Sandbox
<a name="sandbox-environment"></a>

L'*environnement sandbox est l'*endroit où les développeurs écrivent du code, commettent des erreurs et réalisent des travaux de validation de concept. Vous pouvez effectuer un déploiement dans un environnement sandbox à partir d'un poste de travail local ou via un script sur un poste de travail local.

## Accès
<a name="access"></a>

Les développeurs doivent avoir un accès complet à l'environnement sandbox.

## Étapes de construction
<a name="build-steps"></a>

Les développeurs exécutent manuellement le build sur leurs postes de travail locaux lorsqu'ils sont prêts à déployer des modifications dans l'environnement sandbox.

1. Utilisez [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) pour rechercher des informations sensibles

1. Lint le code source

1. Compilez et compilez le code source, le cas échéant

1. Réaliser des tests unitaires

1. Réaliser une analyse de la couverture du code

1. Effectuez une analyse de code statique

1. Construire une infrastructure sous forme de code (IaC)

1. Réaliser une analyse de sécurité IaC

1. Extraire des licences open source

1. Publier des artefacts de construction

## Étapes de déploiement
<a name="deployment-steps"></a>

Si vous utilisez les modèles Gitflow ou Trunk, les étapes de déploiement démarrent automatiquement lorsqu'une `feature` branche est correctement créée dans l'environnement sandbox. Si vous utilisez le modèle GitHub Flow, vous devez exécuter manuellement les étapes de déploiement suivantes. Les étapes de déploiement dans l'environnement sandbox sont les suivantes :

1. Télécharger les artefacts publiés

1. Effectuer le versionnement de la base de données

1. Effectuer le déploiement d'iAc

1. Réaliser des tests d'intégration

## Attentes avant de passer à l'environnement de développement
<a name="expectations-before-moving-to-the-development-environment"></a>
+ Création réussie de la `feature` branche dans l'environnement sandbox
+ Un développeur a déployé et testé manuellement la fonctionnalité dans l'environnement sandbox

# Environnement de développement
<a name="development-environment"></a>

L'*environnement de développement est l'*endroit où les développeurs intègrent leur code afin de garantir qu'il fonctionne comme une seule application cohérente. Dans Gitflow, l'environnement de développement contient les dernières fonctionnalités incluses par demande de fusion et est prêt à être publié. Dans les stratégies GitHub Flow et Trunk, l'environnement de développement est considéré comme un environnement de test, et la base de code peut être instable et ne pas convenir au déploiement en production.

## Accès
<a name="access"></a>

Attribuez des autorisations selon le principe du moindre privilège. Le *moindre privilège* est la bonne pratique de sécurité qui consiste à accorder les autorisations minimales nécessaires à l'exécution d'une tâche. Les développeurs devraient avoir moins accès à l'environnement de développement qu'à l'environnement sandbox.

## Étapes de construction
<a name="build-steps"></a>

La création d'une demande de fusion vers la `develop` branche (Gitflow) ou la `main` branche (Trunk ou GitHub Flow) lance automatiquement la construction.

1. Utilisez [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) pour rechercher des informations sensibles

1. Lint le code source

1. Compilez et compilez le code source, le cas échéant

1. Réaliser des tests unitaires

1. Réaliser une analyse de la couverture du code

1. Effectuez une analyse de code statique

1. Construisez iAc

1. Réaliser une analyse de sécurité IaC

1. Extraire des licences open source

## Étapes de déploiement
<a name="deployment-steps"></a>

Si vous utilisez le modèle Gitflow, les étapes de déploiement démarrent automatiquement lorsqu'une `develop` branche est correctement créée dans l'environnement de développement. Si vous utilisez le modèle GitHub Flow ou le modèle Trunk, les étapes de déploiement démarrent automatiquement lorsqu'une demande de fusion est créée pour la `main` branche. Les étapes de déploiement dans l'environnement de développement sont les suivantes :

1. Téléchargez les artefacts publiés à partir des étapes de construction

1. Effectuer le versionnement de la base de données

1. Effectuer le déploiement d'iAc

1. Réaliser des tests d'intégration

## Attentes avant de passer à l'environnement de test
<a name="expectations-before-moving-to-the-testing-environment"></a>
+ Création et déploiement réussis de la `develop` branche (Gitflow) ou de la `main` branche (Trunk ou GitHub Flow) dans l'environnement de développement
+ Les tests unitaires passent à 100 %
+ Construction réussie d'iAc
+ Les artefacts de déploiement ont été créés avec succès
+ Un développeur a effectué une vérification manuelle pour confirmer que la fonctionnalité fonctionne comme prévu

# Environnement de test
<a name="testing-environment"></a>

Le personnel chargé de l'assurance qualité (AQ) utilise l'environnement de test pour valider les fonctionnalités. Ils approuvent les modifications une fois les tests terminés. Après approbation, la branche passe à l'environnement suivant, celui du stage. Dans Gitflow, cet environnement et les autres environnements supérieurs ne sont disponibles que pour le déploiement à partir de `release` succursales. Une `release` branche est basée sur une `develop` branche qui contient les fonctionnalités planifiées.

## Accès
<a name="access"></a>

Attribuez des autorisations selon le principe du moindre privilège. Les développeurs devraient avoir moins accès à l'environnement de test qu'à l'environnement de développement. Le personnel chargé de l'assurance qualité a besoin d'autorisations suffisantes pour tester la fonctionnalité.

## Étapes de construction
<a name="build-steps"></a>

Le processus de compilation dans cet environnement ne s'applique qu'aux corrections de bogues lors de l'utilisation de la stratégie Gitflow. La création d'une demande de fusion adressée à la `bugfix` branche lance automatiquement la construction.

1. Utilisez [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) pour rechercher des informations sensibles

1. Lint le code source

1. Compilez et compilez le code source, le cas échéant

1. Réaliser des tests unitaires

1. Réaliser une analyse de la couverture du code

1. Effectuez une analyse de code statique

1. Construisez iAc

1. Réaliser une analyse de sécurité IaC

1. Extraire des licences open source

## Étapes de déploiement
<a name="deployment-steps"></a>

Lancez automatiquement le déploiement de la `release` branche (Gitflow) ou de la `main` branche (Trunk ou GitHub Flow) dans l'environnement de test après le déploiement dans l'environnement de développement. Les étapes de déploiement dans l'environnement de test sont les suivantes :

1. Déployez la `release` branche (Gitflow) ou la `main` branche (Trunk ou GitHub Flow) dans l'environnement de test

1. Pause pour approbation manuelle par le personnel désigné

1. Télécharger les artefacts publiés

1. Effectuer le versionnement de la base de données

1. Effectuer le déploiement d'iAc

1. Réaliser des tests d'intégration

1. Réaliser des tests de performance

1. Approbation d'assurance qualité

## Attentes avant de passer à l'environnement de mise en scène
<a name="expectations-before-moving-to-the-staging-environment"></a>
+ Les équipes de développement et d'assurance qualité ont effectué suffisamment de tests pour répondre aux exigences de votre organisation.
+ L'équipe de développement a résolu tous les bogues découverts par le biais d'une `bugfix` branche.

# Environnement de mise en scène
<a name="staging-environment"></a>

L'*environnement* de préparation est configuré pour être identique à l'environnement de production. Par exemple, l'étendue et la taille de la configuration des données doivent être similaires à celles des charges de travail de production. Utilisez l'environnement intermédiaire pour vérifier que le code et l'infrastructure fonctionnent comme prévu. Cet environnement est également le choix privilégié pour les cas d'utilisation professionnels, tels que les avant-premières ou les démonstrations destinées aux clients.

## Accès
<a name="access"></a>

Attribuez des autorisations selon le principe du moindre privilège. Les développeurs doivent avoir le même accès à l'environnement de préparation qu'à l'environnement de production.

## Étapes de construction
<a name="build-steps"></a>

Aucune. Les mêmes artefacts que ceux utilisés dans l'environnement de test sont réutilisés dans l'environnement de préparation.

## Étapes de déploiement
<a name="deployment-steps"></a>

Lancez automatiquement le déploiement de la `release` branche (Gitflow) ou de la `main` branche (Trunk ou GitHub Flow) dans l'environnement de test après approbation et déploiement dans l'environnement de test. Les étapes de déploiement dans l'environnement de préparation sont les suivantes :

1. Déployez la `release` branche (Gitflow) ou la `main` branche (Trunk ou GitHub Flow) dans l'environnement de préparation

1. Pause pour approbation manuelle par le personnel désigné

1. Télécharger les artefacts publiés

1. Effectuer le versionnement de la base de données

1. Effectuer le déploiement d'iAc

1. (Facultatif) Effectuez des tests d'intégration

1. (Facultatif) Effectuer un test de charge

1. Obtenir l'approbation des approbateurs requis en matière de développement, d'assurance qualité, de produit ou d'entreprise

## Attentes avant de passer à l'environnement de production
<a name="expectations-before-moving-to-the-production-environment"></a>
+ Une version équivalente à la production a été déployée avec succès dans l'environnement de préparation
+ (Facultatif) Les tests d'intégration et de charge ont été réussis

# Environnement de production
<a name="production-environment"></a>

L'*environnement de production* prend en charge le produit publié, en gérant les données réelles des clients réels. Il s'agit d'un environnement protégé auquel l'accès est attribué par le moindre privilège et l'accès élevé ne doit être autorisé que dans le cadre d'un processus d'exception audité pendant une période limitée.

## Accès
<a name="access"></a>

Dans l'environnement de production, les développeurs doivent disposer d'un accès limité en lecture seule à l'AWS Management Console. Par exemple, les développeurs devraient être en mesure d'accéder aux données du journal pour les day-to-day opérations. Toutes les mises en production doivent être soumises à une étape d'approbation avant le déploiement.

## Étapes de construction
<a name="build-steps"></a>

Aucune. Les mêmes artefacts utilisés dans les environnements de test et de préparation sont réutilisés dans l'environnement de production.

## Étapes de déploiement
<a name="deployment-steps"></a>

Lancez automatiquement le déploiement de la `release` branche (Gitflow) ou de la `main` branche (Trunk ou GitHub Flow) dans l'environnement de production après approbation et déploiement dans l'environnement de préparation. Les étapes de déploiement dans l'environnement de production sont les suivantes :

1. Déployez la `release` branche (Gitflow) ou la `main` branche (Trunk ou GitHub Flow) dans l'environnement de production

1. Pause pour approbation manuelle par le personnel désigné

1. Télécharger les artefacts publiés

1. Effectuer le versionnement de la base de données

1. Effectuer le déploiement d'iAc