Tools/Ansible/Infrastructure As Code : Différence entre versions
(→GIT) |
|||
Ligne 16 : | Ligne 16 : | ||
= GIT = | = GIT = | ||
+ | == Références rapides de GIT == | ||
+ | {| class="wikitable" | ||
+ | !colspan="2"|Principales commandes GIT | ||
+ | |- | ||
+ | |Commande | ||
+ | |Description | ||
+ | |- | ||
+ | |<code>git clone URL</code> | ||
+ | |Cloner un projet Git existant à partir du dépôt distant à | ||
+ | l'URL dans le répertoire courant. | ||
+ | |- | ||
+ | |git status | ||
+ | |Afficher l'état des fichiers modifiés et indexés dans | ||
+ | l'arborescence de travail. | ||
+ | |} | ||
+ | |||
== Présentation de <code>GIT</code> == | == Présentation de <code>GIT</code> == | ||
Version du 11 mai 2020 à 10:26
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.
Sommaire
GIT
Références rapides de GIT
Principales commandes GIT | |
---|---|
Commande | Description |
git clone URL
|
Cloner un projet Git existant à partir du dépôt distant à
l'URL dans le répertoire courant. |
git status | Afficher l'état des fichiers modifiés et indexés dans
l'arborescence de travail. |
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.
DESCRIPTION DE LA CONFIGURATION GIT INITIALE
Étant donné que les utilisateurs de Git modifient fréquemment des projets avec plusieurs contributeurs, Git enregistre le nom et l'adresse électronique de l'utilisateur à chacune des validations. Ces valeurs peuvent être définies au niveau projet, mais les paramètres par défaut globaux peuvent également être définis pour un utilisateur. La commande git config
contrôle ces paramètres. L'utilisation de cette commande avec l'option --global
gère les paramètres par défaut de tous les projets Git auxquels l'utilisateur contribue en enregistrant les paramètres dans son fichier ~/.gitconfig
.
[user@demo ~]$ git config --global user.name 'Franck H' [user@demo ~]$ git config --global user.email frh@host.example.com
Si bash
est le shell de l'utilisateur, un autre paramètre facultatif, qui est utile, consiste à configurer
votre invite de façon à ce qu'elle soit automatiquement modifiée pour signaler l'état de votre arborescence de travail. La méthode la plus simple consiste à utiliser le script git-prompt.sh
fourni avec le paquetage git.
Pour modifier votre invite de shell
de cette façon, ajoutez les lignes suivantes au fichier ~/.bashrc
. Si votre répertoire courant se trouve dans une arborescence de travail Git, le nom de
la branche Git actuelle de l'arborescence de travail est affiché entre parenthèses. Si vous disposez
de fichiers non suivis, modifiés ou indexés qui ne sont pas validés dans votre arborescence de
travail, l'invite indique ce qui suit :
- (branch *) signifie qu'un fichier suivi est modifié
- (branch +) signifie qu'un fichier suivi est modifié et indexé avec
git add
- (branch %) signifie que les fichiers non suivis se trouvent dans votre arborescence
- Des combinaisons de marqueurs sont possibles, telles que (branch *+)
source /usr/share/git-core/contrib/completion/git-prompt.sh export GIT_PS1_SHOWDIRTYSTATE=true export GIT_PS1_SHOWUNTRACKEDFILES=true export PS1='[\u@\h \W$(declare -F __git_ps1 &>/dev/null && __git_ps1 " (%s)")]\$ '
LE WORKFLOW GIT
Lorsque vous travaillez sur des projets partagés, l'utilisateur Git clone un dépôt existant en amont à l'aide de la commande git clone
. Le nom de chemin d'accès ou l'URL fourni détermine le dépôt qui est cloné dans le répertoire courant. Une arborescence de travail est également créée de sorte que le répertoire des fichiers soit prêt pour des révisions. Étant donné que l'arborescence de travail n'est pas modifiée, son état initial est propre.
Par exemple, la commande suivante clone le dépôt project.git
sur git.lab.example.com, avec une connexion à l'aide du protocole SSH et d'une authentification en tant qu'utilisateur git :
[user@demo ~]$ git clone git@git.lab.example.com:project.git
|
Lors de la phase de développement, des fichiers sont créés et les fichiers existants sont modifiés dans l'arborescence de travail. L'arborescence de travail passe alors à un état modifié.
- La commande
git status
affiche des informations détaillées sur les fichiers de l'arborescence de travail qui sont modifiés, mais non indexés, non suivis (nouveau) ou indexés pour la validation suivante. - La commande
git add
indexe les fichiers, en les préparant à être validés. Seuls les fichiers qui sont indexés dans la zone d'indexation sont enregistrés dans le dépôt lors de la validation suivante. Si un utilisateur travaille sur deux modifications en même temps, les fichiers peuvent être organisés en deux validations pour un meilleur suivi des modifications. Un ensemble demodifications est indexé et validé, puis les autres modifications sont indexées et validées. - La commande
git rm
supprime un fichier du répertoire de travail et indexe également sa suppression du dépôt pour la validation suivante. - La commande
git reset
supprime de la zone d'indexation un fichier qui a été ajouté pour la prochaine validation. Cette commande n'a aucun effet sur le contenu du fichier dans l'arborescence de travail. - La commande
git commit
valide les fichiers indexés dans le dépôt Git local. Un message de journal doit être fourni pour expliquer les raisons pour lesquelles l'ensemble actuel de fichiers indexés est enregistré. Si vous ne spécifiez pas de message, la validation est abandonnée. Les messages de journal ne doivent pas être longs, mais ils doivent être explicites pour être utiles.
|
|
- La commande
git push
envoie au dépôt distant les modifications apportées au dépôt local. Afin de coordonner les tâches avecGit
, tous les développeurs doivent transmettre par push leur travail au même dépôt distant partagé.
Pour que les transmissions par push de Git puissent fonctionner, il convient de définir la méthode push par défaut. La commande suivante définit la valeur simple de la méthode par défaut de transmission par push. Il s'agit de l'option la plus sûre pour les débutants.
[user@demo ~]$ git config --global push.default simple
- La commande
git pull
extrait les validations à partir du dépôt distant et les ajoute au dépôt local. Elle fusionne également les modifications apportées aux fichiers dans votre arborescence de travail.
Cette commande doit être fréquemment exécutée pour que les modifications apportées au projet par les autres utilisateurs dans le dépôt distant soient constamment à jour.
|