Comprendre les environnements
Les workflows de déploiement vous permettent d’automatiser les étapes de votre processus de déploiement. Souvent, vous devez exécuter les étapes dans plusieurs environnements distincts. Dans votre entreprise de jouets, vous voulez passer en revue les changements de votre code avant de les déployer dans votre environnement de production.
Dans cette leçon, vous découvrez comment les environnements dans GitHub Actions vous aident à prendre en charge votre propre processus.
Pourquoi avez-vous plusieurs environnements ?
Les processus de déploiement effectuent des changements sur vos ressources Azure, y compris les ressources en cours d’utilisation. Le changement des ressources implique un risque, car les changements que vous déployez peuvent ne pas se comporter comme prévu. Vous pouvez même découvrir qu’ils bloquent votre configuration actuelle.
Pour réduire le risque de problèmes, une bonne pratique est de tester vos changements de manière sécurisée avant de les déployer dans votre environnement de production. Vous réduisez le risque en déployant les changements dans un environnement hors production.
De nombreuses organisations configurent plusieurs environnements hors production où elles déploient progressivement leurs changements avant de les mettre en production. Chaque environnement hors production remplit un rôle spécifique et comporte souvent des barrières qualité spécifiques à franchir pour passer à l’environnement suivant. En cas de problème, par exemple, un test qui échoue, le déploiement s’arrête. Le niveau de confiance des changements augmente à mesure que votre déploiement passe par les différents environnements.
Les environnements courants sont les suivants :
Développement : un environnement de développement est généralement utilisé par les développeurs pour essayer leurs changements et les itérer rapidement sur leur travail.
Les environnements de développement ont souvent des contrôles minimaux pour que les membres de l’équipe puissent facilement tester leurs idées. Vous pouvez utiliser un environnement de développement pour tester un certain paramètre de configuration sur une ressource ou pour voir comment configurer de manière sécurisée un nouveau site web avec une base de données de back-end. Un grand nombre de ces changements et essais peuvent ne pas persister dans votre processus de déploiement, car vous éliminez les idées qui ne marchent pas.
Dans certaines équipes, vous pouvez même configurer un environnement de développement distinct pour chaque membre de l’équipe, afin qu’ils ne se gênent pas mutuellement quand ils travaillent sur de nouvelles fonctionnalités.
Les environnements de développement sont parfois également appelés environnements de bac à sable.
Test : un environnement de test est conçu pour exécuter des tests manuels ou automatisés sur vos changements.
Les environnements de test peuvent être utilisés dans un processus d’intégration continue. Dès que vous déployez un changement dans un environnement de test, vous pouvez lui appliquer des tests automatisés. Si tous les tests automatisés réussissent, le changement peut être fusionné dans la branche primaire du projet. Les tests automatisés vérifient généralement les fonctionnalités principales du système, ainsi que des éléments comme les violations de stratégie dans les ressources nouvellement déployées.
Vous pouvez également créer des environnements de test dédiés à des types de tests spécifiques, comme les tests de performances et de sécurité.
Intégration : un environnement d’intégration peut vous aider à tester les points d’intégration avec d’autres systèmes.
Vous pouvez simuler des transactions de bout en bout dans un environnement d’intégration. Ces tests s’exécutent souvent automatiquement, mais de nombreuses organisations font également des tests manuels sur cet environnement.
Les environnements d’intégration sont parfois également appelés environnements de test d’intégration système (SIT).
Test d’acceptation utilisateur : un environnement de test d’acceptation utilisateur (UAT) est utilisé pour la validation manuelle, généralement par les parties prenantes de l’entreprise plutôt que par les développeurs. Dans la validation manuelle, une personne parcourt toute la solution pour vérifier qu’elle se comporte comme prévu et qu’elle répond aux besoins de l’entreprise. Cette personne approuve ensuite les changements pour que le déploiement puisse continuer.
Préproduction : un environnement de préproduction est souvent le miroir de l’environnement de production, avec la même configuration et les mêmes références SKU de ressources. Il est utilisé comme contrôle final pour vérifier comment le déploiement de production se comporte pendant et après l’application du changement. Il peut également être utilisé pour vérifier si un temps d’arrêt est à prévoir pendant le déploiement en production.
Les environnements de préproduction sont parfois également appelés environnements intermédiaires.
Production : votre environnement de production est celui qu’utilisent les utilisateurs finaux de l’application. Il s’agit de l’environnement en direct que vous voulez protéger et maintenir opérationnel autant que possible.
Dans certaines organisations, vous pouvez avoir plusieurs environnements de production. Par exemple, vous pouvez avoir des environnements de production dans différentes régions géographiques ou pour servir différents groupes de clients.
Démo : votre équipe peut également créer des environnements de démonstration (démo) pour montrer l’application aux utilisateurs finaux, pour les utiliser dans des formations ou pour que les équipes de vente puissent présenter certaines fonctionnalités aux clients potentiels. Vous pouvez même avoir plusieurs environnements de démo qui remplissent des objectifs différents. Un environnement de démo est souvent un réplica allégé de votre environnement de production, avec des données client factices.
Environnements dans votre organisation
Vous pouvez voir des variantes de ces environnements. Certaines organisations utilisent seulement quelques environnements, mais d’autres en utilisent beaucoup plus. Le nombre et le type d’environnements que vous utilisez dépendent de la solution que vous déployez, de la taille de l’équipe qui génère la solution et de l’importance de la charge de travail.
Parfois, un seul environnement prend le rôle de plusieurs des environnements listés plus haut. Dans d’autres cas, vous pouvez avoir un workflow complexe qui se déploie sur plusieurs environnements, certains en parallèle et d’autres en série. Certaines organisations vont même jusqu’à supprimer ou déprovisionner automatiquement les environnements dont elles ne se servent plus, puis les redéploient quand elles en ont besoin.
Quelle que soit la liste d’environnements que choisit votre organisation, l’objectif est d’améliorer le niveau de confiance d’un changement à mesure qu’il avance dans votre workflow de déploiement. Quand un changement ne répond pas à vos exigences de qualité, vous devez pouvoir en arrêter le déploiement dans les environnements suivants de la chaîne.
Dans votre entreprise de jouets, vous décidez de commencer avec un ensemble de base d’environnements pour votre site web. En plus de votre environnement de production, vous créez un environnement hors production nommé Test :
Vous mettez à jour votre workflow pour déployer votre code Bicep dans votre environnement de test et y exécuter des tests de base. Si cet effort porte ses fruits, vous pouvez alors procéder au déploiement dans votre environnement de production.
Environnements de workflow
GitHub Actions a également le concept d’environnement. Vous créez un environnement GitHub Actions pour représenter l’environnement que vous avez dans Azure. Quand vous définissez votre workflow dans un fichier YAML, vous pouvez lier des travaux à un environnement spécifique. En utilisant des environnements, vous obtenez des fonctionnalités supplémentaires dans votre workflow.
Règles de protection
Un environnement dans GitHub Actions peut avoir des règles de protection configurées. Chaque fois que l’environnement est utilisé dans un travail de votre workflow, GitHub Actions vérifie que ces règles sont respectées avant le démarrage de l’exécution du travail.
Par exemple, vous pouvez configurer des évaluations manuelles sur votre environnement de production. Avant le démarrage d’un déploiement de production, le réviseur désigné reçoit une notification. Cette personne peut vérifier manuellement que vos stratégies et procédures sont respectées avant le début du déploiement. Par exemple, l’approbateur peut vérifier que tout fonctionne comme prévu dans l’environnement de préproduction avant d’approuver le déploiement.
Par ailleurs, vous pouvez exécuter une vérification automatisée pour valider la branche qui a envoyé votre changement. Si le changement ne se trouve pas sur votre branche primaire, vous pouvez configurer GitHub pour empêcher son déploiement dans votre environnement de production.
Secrets
GitHub Actions vous permet de stocker des secrets à utiliser seulement dans un environnement spécifique. Plus d’informations sur la gestion des secrets sont présentées plus loin dans ce module.
Historique de déploiement
GitHub Actions suit l’historique des déploiements effectués dans un environnement. Cet historique vous permet de suivre facilement ce qui se passe dans l’environnement au fil du temps. Il vous permet même de suivre un déploiement jusqu’à une validation dans votre dépôt. Cette fonctionnalité peut être utile si vous avez un problème avec un déploiement et devez identifier le changement qui a conduit au problème.
Création d’environnements
Vous pouvez créer un environnement à partir de l’interface web GitHub.
Quand votre workflow référence un environnement qui n’existe pas, GitHub Actions le crée automatiquement pour vous. Cette fonctionnalité peut affecter la sécurité de votre dépôt GitHub, car le nouvel environnement n’a aucune règle de protection configurée. Il vaut mieux créer vous-même un environnement avec l’interface web GitHub pour pouvoir avoir un contrôle total sur sa sécurité.
Lier un travail de déploiement à un environnement
Dans votre définition de workflow de déploiement, vous pouvez faire référence à un environnement à l’aide de la propriété environment :
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
Dans cet exemple, le travail nommé deploy est lié à l’environnement Test.
Environnements et connexions à Azure
Quand vous utilisez plusieurs environnements, vous devez rendre indépendants les environnements les uns des autres. Par exemple, le site web de votre environnement de développement ne doit pas pouvoir accéder à une base de données dans votre environnement de production.
Le même principe s’applique également au workflow de déploiement. Vous devez créer des connexions de service distinctes pour chaque environnement. Le respect de cette pratique ajoute une autre couche de protection pour garantir que vos déploiements hors production n’affectent pas votre environnement de production.
Les identités de charge de travail doivent recevoir des autorisations spécifiques pour effectuer le déploiement uniquement sur l’abonnement et le groupe de ressources utilisés par cet environnement :
Important
Utilisez une identité de charge de travail distincte pour chaque environnement où vous prévoyez un déploiement. Accordez à l’identité de charge de travail les autorisations minimales dont elle a besoin pour déployer dans son environnement, et aucune autre.
Pensez aussi à séparer vos environnements dans Azure. Au minimum, vous devez créer un groupe de ressources distinct pour chaque environnement. Dans de nombreux cas, mieux vaut créer des abonnements Azure distincts pour chaque environnement. Vous pouvez ensuite créer plusieurs groupes de ressources dans l’abonnement de chaque environnement.
Appliquez des attributions de rôles Azure pour que les utilisateurs et les identités de charge de travail puissent accéder uniquement aux environnements qui sont nécessaires. Limitez l’accès à votre environnement de production à un petit nombre de personnes et à l’identité de charge de travail de déploiement de cet environnement.
Informations d’identification fédérées pour les environnements
Quand votre identité de charge de travail se connecte à Azure à partir de votre workflow de déploiement, elle utilise des informations d’identification fédérées pour s’authentifier en toute sécurité sans secrets ni clés. Dans les modules précédents de ce parcours d’apprentissage, vos informations d’identification fédérées ont accordé l’accès à vos workflows de déploiement quand ils ont été déployés à partir de la branche principale de votre référentiel Git.
Quand vous procédez au déploiement dans un environnement au sein de votre workflow, vous devez utiliser des informations d’identification fédérées délimitées à cet environnement.
Dans ce module, votre workflow comprend plusieurs travaux, dont beaucoup se connectent et effectuent des déploiements sur Azure. Certains travaux utilisent des environnements et certains n’en utilisent pas. Par conséquent, vous créez deux informations d’identification fédérées pour chacune de vos identités de charge de travail : des informations d’identification étendues à l’environnement et des informations d’identification étendues à la branche principale.