Guide d’utilisation pour Git

Name: Guide d’utilisation pour Git
Uploaded: 2017-12-09T14:33:41+00:00
Duration: PTM26S7
Channel: Melanie Marchand
Description: Guide d’utilisation pour Git

SOFT BW6 Generator Guide d’utilisation pour Git

Guide d’utilisation pour Git
05 Génération d’une « unité de développement » 01 Introduction 06 Gestion des branches Git 02 Configuration de Gitlab 07 Tags et génération de packages 03 Configuration du plugin SOFT BW6 Generator 08 Déploiement de packages 04 Initialisation du workspace

Introduction

Introduction Objectifs
Les objectifs du Team Provider Git pour le plugin SOFT BW6 Generator sont : gérer le code généré par le plugin à l’aide du gestionnaires de sources Git (à iso-fonctionnalités avec le Team Provider SVN) permettre l’utilisation des fonctionnalités de Git non présentes dans les autres gestionnaires de sources (« cheap branching », « décentralisation », « rapidité »…) en apportant une forte valeur ajoutée à l’utilisation de Git En particulier : simplifier la création des dépôts Git et des branches faciliter la gestion du code notamment la fusion des différentes branches en proposant un « workflow » adapté à Git prendre en compte les spécificités de BusinessWorks 6 qui auraient pu poser des problèmes avec Git (gestion des fichiers à ignorer, rafraîchissement des projets après changement de branche, …) proposer un modèle adapté à SOFT MDA laisser la possibilité d’utiliser Git hors du cadre de SOFT (ligne de commande, outils graphiques ou Web…) en toute réversibilité

Organisation des dépôts Git
Arborescence des projets de delivery BW6 Groupe Git (GitLab) root : dépôt Git (1 seule branche master) Specifications : dépôt Git (1 seule branche master) : sous module de root Packages : dépôt Git (1 seule branche master) : sous module de root projects : Projet1 : dépôt Git (sous-module de root) Projet2 : dépôt Git (sous-module de root) TestData : dépôt Git (1 seule branche master) : sous module de root <Workspace Eclipse> Documents/Specifications Packages projects Projet1 Projet2 TestData L’outil de gestions des dépôts Git est GitLab, il nécessite la création d’un groupe Le dépôt principal (root) ne contient pas de sources et n’est constitué que d’une seule branche Packages = le dépôt des packages binaires, Specifications = celui des spécifications, TestData = celui des jeux de tests Projet1, Projet2 = projets au sens SOFT/MDA Chaque projet au sens SOFT/MDA (ex : Projet1) est un dépôt Git, sous-module du dépôt root Chaque projet au sens SOFT/MDA est constitué des branches suivantes : master = reflet des sources livrées en PRD release = reflet des sources validées pour INTEGRATION/QUALIF (ex: LOT1, LOT2 etc..) develop-feature-x, develop-feature-y = branches de développement de nouvelle fonctionnalités qui devront nécessairement avoir pour parent une release donnée

Processus du delivery BW6
déploiement vers Nexus Processus du delivery BW6 Ligne de vie d’un projet (au sens MDA) package des applications modifiées uniquement commit (Git) push (Git) Dépôt packages master master checkout -b (Git) generate (SOFT) merge (Git) (= promotion) Package du projet (N appli) tag release-X checkout -b (Git) generate (SOFT) commit (?) commit (Git) merge (Git) push (Git) push sur projects (Git) branches commit (Git) merge (Git) push (Git) push sur projects (Git) develop-feature-X checkout -b (Git) generate (SOFT) develop-feature-Y Dépôt d’un projet (= PRJ_NAME)

Configuration de Gitlab

Prérequis et convention Le serveur Gitlab est accessible à l’adresse Un groupe doit être créé dans lequel les dépôts Git seront créés par le plugin Un utilisateur de type Master sur le groupe* est nécessaire Guest < Reporter < Developer < Master < Owner les permissions du type Master permettent de créer des dépôts Git cet utilisateur peut notamment utiliser l’API Gitlab avec son « Private Token » * s’il n’est pas possible d’avoir les droits Master sur le groupe, voir la « Création manuelle des dépôts » Une version récente (8.+) de Gitlab est requise version de l’API Gitlab : v3 Une connaissance des bases de Git est nécessaire Tutoriel en ligne :

Création d’un « New Group » Création d’un groupe Gitlab Le plugin nécessite la création d’un groupe Gitlab Action accessible à l’adresse Cliquer sur « New Group »

Les options de « New Group » Création d’un groupe Gitlab Le groupe s’appelle bw6-projects Possibilité d’ajouter une description La visibilité Internal est recommandée Terminer l’action en cliquant sur « Create Group »

Le groupe créé Création d’un groupe Gitlab Le groupe Gitlab créé est accessible à l’adresse Cette URL sera nécessaire pour la configuration du plugin Aucun projet n’est créé Aucun projet n’est à créer dans Gitlab

Les membres du groupe Gestion des utilisateurs Pour gérer les utilisateurs du groupe L’utilisateur qui a créé le groupe est Owner NB : Owner > Master Un utilisateur Master peut être créé L’utilisateur Owner peut aussi être utilisé

Le Private Token de l’utilisateur Configuration d’un utilisateur L’utilisateur qui utilise le plugin doit avoir au minimum le rôle « Master » pour pouvoir créer des projets (et donc des dépôts Git) Le « Private Token » de l’utilisateur est requis Il peut être récupéré à l’adresse Cette valeur sera nécessaire pour la configuration du plugin

Création d’un nouveau dépôt Création manuelle des dépôts Cette méthode manuelle n’est à appliquer que dans deux cas : impossibilité d’utiliser l’API Gitlab (version trop ancienne de Gitlab, l’utilisateur n’a pas de Private Token ou n’a pas l’autorisation d’utiliser l’API) impossibilité d’accorder les droits Master sur le groupe Sur la page du groupe ( projects) cliquer sur « New Project » la page de création d’un dépôt va s’afficher…

Informations du nouveau dépôt Création manuelle des dépôts Pour chaque dépôt à créer, il faut indiquer le nom dans le champ « Project name » en respectant la casse La liste des dépôts à créer est : root Packages Specifications TestData <NOM_PROJET_DANS_MDA> Il faut donc effectuer l’étape de création d’un dépôt 5 fois

Ajout des utilisateurs dans les dépôts créés Création manuelle des dépôts Pour chaque dépôt créé (donc a minima les 5), il faut ajouter les utilisateurs concernés dans les membres du dépôt Par exemple l’URL du dépôt créé (à adapter pour chaque dépôt créé), ici « root » est : Le menu « Members » permet d’afficher la page de gestion des membres d’un dépôt…

Ajout des utilisateurs dans les dépôts créés Création manuelle des dépôts Dans le premier champ, il faut ajouter tous les utilisateurs concernés Il faut ensuite leur donner le rôle Master dans le deuxième champ Enfin les membres sont ajoutés en cliquant sur « Add to project » Il faut répéter l’ajout des membres dans tous les dépôts créés manuellement

Création d’un fichier sur un dépôt Création manuelle des dépôts Pour les dépôts associés à des projets SOFT/MDA, il faut créer au moins un fichier sur la branche master Exemple d’un projet de flux : « SERVICE_PROJECT ». Sur la page du dépôt (par ex: projects/SERVICE_PROJECT) : Utiliser le menu « New file » Dans la page qui s’affiche, il suffit de créer un fichier comme par exemple un fichier « README.md ». Le contenu n’a pas d’importance Cliquer sur « Commit Changes »

Configuration du plugin SOFT BW6 Generator

Configuration du plugin
Les préférences Git du plugin Préférences La page « Git provider references » doit être configurée Git group URL Git user & Git password Git admin password le « Private Token » de l’utilisateur Enable Git provider : cochée Cliquer sur « Apply » pour valider et enregistrer les préférences Groupe Gitlab utilisateur & mot de passe Private Token

Configuration du plugin
Les préférences Git du plugin Préférences Sur la page « SOFT generator BW6 plugin » Sélectionner l’implémentation « Git Provider » pour le Team provider Cliquer sur « Apply » pour valider et enregistrer les préférences Cliquer sur OK pour quitter Le workspace est prêt à être initialisé Git Provider sélectionné

Initialisation du workspace

Définition d’un « workspace » Un « workspace » (au sens d’Eclipse / TIBCO Business Studio) est un dossier contenant : des dossiers de métadonnées et de configuration des différents plugins Eclipse (.bsProject, .com.tibco.bw.rad, .metadata) le dossier du gestionnaire de version (.git dans notre contexte ou .svn dans le cas SVN) les projets au sens SOFT/MDA (un sous-répertoire du dossier projects par projet, chacun étant un dépôt Git indépendant) les projets annexes nécessaires au fonctionnement de SOFT (Documents/Specification, Packages, TestData, chacun étant un dépôt Git) Par défaut après le premier démarrage de TIBCO Business Studio, le workspace ne contient que les dossiers de métadonnées Le plugin SOFT BW6 Generator gère : l’initialisation la synchronisation le chargement des projets

Le groupe est vide Sans aucun dépôt existant On se place dans le cas où : le groupe est vide aucun flux ou service n’a été créé Le plugin va créer automatiquement les dépôts nécessaires : si Gitlab est utilisé si les dépôts à créer sont en local

Sélection du profil MDA Sans aucun dépôt existant A l’aide du menu « Projects selector » sélectionner un profil MDA dans la boîte de dialogue « SOFT project switcher wizard » le plugin demande pour cloner le dépôt, même s’il n’existe pas les dépôts nécessaires sont créés et clonés dans le workspace

Projets créés par défaut Sans aucun dépôt existant 4 dépôts Git ont été créés 3 projets Eclipse ont été créés et importés Packages Specifications TestData Le workspace est prêt pour générer des unités de développement

Génération d’une unité de développement

Différents cas de figure Rappels, une unité de développement… … est une unité de travail quantifiable … est composée concrètement de fichiers (processes, ressources, schémas, …) contenus dans différents projets au sens d’Eclipse rattachés à un projet au sens SOFT/MDA (cf. slide suivant) … aura ses fichiers sauvegardés dans un dépôt Git associé à son projet au sens SOFT/MDA La génération d’une unité de développement peut s’effectuer en partant de plusieurs situations aucune autre unité de développement n’a été générée  il n’y a donc aucun fichier sur le dépôt correspondant NB : le dépôt correspondant peut même ne pas encore exister une autre unité de développement, rattachée au même projet SOFT/MDA a déjà été générée NB : le dépôt correspondant existe donc déjà si tous les changements de l’autre unité de développement sont bien soumis et poussés (commit & push) avant la génération  pas de problème une autre unité de développement (ou la même) a déjà été générée en local sans être soumise et poussée  conflits

Création d’un service sans conflit Aucun projet n’a été créé  il ne peut y avoir de conflit de versions Nom du service : service1_1 Nom du projet : PRJ1 La branche par défaut est « release » la branche sera créé automatiquement les commits doivent être faits sur des branches de développement comme « release » la branche « master » contient le code déployé en production

Commit & push du projet TestData Commit & push du projet TestData Le projet transverse TestData contient désormais un dossier pour le projet PRJ1 (il contiendra les jeux de tests pour ce projet) Il faut ajouter (= cocher) tous les fichiers Ecrire un commentaire de commit Cliquer sur « Commit and Push » Une fenêtre de confirmation du « Push » s’affiche

Commit & push des projets BusinessWorks Commit & push des projets BusinessWorks Les projets BusinessWorks sont générés en fonction des templates SOFT et des métadonnées de MDA Il faut ajouter (= cocher) tous les fichiers Ecrire un commentaire de commit Cliquer sur « Commit and Push » La branche étant nouvelle, des fenêtres pour le premier « push » vont s’afficher… suite

Commit & push des projets BusinessWorks Commit & push des projets BusinessWorks … ces fenêtres contiennent par défaut les bons paramètres « Remote: origin » Il s’agit du nom par défaut dans Git pour désigner le dépôt « upstream » « Configure upstream for push and pull » Précise à Git qu’il devra tirer (pull) et pousser (push) depuis et sur cette branche distante pour la branche locale considérée (à savoir « release ») « Merge upstream commits into local branch » Précise à Git de fusionner les changements de la branche local dans la branche distante (plutôt que d’écraser) Cliquer sur « Next » puis sur « Finish » dans la fenêtre de résumé Une fenêtre de confirmation du « Push » s’affiche

L’unité de développement générée L’unité de développement générée Dans la vue « Project Explorer » d’Eclipse on retrouve les différents projets générés avec le nom du dépôt associé ainsi que sa branche courante entre crochets, soit : pour le dépôt PRJ1 branche release MessageFlowsBusinessSharedPRJ1 PRJ1.application PRJ1.application.parent ServicesBusinessShared SOFTSyncOrchestrator pour le dépôt Packages branche master Packages pour le dépôt Specifications branche master Specifications pour le dépôt TestData branche master TestData Ces informations seront utiles par la suite pour les opérations de branchement et de fusion

Création avec synchronisation / résolution de conflit Pour démontrer l’utilité du « Git Team Provider », voici un scénario un peu plus complexe Dans un workspace Eclipse différent (= celui d’un autre développeur), créer une deuxième unité de développement dans le même projet au sens SOFT/MDA initialiser le workspace avec le même profil MDA générer une autre unité de développement sur la même branche que précédemment (release) faire un « commit & push » Revenir dans le premier workspace le workspace est déjà initialisé mais n’est plus à jour car une autre unité de développement vient d’être envoyée sur le dépôt créer le même service que ci-dessus  le plugin alerte que le workspace n’est pas à jour et propose la synchronisation Ce scénario est détaillé dans les slides suivants

Initialisation d’un deuxième workspace
Sélection du profil MDA et du projet SOFT/MDA Avec des dépôts existants A l’aide du menu « Projects selector » sélectionner le même profil MDA que précédemment dans la boîte de dialogue « SOFT project switcher wizard » le plugin demande pour cloner le dépôt « root » qui contient les références vers tous les autres dépôts Git (en tant que sous- modules) les dépôts nécessaires sont clonés dans le workspace les contrôles de la boîte de dialogue sont mis à jour avec par défaut : Projet : PRJ1 Branche : release après « Finish », le plugin clone le dépôt du projet PRJ1 et se place sur la branche release

Avec des dépôts existants La branche sélectionnée release est à jour puisque le dépôt vient d’être cloné La génération de l’unité service2_1 ne posera donc pas de problème au niveau de Git La nouvelle unité de développement va insérer des fichiers dans les mêmes projets que l’unité générée précédemment  sélectionner « No » pour ne pas recréer les modules existants

Commit & push des projets BusinessWorks Avec des dépôts existants La branche sélectionnée release est à jour puisque le dépôt vient d’être cloné La génération du service2_1 ne posera donc pas de problème au niveau de Git Le nouveau service va insérer des fichiers dans les mêmes projets que le service généré précédemment  sélectionner « No » pour ne pas recréer les modules existants Il est possible de faire un « Commit and Push » de l’unité qui vient d’être créée le commit a pour hash f774bbc

Génération nécessitant une synchronisation
Synchronisation avant génération Sur le premier workspace on se replace sur le premier workspace le workspace est déjà initialisé mais n’est plus à jour car une autre unité de développement vient d’être envoyée sur le dépôt (depuis le deuxième workspace) la synchronisation est simple : il suffit de faire un git pull pour récupérer le commit f774bb de la génération du deuxième workspace soit avec le bouton de la vue Synchronize soit simplement avec la commande git pull en ligne de commande il est maintenant possible de générer une unité de développement dans le premier workspace

Gestion des branches Git

Création d’une nouvelle branche Création d’une nouvelle branche dans la boîte de dialogue « SOFT project switcher wizard », cliquer sur « Add branch » sélectionner une « source branch » NB : seules les branches présentes sur le dépôt distant sont proposées donner un nom pour la nouvelle branche NB : le préfixe « develop- » est automatiquement ajouté (configurable dans les préférences du plugin)

Sélection d’une nouvelle branche Sélection d’une nouvelle branche la branche créé précédemment est disponible dans la liste déroulante « Select a branch » sélectionner la branche develop-feature-1 le projet est automatiquement basculé vers cette nouvelle branche tant que la branche n’est pas poussé, les modifications resteront locales

Commit & push sur une nouvelle branche Commit & push sur une nouvelle branche effectuer une modification sur un fichier d’un projet BusinessWorks afficher la vue « Git Staging » à l’aide du menu contextuel « Team  Commit… » vérifier que les fichiers modifiés à prendre en compte sont bien dans « Staged Changes » cliquer sur « Commit and Push… »  la branche est poussée sur le dépôt distant pour la première fois

Tags et génération de packages

Création d’un tag Création d’un tag La création d’un tag se fait à l’aide du menu contextuel « SOFT  Tags included units of a single application to MDA » en se plaçant sur un projet d’application Un tag Git est généré sur le dépôt du projet

Génération d’un package depuis un tag Génération d’un package depuis un tag

Déploiement de packages

Déploiement d’un package sur un AppSpace Déploiement d’un package sur un AppSpace

Guide d’utilisation pour Git

Présentations similaires

Présentation au sujet: "Guide d’utilisation pour Git"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Guide d’utilisation pour Git

Présentations similaires

Présentation au sujet: "Guide d’utilisation pour Git"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back