Git

Intégration Git pour PowerShell Universal.

L'intégration Git nécessite une licence.

PowerShell Universal est capable de synchroniser les scripts de configuration avec un référentiel 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. Il s'agit de l'approche recommandée. L'avantage est que lorsque vous connectez de nouvelles instances de PowerShell Universal à votre instance SQL, vous n'aurez pas à reconfigurer la synchronisation Git.

Pour configurer la synchronisation Git, accédez à Paramètres \ Git dans la console d'administration. Vous pourrez cliquer sur le bouton Créer les paramètres Git.

Dans PowerShell Universal 5.x et versions ultérieures, les informations d'identification Git (URL distante, nom d'utilisateur et jeton d'accès personnel) sont stockées dans la base de données SQL plutôt que dans appsettings.json. La modification de ces paramètres dans l'interface utilisateur met à jour la base de données. Si vous modifiez les paramètres Git puis cliquez sur OK, PSU peut effacer les informations d'identification stockées même si les champs semblent remplis. Dans les environnements à plusieurs nœuds, vous devez saisir à nouveau les informations d'identification sur chaque nœud individuellement après avoir effectué des modifications.

appsettings.json

Vous pouvez également utiliser les paramètres de configuration pour configurer la synchronisation Git. Cela est utile si vous disposez d'une seule instance de PSU et souhaitez sauvegarder votre fichier appsettings.json. La modification des paramètres dans la console d'administration ne met pas à jour le fichier appsettings.json. Vous devrez le faire manuellement et redémarrer PowerShell Universal après avoir modifié les paramètres.

Si des 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 synchronise avec la branche master. Si vous souhaitez utiliser une branche différente, 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 de référentiel configuré)
Exécutez :

git fetch
git branch --set-upstream-to=origin/main main
git pull

Distant

Les dépôts distants ne sont pas obligatoires. Si aucun distant n'est spécifié, le référentiel git est stocké localement dans le répertoire du référentiel. S'il est spécifié, PowerShell Universal se synchronisera avec le distant. Des informations d'identification appropriées sont requises pour accéder à ce distant.

Format d'URL Azure DevOps

Les référentiels Azure DevOps doivent utiliser le format d'URL moderne dev.azure.com plutôt que l'ancien domaine visualstudio.com :

Format correct :

https://dev.azure.com/<organization>/<project>/_git/<repository>

Exemples :

https://dev.azure.com/mycompany/MyProject/_git/PowerShellUniversal
https://dev.azure.com/mycompany/MyProject/_git/PSU%20Scripts

Si le nom de votre référentiel contient des espaces, ils doivent être encodés sous la forme %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 jeton d'accès personnel doit avoir la portée Code (lecture et écriture). Les jetons à granularité fine fonctionnent, mais les PAT classiques sont recommandés pour la compatibilité entre les versions de PSU.

Remarque pour les utilisateurs de GitLab : Si votre instance GitLab nécessite une authentification par en-tête, vous devrez peut-être utiliser l'option Client Git externe et configurer des assistants d'informations d'identification 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 un en-tête Private-Token à la place.

Authentification

Vous devrez configurer l'authentification auprès de votre référentiel git distant. Nous recommandons l'utilisation d'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 supplémentaires, comme l'utilisation de l'authentification SSH. PowerShell Universal n'utilisera pas le nom d'utilisateur, les mots de passe ou les PAT configurés lors de l'activation de cette méthode. Vous devrez avoir un client git installé.

Utilisation des 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 Plateforme \ Clés SSH. 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 référentiel ou du compte cible. Par exemple, vous pouvez suivre le guide GitHub ici.

Dans la fenêtre Paramètres Git, sélectionnez la clé SSH que vous souhaitez utiliser avec la synchronisation Git. Lors de l'utilisation de clés SSH, assurez-vous que l'URL SSH est sélectionnée pour le clonage de votre référentiel.

git@github.com:ironmansoftware/psu-devo

Définition des informations d'identification

Lors de l'utilisation du client git externe, vous êtes responsable de la configuration des informations d'identification avant d'effectuer une synchronisation.

Vous pouvez configurer les informations d'identification via la configuration git ou l'URL transmise à PowerShell Universal.

La commande suivante stockera les informations d'identification en texte brut 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 informations d'identification. 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 en fonction de votre dépôt git distant.

git config --global credential.helper store
echo "https://${username}:${password_or_access_token}@github.com" > ~/.git-credentials

Vous pouvez également stocker les informations d'identification directement dans l'URL fournie à PowerShell Universal.

https://adam:APP_TOKEN@github.com/myOrg/myRepo.git

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 :

https://username:PAT@github.com/ironmansoftware/universal

Exemple : SSH et GitHub

Tout d'abord, vous devrez configurer votre agent ssh local et votre compte GitHub avec des clés SSH.

Vous pouvez suivre leur guide ici.

Ensuite, vous fournirez un URI SSH pour l'URL du dépôt git distant dans PowerShell Universal. La clé SSH configurée sera utilisée pour la connexion.

git@github.com:ironmansoftware/universal.git

Problème de certificat SSL

SSL Certificate problem: unable to get local issuer certificate

Si vous exécutez sous Windows et rencontrez un problème de certificat SSL, vous devrez peut-être vous assurer d'avoir activé le support schannel.

Persistance des informations d'identification

Unable to persist credentials with the 'wincredman' credential store.

Si vous êtes sous Windows et recevez une erreur concernant la persistance des informations d'identification dans wincredman, vous devrez peut-être définir la persistance des informations d'identification sur DAPI. Vous pouvez apprendre comment faire ici.

Mode manuel

Le mode manuel exige que les utilisateurs qui modifient l'instance PowerShell Universal cliquent sur Modifier afin d'apporter des modifications au système.

Une fois les modifications terminées, l'utilisateur peut cliquer sur Enregistrer les modifications pour lancer une validation.

Sur la page de validation git, vous pouvez afficher les fichiers modifiés et saisir un message de validation.

Une fois les modifications validées, elles seront transmises au dépôt distant et le service commencera à se synchroniser à nouveau avec git. Il est également possible qu'un conflit de fusion git se produise à ce moment. Consultez Résolution des conflits pour plus d'informations.

Le mode manuel peut être défini dans les paramètres git de la console d'administration ou dans appsettings.json.

"Data": {
  "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository",
  "ConnectionString": "filename=%ProgramData%\\UniversalAutomation\\database.db;upgrade=true",
  "RunMigrations": true,
  "GitRemote": "",
  "GitUserName": "",
  "GitPassword": "",
  "GitBranch": "",
  "GitSyncBehavior": "TwoWay",
  "GitInitializeBehavior": "",
  "GitSyncInterval": "1",
  "ConfigurationScript": "",
  "ExternalGitClient": false
  "Mode": "Manual" // Or Automatic
},

Méthode 1 : Transmission des fichiers locaux vers le dépôt distant

L'emplacement par défaut du référentiel local est C:\ProgramData\UniversalAutomation\Repository

Vous devez vous assurer que votre dossier local n'est pas un référentiel git préexistant. Votre répertoire de référentiel doit simplement être un dossier contenant vos fichiers PowerShell Universal. Si un dossier .git existe et que vous ne souhaitez pas utiliser ce référentiel, vous devez le supprimer et PowerShell Universal en créera un nouveau.

Si vous remplissez un nouveau référentiel git, vous devez vous assurer que le dépôt distant ne contient aucun fichier. Il doit s'agir d'un référentiel complètement vide. Par exemple, lors de la création d'un référentiel sur GitHub, ne sélectionnez pas de licence ni de fichier readme.md à créer.

Une fois le référentiel 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 disposez de la branche, de l'URL du dépôt git distant et des informations d'identification, vous pouvez les fournir à votre fichier appsettings.json et le dépôt distant sera rempli avec vos fichiers locaux.

Méthode 2 : Extraction depuis un dépôt git distant

L'emplacement par défaut du référentiel local est C:\ProgramData\UniversalAutomation\Repository

Vous pouvez configurer PowerShell Universal pour extraire depuis un dépôt git distant. Dans cette configuration, vous devez vous assurer que votre dossier de référentiel local est complètement vide. Tout fichier présent dans le dossier entraînera l'échec de la synchronisation Git et l'empêchera de récupérer.

Configurez le fichier appsettings.json pour inclure la branche, les informations d'identification 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 sera de cloner le référentiel 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 du temps pour télécharger de grands référentiels ou pour les délais liés à des réseaux lents. Vous pouvez constater que le service PowerShell Universal reste bloqué 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.

"Data" : {
    "GitSyncTimeout": 30
}

Intervalle de synchronisation

Type : Entier Par défaut : 60 appsettings.json : GitSyncInterval

L'intervalle, en secondes, entre les tentatives de synchronisation Git automatique 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 :

"GitSyncInterval": 300

Cela changerait l'intervalle de synchronisation à 5 minutes. Des valeurs plus faibles augmentent la fréquence de synchronisation, mais peuvent avoir un impact sur les performances dans les grands référentiels ou les réseaux lents. Il n'est pas recommandé de définir cette valeur trop basse (en dessous de 30 secondes) pour les environnements de production.

Résolution des problèmes

Azure DevOps : « Too many redirects or authentication replays »

Cette erreur indique généralement l'un des problèmes suivants :

Format d'URL hérité : Assurez-vous d'utiliser https://dev.azure.com/<org>/<project>/_git/<repo> au lieu de l'ancien domaine visualstudio.com
Portée de PAT non valide : Votre jeton d'accès personnel doit avoir les autorisations Code (lecture et écriture) dans Azure DevOps
Informations d'identification expirées : Générez un nouveau PAT et saisissez-le à nouveau dans les paramètres Git de PSU
Espaces encodés : Si le nom de votre référentiel contient des espaces, assurez-vous qu'ils sont encodés sous la forme %20 dans l'URL

Résolution :

Mettez à jour l'URL distante pour utiliser dev.azure.com
Générez un nouveau PAT avec la portée Code (lecture et écriture)
Activez Utiliser le client Git externe 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 référentiel et exécutez :

git fetch
git branch --set-upstream-to=origin/main main
git pull

Remplacez main par le nom de votre branche réelle. Cliquez ensuite sur Synchroniser maintenant dans PSU.

La synchronisation Git s'arrête après la modification des paramètres dans l'interface utilisateur

Symptômes : Après avoir modifié les paramètres Git (URL distante, informations d'identification, intervalle de synchronisation, etc.) dans l'interface utilisateur 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 informations d'identification Git sont stockées dans la base de données SQL. Toute modification apportée aux paramètres Git via l'interface utilisateur peut effacer les informations d'identification stockées, même si le champ du mot de passe semble encore rempli dans le formulaire.

Résolution :

Saisissez à nouveau le jeton d'accès personnel dans Paramètres → Git
Cliquez sur OK pour enregistrer
Dans les environnements à plusieurs nœuds, répétez cette procédure sur chaque nœud — les informations d'identification doivent être saisies individuellement sur chaque serveur
Cliquez sur Synchroniser maintenant pour vérifier que la synchronisation fonctionne à nouveau

Le système ne propage pas automatiquement les informations d'identification 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 :

Inadéquation 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 via gRPC sur les ports 5000 (HTTP) ou 5001 (HTTPS)
Blocage de proxy ou 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 autorisent 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_proxy et https_proxy pour le compte de service PSU

Docker et déploiements conteneurisés

Assurez-vous que l'image du conteneur inclut git (exécutez git --version pour vérifier)
Vérifiez l'accès réseau sortant vers le dépôt git distant
Montez des volumes persistants pour /data ou %ProgramData%\UniversalAutomation pour préserver l'état git entre les redémarrages
Si la synchronisation échoue silencieusement, vérifiez les journaux du conteneur pour les erreurs git ou réseau

Modification de .git/config sans 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 directement la configuration du référentiel via le navigateur de fichiers de PSU :

Accédez à Plateforme → Configuration → Référentiel → .git → config
Ajoutez les lignes suivantes (ajustez le nom de la branche pour correspondre à votre référentiel) :

[branch "main"]
    remote = origin
    merge = refs/heads/main

Cliquez sur Enregistrer
Revenez à Paramètres → Git et cliquez sur Synchroniser maintenant

Cette approche vous permet de configurer le suivi amont sans avoir besoin de commandes git, ce qui est particulièrement utile lorsque Git pour Windows n'est pas installé ou lorsque vous exécutez 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érifiez les autorisations du système de fichiers :

Arrêtez le service PowerShell Universal
Essayez de modifier manuellement %ProgramData%\PowerShellUniversal\appsettings.json (ou %ProgramData%\UniversalAutomation\appsettings.json dans les versions plus anciennes)
Ajoutez une ligne de commentaire, enregistrez et 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 autorisations NTFS bloquent les écritures dans le répertoire de données PSU

Activez la journalisation de débogage pour la résolution des problèmes :

Arrêtez le service PowerShell Universal
Modifiez appsettings.json et définissez :

"SystemLogLevel": "Debug"

Enregistrez et redémarrez le service
Essayez d'enregistrer les paramètres Git à nouveau
Examinez %PROGRAMDATA%\PowerShellUniversal\systemLog.txt pour les erreurs liées aux écritures de configuration

Remplissez manuellement les paramètres Git :

Avec le service arrêté, vous pouvez directement remplir les champs Git dans appsettings.json :

"GitRemote": "https://dev.azure.com/org/project/_git/repo",
"GitUserName": "any",
"GitPassword": "your-PAT-here",
"GitBranch": "main"

Redémarrez le service et vérifiez que les paramètres apparaissent dans Paramètres → Git. S'ils disparaissent à nouveau, les journaux de débogage indiqueront si un problème d'autorisation, un logiciel de protection des points de terminaison ou une erreur de validation de configuration est à l'origine de la réinitialisation.

unknown certificate lookup failure: 16777280

Lors de l'utilisation de la bibliothèque git intégrée, vous pouvez rencontrer des problèmes de certificat lors de la connexion à des référentiels git hébergés localement. Dans cette configuration, nous recommandons d'utiliser le client git externe pour bénéficier d'un meilleur support pour la configuration du processus de recherche de certificat.

Fichiers inclus

Les fichiers inclus dans une synchronisation Git sont tous les fichiers présents dans le référentiel local. Cela inclut les fichiers de configuration PS1, les fichiers XML de pages et tous les autres fichiers que vous pouvez ajouter manuellement.

Les éléments suivants ne sont pas inclus :

appsettings.json
database.db
web.config
Binaires de l'application PowerShell Universal

Référentiels Git multiples

PowerShell Universal prend en charge le stockage de plusieurs configurations de référentiel git dans la base de données. Ce faisant, vous pouvez rapidement basculer entre différentes configurations de PowerShell Universal. Cliquez sur l'onglet Référentiels pour afficher les référentiels actuellement configurés. De là, vous pouvez supprimer et modifier les configurations de référentiel.

PowerShell Universal ne supprime pas le dossier .git lors de la suppression d'une configuration de référentiel. Vous devrez le faire manuellement afin de configurer un nouveau référentiel.

Lorsque vous ajoutez une nouvelle configuration de référentiel, vous pouvez cliquer sur le bouton Appliquer pour basculer vers le référentiel sélectionné. Cela supprimera tous les fichiers du répertoire du référentiel et clonera le référentiel sélectionné. Vous ne pouvez pas appliquer une configuration de référentiel s'il y a des modifications non validées dans votre référentiel. Après le clonage du référentiel, PowerShell Universal rechargera entièrement sa configuration.

Page d'historique et d'état Git

L'onglet d'historique affiche tout l'historique des validations git pour le référentiel actuel.

L'onglet d'état de synchronisation affiche l'état actuel des nœuds dans le cluster PSU.

Test de la synchronisation Git

La meilleure façon de s'assurer que votre synchronisation Git fonctionne correctement est de cliquer sur le bouton Synchroniser maintenant. Cela forcera l'exécution d'une synchronisation et vous pourrez vérifier si les paramètres saisis ont fonctionné correctement.

Affichage des modifications

Vous pouvez afficher les modifications dans le tableau des synchronisations git. Chaque synchronisation inclut le nombre de modifications trouvées depuis la dernière synchronisation, le SHA de la validation et une liste des modifications entre ce SHA et le précédent. Lorsque des fichiers sont dans un état modifié, vous pourrez afficher les différences à l'aide de l'outil de comparaison de fichiers.

Résolution des conflits

La résolution des conflits n'est disponible qu'en mode de synchronisation Git manuelle.

Lorsque plusieurs utilisateurs modifient les fichiers de configuration de PowerShell Universal, il peut y avoir des conflits. PowerShell Universal affichera qu'un nœud particulier est dans un état conflictuel lors d'une tentative de validation des modifications. Vous verrez une liste des modifications en conflit sur la page de validation git. Cliquez sur le bouton Résoudre le conflit pour afficher le conflit dans un éditeur.

Dans cet exemple, la chaîne pour ce point de terminaison a été modifiée à la fois sur le dépôt distant et sur le référentiel local.

Modifiez le texte pour supprimer le conflit.

Enregistrez les modifications et revenez à la page de validation git. Saisissez un nouveau message de validation pour le conflit de fusion et cliquez sur Valider les modifications.

Cela résoudra le conflit de fusion et transmettra les modifications au dépôt distant.

Comportement de la synchronisation Git

Bidirectionnel

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 avec le dépôt distant configuré.

Toutes les modifications apportées dans le dépôt distant seront extraites localement.

Si vous configurez la synchronisation Git avec un dépôt git distant préexistant, les modifications seront extraites et synchronisées localement. Vous ne pouvez pas avoir de modifications locales.

Si vous configurez la synchronisation Git avec un référentiel vide, les modifications locales seront synchronisées et le référentiel sera initialisé.

Unidirectionnel

Vous pouvez ajuster le comportement de la synchronisation Git en modifiant le paramètre GitSyncBehavior dans appsettings.json. Lorsqu'il est défini sur OneWay, la console d'administration et l'API de gestion deviennent en lecture seule. Le système PowerShell Universal extraira depuis le dépôt distant mais ne transmettra ni ne validera jamais localement.

    "Data": {
    "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository",
    "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db",
    "DatabaseType": "LiteDB",
    "GitRemote": "https://github.com/myorg/myrepo.git",
    "GitUserName": "any",
    "GitPassword": "MYPAT----------------"
    "GitBranch": "dev",
    "GitSyncBehavior": "OneWay",
    "ConfigurationScript": ""
  },

Transmission uniquement

Le mode de synchronisation Git en transmission uniquement n'extraira pas les modifications du dépôt distant. Toutes les modifications apportées localement seront transmises au dépôt distant. La console ne sera pas en lecture seule. Cette configuration est utile dans les scénarios où vous disposez d'un ordinateur utilisé comme source de vérité pour la configuration d'un pool de serveurs en lecture seule.

"Data": {
  "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository",
  "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db",
  "DatabaseType": "LiteDB",
  "GitRemote": "https://github.com/myorg/myrepo.git",
  "GitUserName": "any",
  "GitPassword": "MYPAT----------------"
  "GitBranch": "dev",
  "GitSyncBehavior": "PushOnly",
  "ConfigurationScript": ""
},

Jeton d'accès personnel

Nous vous 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é de mot de passe dans appsettings.json ou via d'autres méthodes de configuration.

    "Data": {
    "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository",
    "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db",
    "GitRemote": "https://github.com/myorg/myrepo.git",
    "GitUserName": "any",
    "GitPassword": "MYPAT----------------"
  },

Jetons à granularité fine GitHub

Dans GitHub, vous pouvez récupérer un jeton à granularité fine en cliquant sur votre avatar en haut à droite, en sélectionnant Paramètres, Paramètres développeur, Jetons d'accès personnels, puis Jetons à granularité fine.

Portées du jeton

Lors de la génération du jeton, assurez-vous de fournir l'accès Read-Write au référentiel pour l'autorisation Content. Cela ajoutera automatiquement l'accès en lecture à l'autorisation Metadata. Vous pouvez fournir l'accès uniquement au référentiel que vous souhaitez cloner.

Jetons GitHub (classiques)

Dans GitHub, vous pouvez récupérer un jeton d'accès personnel en cliquant sur votre avatar en haut à droite, en sélectionnant Paramètres, Paramètres développeur, Jetons d'accès personnels, puis Jetons (classiques).

Lors de la génération de votre jeton d'accès, assurez-vous de sélectionner les autorisations 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 également configurer un dépôt git distant 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 via une autre méthode de configuration.

    "Data": {
    "RepositoryPath": "%ProgramData%\\UniversalAutomation\\Repository",
    "ConnectionString": "%ProgramData%\\UniversalAutomation\\database.db",
    "GitRemote": "https://github.com/myorg/myrepo.git",
    "GitUserName": "myusername",
    "GitPassword": "mypassword"
  },

Erreurs courantes

Git synchronization failed. unknown certificate lookup failure: 16777280

La bibliothèque lib2gitsharp n'a pas pu valider le certificat du référentiel git distant. Vous devrez utiliser le client git externe et une configuration git personnalisée pour résoudre ce problème.

Certaines options courantes pour la prise en charge HTTPS de git incluent :

http.sslVerify
    Whether to verify the SSL certificate when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_NO_VERIFY environment variable.

http.sslCAInfo
    File containing the certificates to verify the peer with when fetching or pushing
    over HTTPS. Can be overridden by the GIT_SSL_CAINFO environment variable.

http.sslCAPath
    Path containing files with the CA certificates to verify the peer with when
    fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_CAPATH environment variable.

« too many redirects » ou rejeux d'authentification

Le dépôt git distant a rejeté vos informations d'identification pour accéder au référentiel. Votre jeton d'accès personnel a peut-être expiré ou n'a pas accès au dépôt distant.

repository not owned by current user

Le référentiel 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 référentiel et qu'un compte de service différent a ensuite été défini sur le service. Étant donné que 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 faire confiance au dossier. Définissez la valeur suivante dans la configuration git globale.

[safe]
directory = C:\ProgramData\UniversalAutomation\Repository

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 référentiel git. PowerShell Universal utilise des commandes très basiques lorsqu'il traite avec git. Toute modification apportée à PowerShell Universal via la console d'administration ou l'API invoque un git commit et l'auteur est défini sur l'identité de l'utilisateur effectuant la modification. Lors d'une opération de synchronisation Git, nous effectuons d'abord un git pull pour nous assurer que nous disposons de la dernière version des fichiers sur le dépôt distant. Ensuite, nous effectuons un git push pour transmettre les validations locales qui ont eu lieu depuis la dernière synchronisation.

Vous pourriez obtenir cette fonctionnalité avec une tâche planifiée.

Cela dit, l'une des fonctionnalités de la synchronisation Git est qu'elle analyse la validation pour s'assurer que seuls les fichiers modifiés lors de la synchronisation sont rechargés. Cela empêchera les tableaux de bord de se déployer automatiquement lorsqu'ils n'ont pas changé ou les services API de redémarrer lorsque les environnements n'ont pas été mis à jour. Il y a donc un gain de performances ici.

L'autre problème est que, 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 une extraction. Vous devrez vous assurer que vous forcez la réévaluation des configurations.

Stratégies de branchement

Les stratégies de branchement dans git dictent 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 peut garantir que des équipes de différentes tailles peuvent travailler efficacement ensemble dans la plateforme.

Utilisateurs uniques et petites équipes

Pour les utilisateurs uniques et les petites équipes, il peut ne pas être 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 les modifications. Les utilisateurs accéderont directement à PowerShell Universal pour apporter des modifications ou valider des modifications sur la branche unique à partir de clones locaux du répertoire du référentiel à l'aide d'un outil comme VS Code.

main - Branche unique qui accepte toutes les modifications directement

Utilisateurs uniques et petites équipes avec une branche de préproduction

Même les utilisateurs uniques et les petites équipes peuvent trouver avantageux d'utiliser une branche de préproduction, ou de développement. Cette branche recevra les modifications pendant le développement. Une instance autonome de PowerShell Universal sera configurée pour s'exécuter sur cette branche de développement afin que les utilisateurs puissent valider les modifications avant de les transmettre en production.

Lors de l'utilisation d'une configuration de branche de préproduction, 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.

Chaque instance de PowerShell Universal nécessite une licence. Dans cette configuration, deux licences seraient requises.

Une instance PowerShell Universal distincte peut ensuite être configurée pour pointer vers une branche principale, ou de production, qui recevra les mises à jour via des fusions ou des demandes de tirage dans un système comme GitHub. Dans cette configuration, il est possible d'utiliser la synchronisation Git unidirectionnelle pour extraire les modifications de la branche principale sans jamais transmettre depuis la plateforme. Cela évite également la plupart des conflits de fusion car ils seront traités dans la branche de développement ou via l'outil de fusion dans le référentiel source.

main - Branche de production qui reçoit les modifications des demandes de tirage de la branche dev
dev - La branche de préproduction utilisée pour accepter les validations et valider les modifications avant de les transmettre au master

Équipes de taille moyenne à grande

Lorsque l'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 du code et éviter les conflits de fusion. PowerShell Universal fournit des outils de fusion de base, mais de meilleurs outils sont disponibles à cette fin, tels que les demandes de tirage GitHub, les demandes de fusion GitLab et les 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 les modifications importantes dans la branche dev, les développeurs créeront leur propre branche de fonctionnalité qui contient toutes leurs modifications jusqu'à ce qu'elles soient suffisamment complètes pour être fusionnées dans la branche de développement.

PowerShell Universal fournit des licences développeur pour éviter d'avoir à acheter une licence pour chaque développeur de votre équipe. Des licences seraient toujours requises pour les environnements de production et de préproduction.

Dans ce type de configuration, le développement local est idéal car les développeurs travailleront sur leur instance PowerShell Universal locale dans leur branche de fonctionnalité. Lorsque la fonctionnalité est terminée, ils créeront une demande de tirage ou de fusion dans le référentiel source pour déplacer les modifications dans la branche dev. Les tests seront effectués sur la branche dev avant la fusion en production.

Similaire à une stratégie de branchement main\dev, toutes les instances PowerShell Universal seront isolées et ne partageront pas de base de données ni de planificateur.

Une fois qu'un ensemble de fonctionnalités est prêt pour la production, une demande de tirage ou de fusion sera effectuée de dev vers la branche principale.

main - Branche de production qui ne recevra les modifications que de dev
dev - Branche de préproduction qui reçoit les modifications des branches de fonctionnalités mais n'est pas modifiée directement
feature - Branche de fonctionnalité sur laquelle les développeurs valident directement et qui est fusionnée dans dev lorsqu'elle est prête

Selon la complexité de votre environnement, il peut être conseillé d'utiliser les déploiements plutôt que git en production. Consultez la section Grandes équipes ci-dessous pour plus d'informations.

Grandes équipes

Dans les grandes équipes, nous recommandons d'utiliser git à des fins de développement, mais d'utiliser les déploiements, ou un concept similaire, pour la production.

Les déploiements fournissent des packages de configuration immuables qui ont été bien testés dans les environnements inférieurs. En utilisant les déploiements, 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'assurance qualité 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 déploiements sans avoir à mettre à jour manuellement aucun système.

Hébergement Git

PowerShell Universal prend en charge toute solution d'hébergement git standard. Nos clients utilisent fréquemment les solutions suivantes :

GitHub
GitHub Enterprise
GitLab
Bitbucket
Azure DevOps

Bien que ce soient les plateformes les plus courantes, nous prenons en charge toute plateforme qui utilise 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 une utilisation avec PowerShell Universal.

PrécédentIndicateurs de fonctionnalité SuivantHébergement

Mis à jour il y a 1 mois

Ce contenu vous a-t-il été utile ?