Git
PowerShell Universal est capable de synchroniser les scripts de configuration avec un dépôt git distant.
Configuration
Console d'administration
La synchronisation git peut être configurée dans la base de données en ajustant les paramètres dans la console d'administration. C'est l'approche à privilégier. L'avantage est que lorsque vous connectez de nouvelles instances de PowerShell Universal à votre instance SQL, vous n'aurez pas à configurer la synchronisation git de nouveau.
Pour configurer la synchronisation git, accédez à Source Control > Git > Settings dans la console d'administration. Vous pourrez cliquer sur le bouton Create Git Settings.
appsettings.json
Vous pouvez aussi utiliser les paramètres de configuration pour mettre en place la synchronisation git. Cela est utile si vous avez une seule instance de PSU et que vous souhaitez sauvegarder votre fichier appsettings.json. L'ajustement des paramètres dans la console d'administration ne mettra pas à jour le fichier appsettings.json. Vous devrez le faire manuellement et redémarrer PowerShell Universal après avoir modifié les paramètres.
Si les paramètres de synchronisation git sont spécifiés dans la base de données, les paramètres définis dans appsettings.json sont ignorés.
Paramètres de synchronisation Git
Branche
Par défaut, PowerShell Universal se synchronisera avec la branche master. Si vous souhaitez utiliser une autre branche, spécifiez le paramètre GitBranch dans votre appsettings.json.
Correction du suivi amont manquant
Si vous rencontrez l'erreur "There is no tracking information for the current branch", la branche locale n'est pas liée à la branche distante. Pour corriger cela :
Ouvrez PowerShell dans
%ProgramData%\UniversalAutomation\Repository(ou le chemin du dépôt configuré)Exécutez :
Distant
Les dépôts distants ne sont pas requis. Si aucun dépôt distant n'est spécifié, le dépôt git est stocké localement dans le répertoire Repository. S'il est spécifié, PowerShell Universal se synchronisera avec le dépôt distant. Des identifiants appropriés sont requis pour accéder à ce dépôt distant.
Format d'URL Azure DevOps
Les dépôts Azure DevOps doivent utiliser le format d'URL moderne dev.azure.com plutôt que l'ancien domaine visualstudio.com :
Format correct :
Exemples :
Si le nom de votre dépôt contient des espaces, ceux-ci doivent être encodés en %20 dans l'URL. Évitez d'utiliser des URL avec l'ancien domaine visualstudio.com, car elles peuvent provoquer des boucles de redirection ou des échecs d'authentification avec l'erreur « too many redirects or authentication replays ».
Pour Azure DevOps, votre Personal Access Token doit avoir la portée Code (Read & Write). Les jetons à granularité fine fonctionnent, mais les PAT classiques sont recommandés pour la compatibilité entre les versions de PSU.
Note pour les utilisateurs de GitLab : Si votre instance GitLab nécessite une authentification basée sur les en-têtes, vous devrez peut-être utiliser l'option External Git Client et configurer les assistants d'identifiants Git, car le client Git intégré de PSU utilise l'authentification HTTP Basic avec le PAT comme mot de passe. Certaines configurations GitLab attendent plutôt un en-tête Private-Token.
Authentification
Vous devrez configurer l'authentification à votre dépôt git distant. Nous recommandons un jeton d'accès personnel.
Client Git externe
Vous pouvez choisir d'utiliser un client git externe plutôt que la bibliothèque intégrée à PowerShell Universal. Cela vous offre des options de configuration additionnelles, comme l'utilisation de l'authentification SSH. PowerShell Universal n'utilisera pas les noms d'utilisateur, mots de passe ou PAT configurés lorsque cette méthode est activée. Vous devrez avoir un client git installé.
Utilisation de clés SSH
Vous pouvez utiliser PowerShell Universal pour générer et gérer des clés SSH. Dans la console d'administration, cliquez sur Source Control > SSH Keys. Générez une nouvelle clé SSH. Ensuite, cliquez sur le bouton de copie à côté de la clé SSH pour obtenir la clé publique.
Enregistrez la clé publique auprès du dépôt ou du compte cible. Par exemple, vous pouvez suivre le guide GitHub ici.
Dans la fenêtre Git Settings, sélectionnez la clé SSH que vous souhaitez utiliser avec la synchronisation git. Lorsque vous utilisez des clés SSH, assurez-vous que l'URL SSH est sélectionnée pour cloner votre dépôt.
Configuration des identifiants
Lorsque vous utilisez le client git externe, il vous incombe de configurer les identifiants avant d'effectuer une synchronisation.
Vous pouvez configurer les identifiants par la configuration git ou par l'URL transmise à PowerShell Universal.
La commande suivante stockera les identifiants en texte en clair sur le serveur PowerShell Universal. Vous devrez exécuter cette commande en tant qu'utilisateur du compte de service afin qu'il ait accès aux identifiants. Cela créera un fichier .git-credentials qui sera utilisé lors de l'authentification auprès de l'URL cible. Vous devrez peut-être modifier l'URL selon votre dépôt git distant.
Vous pouvez aussi stocker les identifiants directement dans l'URL fournie à PowerShell Universal.
Exemple : nom d'utilisateur et PAT
Pour utiliser un client git externe et transmettre un nom d'utilisateur et un PAT pour l'authentification, vous pouvez les spécifier dans l'URL du dépôt git distant. Par exemple :
Exemple : SSH et GitHub
D'abord, vous devrez configurer votre ssh-agent local et votre compte GitHub avec des clés SSH.
Vous pouvez suivre leur guide ici.
Ensuite, vous fournirez un URI SSH comme URL de dépôt git distant dans PowerShell Universal. La clé SSH configurée sera utilisée pour la connexion.
Problème de certificat SSL
SSL Certificate problem: unable to get local issuer certificate
Si vous exécutez sur Windows et recevez un problème de certificat SSL, vous devrez peut-être vous assurer d'avoir activé la prise en charge de schannel.
Persistance des identifiants
Unable to persist credentials with the 'wincredman' credential store.
Si vous êtes sur Windows et recevez une erreur au sujet de la persistance des identifiants dans wincredman, vous devrez peut-être définir la persistance des identifiants à DAPI. Vous pouvez apprendre comment le faire ici.
Mode manuel
Le mode manuel exige que les utilisateurs qui modifient l'instance PowerShell Universal cliquent sur Edit afin d'apporter des modifications dans le système.
Une fois les modifications terminées, l'utilisateur peut cliquer sur Save Changes pour amorcer un commit
Sur la page de commit git, vous pouvez voir les fichiers modifiés et saisir un message de commit.
Une fois les modifications validées, elles seront poussées vers le dépôt distant et le service recommencera à se synchroniser avec git. Il est aussi possible qu'un conflit de fusion git se produise à ce moment. Consultez Gestion des conflits pour plus d'information.
Le mode manuel peut être défini dans les paramètres git de la console d'administration ou dans appsettings.json.
Méthode un : pousser les fichiers locaux vers le dépôt distant
Vous devez vous assurer que votre dossier local n'est pas un dépôt git préexistant. Votre répertoire de dépôt devrait simplement être un dossier contenant vos fichiers PowerShell Universal. Si un dossier .git existe et que vous ne souhaitez pas utiliser ce dépôt, vous devriez le supprimer et PowerShell Universal créera un nouveau dépôt.
Si vous remplissez un nouveau dépôt git, vous devez vous assurer que le dépôt distant ne contient aucun fichier. Il devrait s'agir d'un dépôt complètement vide. Par exemple, lors de la création d'un dépôt sur GitHub, ne sélectionnez pas la création d'un fichier de licence ou readme.md.
Une fois le dépôt créé, vous pouvez récupérer l'URL du dépôt git distant et la fournir au fichier appsettings.json de PowerShell Universal.
Une fois que vous avez la branche, l'URL du dépôt git distant et les identifiants, vous pouvez les fournir à votre fichier appsettings.json et le dépôt git distant sera rempli avec vos fichiers locaux.
Méthode deux : tirer depuis un dépôt git distant
Vous pouvez configurer PowerShell Universal pour tirer depuis un dépôt git distant. Dans cette configuration, vous devez vous assurer que votre dossier de dépôt local est complètement vide. Tout fichier dans le dossier fera échouer la synchronisation git et l'empêchera de se rétablir.
Configurez le fichier appsettings.json pour inclure la branche, les identifiants et l'URL du dépôt git distant que vous clonez. Une fois les champs définis, vous pouvez démarrer le service PowerShell Universal. La première chose que le service fera est de cloner le dépôt et de le configurer localement.
Délai d'expiration de la synchronisation Git
La synchronisation git expirera si elle ne peut pas contacter le dépôt distant après 60 minutes. Cela laisse le temps de télécharger de gros dépôts ou de composer avec des réseaux lents. Vous pourriez voir le service PowerShell Universal figé sur « Synchronizing with git » au démarrage pendant que le serveur attend que cela se produise. Si vous souhaitez réduire ce délai, vous pouvez utiliser le paramètre appsetting.json suivant. La valeur est en minutes.
Intervalle de synchronisation
Type : Integer
Par défaut : 60
appsettings.json : GitSyncInterval
L'intervalle, en secondes, entre les tentatives de synchronisation Git automatiques lorsque la synchronisation automatique est activée. La valeur par défaut est de 60 secondes (1 minute).
Pour ajuster la fréquence de synchronisation, modifiez appsettings.json :
Cela changerait l'intervalle de synchronisation à 5 minutes. Des valeurs plus faibles augmentent la fréquence de synchronisation, mais peuvent affecter la performance dans les grands dépôts ou les réseaux lents. Définir cette valeur trop basse (sous 30 secondes) n'est pas recommandé pour les environnements de production.
Dépannage
Azure DevOps : « Too many redirects or authentication replays »
Cette erreur indique généralement l'un des problèmes suivants :
Ancien format d'URL : Assurez-vous d'utiliser
https://dev.azure.com/<org>/<project>/_git/<repo>plutôt que l'ancien domainevisualstudio.comPortée du PAT invalide : Votre Personal Access Token doit avoir les permissions Code (Read & Write) dans Azure DevOps
Identifiants expirés : Générez un nouveau PAT et saisissez-le de nouveau dans les paramètres Git de PSU
Espaces encodés : Si le nom de votre dépôt contient des espaces, assurez-vous qu'ils sont encodés en
%20dans l'URL
Résolution :
Mettez à jour l'URL distante pour utiliser
dev.azure.comGénérez un nouveau PAT avec la portée Code (Read & Write)
Activez Use External Git Client et installez Git pour Windows si le client intégré continue d'échouer
Suivi amont manquant
Erreur : « There is no tracking information for the current branch »
Cause : La branche Git locale n'est pas configurée pour suivre une branche distante.
Résolution : Ouvrez PowerShell dans le répertoire du dépôt et exécutez :
Remplacez main par le nom réel de votre branche. Cliquez ensuite sur Synchronize Now dans PSU.
La synchronisation Git s'arrête après la modification des paramètres dans l'interface
Symptômes : Après avoir modifié les paramètres Git (URL distante, identifiants, intervalle de synchronisation, etc.) dans l'interface de PSU et cliqué sur OK, la synchronisation cesse de fonctionner même si les paramètres semblent corrects.
Cause : Dans PSU 5.x, les identifiants Git sont stockés dans la base de données SQL. Toute modification apportée aux paramètres Git par l'interface peut effacer les identifiants stockés, même si le champ de mot de passe semble toujours rempli dans le formulaire.
Résolution :
Saisissez de nouveau le Personal Access Token dans Source Control > Git > Settings
Cliquez sur OK pour enregistrer
Dans les environnements multinœuds, répétez ce processus sur chaque nœud — les identifiants doivent être saisis individuellement sur chaque serveur
Cliquez sur Synchronize Now pour vérifier que la synchronisation fonctionne de nouveau
Le système ne propage pas automatiquement les identifiants entre les nœuds dans une configuration à charge équilibrée ou à haute disponibilité.
Problèmes d'agent et de réseau
Symptômes : La synchronisation fonctionne sur un nœud mais échoue sur les autres, ou vous voyez des erreurs RpcException ou « service is unavailable » dans les journaux.
Causes courantes :
Incompatibilité de version : Assurez-vous que tous les serveurs et agents PSU exécutent la même version
Règles de pare-feu : Les agents communiquent avec le serveur PSU par gRPC sur les ports 5000 (HTTP) ou 5001 (HTTPS)
Blocage de proxy ou de WebSocket : Les proxys d'entreprise peuvent bloquer ou inspecter le trafic gRPC; configurez git pour utiliser le proxy ou activez le client Git externe
Résolution :
Vérifiez que tous les nœuds exécutent la même version de PSU
Vérifiez que les règles de pare-feu permettent le trafic sur les ports 5000/5001
Testez la connectivité gRPC entre les nœuds
Si vous utilisez un proxy, configurez les variables d'environnement
http_proxyethttps_proxypour le compte de service PSU
Déploiements Docker et conteneurisés
Assurez-vous que l'image du conteneur inclut
git(exécutezgit --versionpour vérifier)Vérifiez l'accès réseau sortant vers le dépôt git distant
Montez des volumes persistants pour
/dataou%ProgramData%\UniversalAutomationafin de préserver l'état git entre les redémarragesSi la synchronisation échoue silencieusement, vérifiez les journaux du conteneur pour des erreurs git ou réseau
Modification de .git/config sans le CLI Git
Si l'outil de ligne de commande Git n'est pas installé sur le serveur et que vous rencontrez des erreurs de suivi amont, vous pouvez modifier la configuration du dépôt directement par le navigateur de fichiers de PSU :
Accédez à Platform → Configuration → Repository → .git → config
Ajoutez les lignes suivantes (ajustez le nom de la branche pour qu'il corresponde à votre dépôt) :
Cliquez sur Save
Retournez à Source Control > Git > Settings et cliquez sur Synchronize Now
Cette approche vous permet de configurer le suivi en amont sans avoir besoin de commandes git, ce qui est particulièrement utile lorsque Git for Windows n'est pas installé ou lors de l'exécution sous des comptes de service restreints.
Les paramètres Git ne persistent pas
Si les modifications apportées aux paramètres Git ne sont pas enregistrées ou sont annulées immédiatement après avoir cliqué sur OK :
Vérifier les permissions du système de fichiers :
Arrêtez le service PowerShell Universal
Essayez de modifier manuellement
%ProgramData%\PowerShellUniversal\appsettings.json(ou%ProgramData%\UniversalAutomation\appsettings.jsondans les versions antérieures)Ajoutez une ligne de commentaire, enregistrez, puis rouvrez le fichier pour vérifier que vos modifications persistent
Si les modifications sont annulées, vérifiez si un logiciel antivirus, des objets de stratégie de groupe (GPO) ou des permissions NTFS empêchent l'écriture dans le répertoire de données PSU
Activer la journalisation de débogage pour le dépannage :
Arrêtez le service PowerShell Universal
Modifiez
appsettings.jsonet définissez :
Enregistrez et redémarrez le service
Tentez d'enregistrer les paramètres Git de nouveau
Consultez
%PROGRAMDATA%\PowerShellUniversal\systemLog.txtpour repérer les erreurs liées aux écritures de configuration
Renseigner manuellement les paramètres Git :
Une fois le service arrêté, vous pouvez renseigner directement les champs Git dans appsettings.json :
Redémarrez le service et vérifiez que les paramètres apparaissent dans Source Control > Git > Settings. S'ils disparaissent de nouveau, les journaux de débogage indiqueront si un problème de permission, un logiciel de protection des terminaux ou une erreur de validation de la configuration provoque la réinitialisation.
unknown certificate lookup failure: 16777280
Lorsque vous utilisez la bibliothèque git intégrée, vous pourriez rencontrer des problèmes de certificat lors de la connexion à des dépôts git hébergés localement. Dans cette configuration, nous recommandons d'utiliser le client git externe afin d'offrir un meilleur soutien pour la configuration du processus de recherche de certificat.
Fichiers inclus
Les fichiers inclus lors d'une synchronisation git sont tous les fichiers du dépôt local. Cela comprend les fichiers de configuration PS1, les fichiers XML des pages et tout autre fichier que vous pourriez ajouter manuellement.
Les éléments suivants ne sont pas inclus :
appsettings.json
database.db
web.config
Binaires de l'application PowerShell Universal
Plusieurs dépôts Git
PowerShell Universal prend en charge le stockage de plusieurs configurations de dépôt git dans la base de données. Ainsi, vous pouvez basculer rapidement entre différentes configurations de PowerShell Universal. Cliquez sur l'onglet Repositories pour voir les dépôts actuellement configurés. À partir de là, vous pouvez supprimer et modifier les configurations de dépôt.
PowerShell Universal ne supprime pas le dossier .git lors de la suppression d'une configuration de dépôt. Vous devrez le faire manuellement afin de configurer un nouveau dépôt.
Lorsque vous ajoutez une nouvelle configuration de dépôt, vous pouvez cliquer sur le bouton Apply pour basculer vers le dépôt sélectionné. Cela supprimera tous les fichiers du répertoire du dépôt et clonera le dépôt sélectionné. Vous ne pouvez pas appliquer une configuration de dépôt s'il y a des modifications non validées dans votre dépôt. Après avoir cloné le dépôt, PowerShell Universal rechargera complètement sa configuration.
Page de l'historique et de l'état Git
L'onglet de l'historique affiche tout l'historique des commits git du dépôt actuel.
L'onglet de l'état de synchronisation affiche l'état actuel des nœuds au sein du cluster PSU.
Tester la synchronisation Git
La meilleure façon de s'assurer que votre synchronisation git fonctionne correctement est de cliquer sur le bouton Synchronize Now. Cela forcera l'exécution d'une synchronisation, et vous pourrez vérifier si les paramètres saisis fonctionnent correctement.
Afficher les modifications
Vous pouvez consulter les modifications dans le tableau des synchronisations git. Chaque synchronisation comprend le nombre de modifications trouvées depuis la dernière synchronisation, le SHA du commit et une liste des modifications entre ce SHA et le précédent. Lorsque des fichiers sont dans un état modifié, vous pourrez consulter les différences à l'aide de l'outil de comparaison de fichiers.
Gérer les conflits
Lorsque plusieurs utilisateurs modifient les fichiers de configuration de PowerShell Universal, il peut y avoir des conflits. PowerShell Universal indiquera qu'un nœud particulier est dans un état de conflit lors d'une tentative de validation des modifications. Vous verrez une liste des modifications en conflit sur la page de commit git. Cliquez sur le bouton Resolve Conflict pour afficher le conflit dans un éditeur.
Dans cet exemple, la chaîne de ce point de terminaison a été modifiée à la fois sur le dépôt distant et sur le dépôt local :
Version actuelle (locale) — entre
<<<<<<< HEADet=======:"That endpoint"Version entrante (distante) — entre
=======et>>>>>>> main:"This endpoint"
Modifiez le texte pour supprimer le conflit.
Enregistrez les modifications et retournez à la page de commit git. Saisissez un nouveau message de commit pour le conflit de fusion et cliquez sur Commit Changes.
Cela résoudra le conflit de fusion et effectuera un push vers le dépôt distant.
Comportement de la synchronisation Git
Bidirectionnelle
Par défaut, la synchronisation git fonctionne dans les deux sens. Si vous apportez des modifications dans la console d'administration PSU, ces modifications seront validées et synchronisées vers le dépôt distant configuré.
Toutes les modifications effectuées dans le dépôt distant seront récupérées localement.
Si vous configurez la synchronisation git avec un dépôt distant git préexistant, les modifications seront récupérées et synchronisées localement. Vous ne pouvez avoir aucune modification locale.
Si vous configurez la synchronisation git avec un dépôt vide (bare), les modifications locales seront synchronisées et le dépôt sera initialisé.
Unidirectionnelle
Vous pouvez ajuster le comportement de la synchronisation git en modifiant le paramètre GitSyncBehavior dans appsettings.json. Lorsqu'il est défini à OneWay, la console d'administration et l'API de gestion deviennent en lecture seule. Le système PowerShell Universal récupérera les modifications du dépôt distant, mais n'effectuera jamais de push ni de commit local.
Push seulement
Le mode de synchronisation git push seulement ne récupérera pas les modifications du dépôt distant. Toutes les modifications effectuées localement seront poussées vers le dépôt distant. La console ne sera pas en lecture seule. Cette configuration est utile dans les scénarios où vous avez une machine utilisée pour la configuration source de vérité d'un groupe de serveurs en lecture seule.
Jeton d'accès personnel
Nous recommandons d'utiliser un jeton d'accès personnel (PAT) plutôt qu'un nom d'utilisateur et un mot de passe. Vous pouvez configurer un jeton d'accès personnel en définissant la propriété password dans le fichier appsettings.json ou par d'autres méthodes de configuration.
Jetons à granularité fine GitHub
Dans GitHub, vous pouvez obtenir un jeton à granularité fine en cliquant sur votre avatar en haut à droite, puis en sélectionnant Settings, Developers Settings, Personal Access Tokens et enfin Fine-Grained Tokens.
Portées du jeton
Lors de la génération du jeton, assurez-vous d'accorder au dépôt la permission Read-Write sur Content. Cela ajoutera automatiquement Read à la permission Metadata. Vous pouvez accorder l'accès uniquement au dépôt que vous souhaitez cloner.
Jetons GitHub (classiques)
Dans GitHub, vous pouvez obtenir un jeton d'accès personnel en cliquant sur votre avatar en haut à droite, puis en sélectionnant Settings, Developer Settings, Personal Access Tokens et enfin Tokens (Classic).
Lors de la génération de votre jeton d'accès, assurez-vous de sélectionner les permissions Repo.
Notez que si vous utilisez BitBucket, vous devrez spécifier le nom d'utilisateur en plus du PAT dans appsettings.json.
Nom d'utilisateur et mot de passe
Vous pouvez aussi configurer un dépôt distant git pour s'authentifier avec un nom d'utilisateur et un mot de passe. Définissez le nom d'utilisateur et le mot de passe soit avec le fichier appsettings.json, soit avec une autre méthode de configuration.
Erreurs courantes
Git synchronization failed. unknown certificate lookup failure: 16777280
La bibliothèque lib2gitsharp n'a pas pu valider le certificat du dépôt git distant. Vous devrez utiliser le client git externe et une configuration git personnalisée pour corriger ce problème.
Voici quelques options courantes pour la prise en charge de git HTTPS :
"too many redirects" ou rejeux d'authentification
Le dépôt distant git a rejeté vos identifiants d'accès au dépôt. Votre jeton d'accès personnel est peut-être expiré ou n'a pas accès au dépôt distant.
repository not owned by current user
Le dépôt git local ne dispose pas des contrôles d'accès appropriés pour l'utilisateur qui tente d'y accéder. Cela peut se produire si PowerShell Universal a cloné le dépôt et qu'un compte de service différent a ensuite été défini sur le service. Comme les contrôles d'accès ne correspondent pas, git n'accédera pas au dossier. Il s'agit d'une fonctionnalité de sécurité de git.
Vous pouvez mettre à jour le propriétaire du dossier pour éviter cela ou configurer git pour qu'il fasse confiance au dossier. Définissez la valeur suivante dans la configuration git globale.
La configuration globale se trouve dans : C:\Program Files\git\etc\gitconfig
Avantages de la synchronisation Git par rapport à la synchronisation Git manuelle
Il est possible de synchroniser manuellement un dépôt avec git. PowerShell Universal utilise des commandes très basiques lorsqu'il traite avec git. Toute modification apportée à PowerShell Universal par la console d'administration ou l'API déclenche un git commit et l'auteur est défini comme l'identité de l'utilisateur qui effectue la modification. Lors d'une opération de synchronisation git, nous effectuons d'abord un git pull afin de nous assurer d'avoir la dernière version des fichiers du dépôt distant. Ensuite, nous effectuons un git push pour pousser les commits locaux survenus depuis la dernière synchronisation.
Vous pourriez obtenir cette fonctionnalité avec une tâche planifiée.
Cela dit, une fonctionnalité de la synchronisation git est qu'elle analyse le commit pour s'assurer que seuls les fichiers modifiés durant la synchronisation sont rechargés. Cela empêchera les tableaux de bord de se déployer automatiquement alors qu'ils n'ont pas changé ou les services d'API de redémarrer alors que les environnements n'ont pas été mis à jour. Il y a donc un gain de performance ici.
L'autre problème est qu'en raison de la façon dont PowerShell Universal surveille les fichiers (avec un FileSystemWatcher) et de la façon dont git met à jour les fichiers, les configurations ne se rechargeront pas automatiquement après un pull. Vous devrez vous assurer de forcer la réévaluation des configurations.
Stratégies de branchement
Les stratégies de branchement dans git déterminent comment les modifications sont déplacées d'une branche à une autre. L'utilisation de différents types de stratégies de branchement dans PowerShell Universal permet de s'assurer que des équipes de tailles différentes peuvent travailler efficacement ensemble dans la plateforme.
Utilisateurs seuls et petites équipes
Pour les utilisateurs seuls et les petites équipes, il n'est peut-être pas nécessaire d'avoir plus d'une seule branche. La branche est utilisée pour le suivi de l'historique et offre la possibilité d'annuler des modifications. Les utilisateurs accèderont directement à PowerShell Universal pour apporter des modifications ou valider des modifications dans la branche unique à partir de clones locaux du répertoire du dépôt en utilisant un outil comme VS Code.
main - Branche unique qui accepte toutes les modifications directement
Utilisateurs seuls et petites équipes avec une branche de préproduction
Même les utilisateurs seuls et les petites équipes peuvent trouver avantageux d'employer une branche de préproduction (staging), ou dev. Cette branche recevra les modifications durant le développement. Une instance autonome de PowerShell Universal sera configurée pour s'exécuter avec cette branche dev afin que les utilisateurs puissent valider les modifications avant de les pousser en production.
Lorsqu'une configuration avec branche de préproduction est utilisée, les environnements PowerShell Universal sont complètement séparés. Ils utilisent une base de données et un planificateur différents. Les données telles que les identités, les jetons d'application et l'historique des tâches ne sont pas partagées entre les environnements.
Une instance PowerShell Universal distincte peut ensuite être configurée pour pointer vers une branche main, ou production, qui recevra les mises à jour par fusions ou Pull Requests dans un système comme GitHub. Dans cette configuration, il est possible d'utiliser la synchronisation git unidirectionnelle pour récupérer les modifications de main sans jamais pousser depuis la plateforme. Cela évite également la plupart des conflits de fusion, puisqu'ils seront traités dans la branche dev ou via l'outil de fusion du dépôt source.
main - Branche de production qui reçoit les modifications provenant des pull requests de la branche dev
dev - La branche de préproduction utilisée pour accepter les commits et valider les modifications avant de pousser vers master.
Équipes de taille moyenne à grande
Lorsqu'on considère des équipes de plus de quelques développeurs, une stratégie de branchement plus complexe peut être utile pour mieux évaluer les modifications de code et éviter les conflits de fusion. PowerShell Universal offre des outils de fusion de base, mais de meilleurs outils sont disponibles à cette fin, comme les pull requests de GitHub, les merge requests de GitLab et des outils locaux comme GitKraken.
Dans les équipes de taille moyenne, il peut être souhaitable d'avoir des branches de fonctionnalités supplémentaires qui isolent des modifications spécifiques dans une certaine branche. Par exemple, un développeur peut créer un nouvel ensemble d'API pour gérer Azure dans PowerShell Universal. Afin d'éviter des changements cassants dans la branche dev, les développeurs créeront leur propre branche de fonctionnalité contenant toutes leurs modifications jusqu'à ce qu'elle soit suffisamment complète pour être fusionnée dans la branche de développement.
Dans ce type de configuration, le développement local est idéal, car les développeurs travailleront sur leur instance locale de PowerShell Universal au sein de leur branche de fonctionnalité. Lorsque la fonctionnalité est terminée, ils créeront une Pull ou Merge request dans le dépôt source pour déplacer les modifications vers la branche dev. Les tests seront effectués sur la branche dev avant la fusion vers la production.
Comme pour une stratégie de branchement main\dev, toutes les instances de PowerShell Universal seront isolées et ne partageront pas de base de données ni de planificateur.
Lorsqu'un ensemble de fonctionnalités est prêt pour la production, une Pull ou Merge request sera effectuée de dev vers la branche main.
main - Branche de production qui ne recevra que les modifications de dev
dev - Branche de préproduction qui reçoit les modifications des branches de fonctionnalités, mais qui n'est pas modifiée directement
feature - Branche de fonctionnalité dans laquelle les développeurs valident directement et qui est fusionnée vers dev lorsqu'elle est prête
Selon la complexité de votre environnement, il peut être conseillé d'utiliser les Deployments plutôt que git en production. Consultez la section Grandes équipes ci-dessous pour plus d'information.
Grandes équipes
Dans les grandes équipes, nous recommandons d'utiliser git à des fins de développement, mais d'utiliser les Deployments, ou un concept similaire, pour la production.
Les Deployments fournissent des paquets de configuration immuables qui ont été bien testés dans des environnements de niveau inférieur. En utilisant les Deployments, vous pouvez choisir comment vous développez et gérez votre code et simplement publier le résultat dans vos environnements de développement, de préproduction, d'AQ et de production. Cela garantit que tout le code est bien testé avant d'être déployé dans vos systèmes critiques.
Vous pouvez utiliser des flux de travail automatisés, comme GitHub Actions, pour publier vos Deployments sans devoir mettre à jour manuellement quelque système que ce soit.
Hébergement Git
PowerShell Universal prend en charge toute solution d'hébergement git standard. Nos clients utilisent fréquemment les suivantes :
GitHub
GitHub Enterprise
GitLab
Bitbucket
Azure DevOps
Bien qu'il s'agisse des plateformes les plus courantes, nous prenons en charge toute plateforme utilisant le protocole git.
Exemple : Gitea
Vous pouvez également utiliser des solutions simples et auto-hébergées comme Gitea. Voici un exemple de la façon de configurer facilement un conteneur docker Gitea pour l'utiliser avec PowerShell Universal.
Mis à jour
Ce contenu vous a-t-il été utile ?