Tools/Ansible/Infrastructure As Code : Différence entre versions
| Ligne 20 : | Ligne 20 : | ||
Git est un système de contrôle de version distribué (DVCS, Distributed Version Control System) qui permet aux développeurs de gérer les modifications apportées aux fichiers d'un projet de manière collaborative. Chaque révision d'un fichier est validée dans le système. Les anciennes versions des fichiers peuvent être restaurées, et un journal de l'auteur des modifications est conservé. | Git est un système de contrôle de version distribué (DVCS, Distributed Version Control System) qui permet aux développeurs de gérer les modifications apportées aux fichiers d'un projet de manière collaborative. Chaque révision d'un fichier est validée dans le système. Les anciennes versions des fichiers peuvent être restaurées, et un journal de l'auteur des modifications est conservé. | ||
Les systèmes de contrôle de version présentent de nombreux avantages, notamment : | Les systèmes de contrôle de version présentent de nombreux avantages, notamment : | ||
| − | + | * la possibilité de réviser et de restaurer les anciennes versions des fichiers ; | |
| − | + | * la possibilité de comparer deux versions du même fichier pour identifier les modifications ; | |
| − | + | * un enregistrement ou un journal de l'auteur des modifications, ainsi que le moment où ces modifications ont été apportées ; | |
| − | + | * des mécanismes permettant à plusieurs utilisateurs de modifier des fichiers de manière collaborative, de résoudre les modifications conflictuelles et de fusionner les modifications ensemble. | |
Git est un système de contrôle de version distribué. Chaque développeur peut commencer par cloner un projet partagé existant à partir d'un dépôt distant. Le clonage d'un projet crée une copie complète du dépôt distant d'origine en tant que dépôt local. Il s'agit d'une copie locale de l'intégralité de l'historique des fichiers dans le système de contrôle de version, et pas seulement de l'instantané le plus récent des fichiers de projet. | Git est un système de contrôle de version distribué. Chaque développeur peut commencer par cloner un projet partagé existant à partir d'un dépôt distant. Le clonage d'un projet crée une copie complète du dépôt distant d'origine en tant que dépôt local. Il s'agit d'une copie locale de l'intégralité de l'historique des fichiers dans le système de contrôle de version, et pas seulement de l'instantané le plus récent des fichiers de projet. | ||
| + | |||
| + | Le développeur apporte des modifications dans une arborescence de travail, qui est une extraction d'un seul instantané du projet. Un ensemble de modifications connexes est ensuite indexé et validé dans le dépôt local. À ce stade, aucune modification n'a été apportée au dépôt distant partagé. | ||
| + | Lorsque le développeur est prêt à partager son activité, il transmet par push les modifications au dépôt distant. Sinon, si le dépôt local est accessible à partir du réseau, le propriétaire du dépôt distant peut extraire les modifications du dépôt local du développeur vers le dépôt distant. | ||
| + | De même, lorsqu'un développeur est prêt à mettre à jour son dépôt local avec les dernières modifications apportées au dépôt distant, il peut extraire les modifications du dépôt distant et les fusionner dans le dépôt local. | ||
| + | Pour utiliser Git de manière efficace, un utilisateur doit connaître les trois états possibles d'un fichier dans l'arborescence de travail : modifié, indexé ou validé. | ||
| + | * Modifié : la copie du fichier dans l'arborescence de travail a été éditée et diffère de la version la plus récente figurant dans le dépôt. | ||
| + | * Indexé : le fichier modifié a été ajouté à une liste de fichiers modifiés pour être validé en tant qu'ensemble, mais il n'a pas encore été validé. | ||
| + | * Validé : le fichier modifié a été validé dans le dépôt local. | ||
| + | |||
| + | Une fois le fichier validé dans le dépôt local, la validation peut être transmise par push au dépôt distant ou extraite par celui-ci. | ||
Version du 11 mai 2020 à 09:51
L'un des concepts clés de DevOps est la notion d'infrastructure sous forme de code. Au lieu de gérer votre infrastructure manuellement, vous définissez et créez vos systèmes en exécutant votre code d'automatisation. Red Hat Ansible Automation est un outil clé qui peut vous aider à mettre en oeuvre cette approche.
Si les projets Ansible sont le code utilisé pour définir l'infrastructure, un système de contrôle de version tel que Git doit être utilisé pour suivre et contrôler les modifications apportées au code.
Le contrôle de version vous permet de mettre en oeuvre un cycle de vie pour les différents stades de votre code d'infrastructure, comme le développement, l'assurance qualité et la production. Vous pouvez valider les modifications apportées à une branche et tester ces modifications dans les environnements de développement et d'assurance qualité non critiques. Une fois que les modifications vous conviennent, vous pouvez les fusionner avec le code de production principal et appliquer les modifications à votre infrastructure de production.
GIT
Présentation de GIT
Git est un système de contrôle de version distribué (DVCS, Distributed Version Control System) qui permet aux développeurs de gérer les modifications apportées aux fichiers d'un projet de manière collaborative. Chaque révision d'un fichier est validée dans le système. Les anciennes versions des fichiers peuvent être restaurées, et un journal de l'auteur des modifications est conservé. Les systèmes de contrôle de version présentent de nombreux avantages, notamment :
- la possibilité de réviser et de restaurer les anciennes versions des fichiers ;
- la possibilité de comparer deux versions du même fichier pour identifier les modifications ;
- un enregistrement ou un journal de l'auteur des modifications, ainsi que le moment où ces modifications ont été apportées ;
- des mécanismes permettant à plusieurs utilisateurs de modifier des fichiers de manière collaborative, de résoudre les modifications conflictuelles et de fusionner les modifications ensemble.
Git est un système de contrôle de version distribué. Chaque développeur peut commencer par cloner un projet partagé existant à partir d'un dépôt distant. Le clonage d'un projet crée une copie complète du dépôt distant d'origine en tant que dépôt local. Il s'agit d'une copie locale de l'intégralité de l'historique des fichiers dans le système de contrôle de version, et pas seulement de l'instantané le plus récent des fichiers de projet.
Le développeur apporte des modifications dans une arborescence de travail, qui est une extraction d'un seul instantané du projet. Un ensemble de modifications connexes est ensuite indexé et validé dans le dépôt local. À ce stade, aucune modification n'a été apportée au dépôt distant partagé. Lorsque le développeur est prêt à partager son activité, il transmet par push les modifications au dépôt distant. Sinon, si le dépôt local est accessible à partir du réseau, le propriétaire du dépôt distant peut extraire les modifications du dépôt local du développeur vers le dépôt distant. De même, lorsqu'un développeur est prêt à mettre à jour son dépôt local avec les dernières modifications apportées au dépôt distant, il peut extraire les modifications du dépôt distant et les fusionner dans le dépôt local. Pour utiliser Git de manière efficace, un utilisateur doit connaître les trois états possibles d'un fichier dans l'arborescence de travail : modifié, indexé ou validé.
- Modifié : la copie du fichier dans l'arborescence de travail a été éditée et diffère de la version la plus récente figurant dans le dépôt.
- Indexé : le fichier modifié a été ajouté à une liste de fichiers modifiés pour être validé en tant qu'ensemble, mais il n'a pas encore été validé.
- Validé : le fichier modifié a été validé dans le dépôt local.
Une fois le fichier validé dans le dépôt local, la validation peut être transmise par push au dépôt distant ou extraite par celui-ci.
