Fin Décembre nous avons eu le privilège de vous accueillir pour notre Webinar sur les Workflows Git utilisés en entreprise et dans l’industrie. Nous avons discuté les deux workflows utilisés en interne à Atlassian et nous avons abordé des exemples concrets de réduction des points de friction au sein des équipes.

Pour bien commencer l’année, voici les slides de la présentation, la vidéo et toutes les réponses aux questions que vous aviez posées lors du webinar.

Vidéos du Webinar

Si vous voulez en savoir plus sur les techniques utilisés dans l’industrie et chez Atlassian, ce webinar devrait vous intéresser.

 

Slides

 

Questions / Réponses

En entreprise, est-ce qu’il est préférable d’avoir un(des) intégrateur(s) ou bien que chaque développeur puisse mettre à jour la branche stable/master par lui-même?

En entreprise, nous pensons que l’étape de revue du code est primordiale à l’évolution de votre application. Nous recommandons donc d’utiliser les pull requests. Cela vous permet de passer le code en revue avant qu’il ne soit intégré dans votre base de code. C’est une occasion parfaite pour discuter du code, pour trouver certaines erreurs et surtout pour faire évoluer votre code grâce au système de commentaire. Une fois la pull request validée (en général par au moins 2 développeurs) alors n’importe quel développeur peut intégrer le code dans la branche stable.

 

Quel modèle pour travailler avec un fournisseur?

Pour un fournisseur n’ayant pas besoin d’avoir accès à votre code source, tels qu’une application mobile ou HTML5 se basant sur votre API, nous conseillons un dépôt centralisé unique interne ce qui vous permettra de voir l’avancement du projet tout en gardant un contrôle total sur le code source ainsi que les droits d’accès. Vous pouvez même interdire le fork du projet en utilisant Stash ou Bitbucket.

Si vous travaillez avec un fournisseur ayant besoin d’interagir avec votre code source vous pouvez utilisez les forks ou les branches, tout dépend votre équipe, entreprise, workflow et de la confidentialité de votre code. Peu importe le choix que vous faites, nous recommandons l’utilisation des pull requests à chaque étape d’intégration.

 

Comment intégrer des développeurs sous-traitant avec git tout en conservant un certain degré de confidentialité du code ?

Les forks sont très utiles pour garder le contrôle sur votre code source. Cependant, en ce qui concerne la confidentialité, à moins de séparer encrypter ou compiler certaine partie de votre code, le développeur externe en question aura inévitablement accès au code source.

 

Comment sont implémentés – et enforcés – les droits d’accès ?

Vous pouvez utiliser Stash pour avoir un contrôle complet sur vos droits d’accès. Stash est une solution d’hébergement git pour entreprise et fonctionne en intranet.

 

Quelle est la bonne formule pour les projets où plusieurs développeurs travaillent sur les mêmes fichiers, et éviter les conflits ou bien les gérer?

Il n’y a pas vraiment de formule magique, si deux développeurs travaillent sur le même fichier et changent les mêmes choses dans le code alors il risque d’y avoir des conflits.

Faire des commits plus régulier et plus « petits » permet de faciliter la résolution de ces conflits.

De plus, la planification du développement et des sprints reste importante, en utilisant des épiques clairement définies par user story pour vos fonctionnalités vous aurez une idée claire du travail en amont, permettant a chacun pouvoir anticiper les conflits potentiels lors du développement. Et si deux développeurs doivent absolument travailler sur le même code, envisagez le « pair programming ».

 

Livraison en cycle: si le master est considéré comme une version Alpha ou RC, comment peut-il être en production?

Lors de l’utilisation d’un workflow de livraison en cycle (ie: en version 2.0, 2.1, 2.2 …), le master en versions Alpha / RC n’est pas en production, il évolue en permanence en parallèle (features) de la version en production (bug fix & hot fix) et ce n’est qu’au moment de la « release » qu’une nouvelle branche est créée pour remplacer la version en production ou devenir la nouvelle version de votre application.

 

Quelles différences entre branches stables et branches de release?

Si vous travaillez dans un système de livraison en cycle vous aurez plusieurs branches stables 2.1, 2.2, 2.3 correspondant aux différentes versions de votre application que vous avez déjà livrées.

Les branches de release, elles, sont à plus courte durée de vie, et servent à préparer votre nouvelle version à partir de votre branche master. En général il ne reste que des « détails » liés à la livraison à gérer au moment de la création de ces branches.

 

Peut-on faire une pull request vers plusieurs branches en même temps (exemple stable 2.2 et master)?

Oui mais pas directement, vous devez mettre en place les merges en cascade. Git: Automatic Merges With Server Side Hooks (For The Win!)

 

Dans l’organisation des branches, comment gérez-vous la validation des fonctionnalités par l’équipe QA, de façon à ce que seules les fonctionnalités validées passent sur les branches stables (staging et master)?

Tout dépend où vous placez quel type de QA. Nous avons évidemment un premier niveau grâce aux pull requests, à ce moment les équipe de testeurs et/ou design peuvent être impliqué si besoin est.

Ensuite, si on considère qu’il est nécessaire de faire plus de QA parce que nous avons une fonctionnalité qui regroupe plusieurs user stories et donc plusieurs branches de développement, nous pouvons créer une autre branche temporaire qui va permettre ceci. L’ensemble des user stories à valider sera mergé (via pull request) dans cette nouvelle branches. Une version de validation de l’application sera contruite et, une fois validée, cette branche sera fusionnée dans la branche stable.

 

Merge automatique marche aussi avec Bitbucket?

Pas à l’heure actuelle.

 

Comment migrer un dépôt SVN sous git?

Cela demande un peu de préparation, la procédure est très bien expliquée sur notre site:https://www.atlassian.com/fr/git/migration et dans le blog (en anglais) Human side of the migration to git.

 

Quand utiliser git merge, git pull, git rebase?

Découvrez toutes les commandes git et les workflows utilisés en entreprise sur notre mini site git https://www.atlassian.com/fr/git

 

Est-il possible pour un développeur de supprimer une branche ou un commit du repo? Est-il possible de perdre du code?

En général le développeur ayant créé une branche a tous les droits sur celle-ci et peut donc la supprimer, cependant, avec git vous ne perdez pas l’historique de vos changements. Le reflog enregistre tout pendant 30 jours et vous pouvez utiliser les tags pour gardez vos changements indéfiniment.

De plus, en fonction des droits attribués à cet utilisateur, en utilisant un outil comme Stash, celui-ci ne pourra pas effectuer de changement dans le repo git central sans au moins passer par une pull request. Il sera donc impossible de perdre du code. De plus git ne permet pas de modifier directement le dépôt. Pour effectuer un changement dans un commit voir même le supprimer, il faut créer un nouveau commit. Tout peut donc être récupéré grâce au reflog.

 

Le versioning (tags) est-il fait automatiquement via le système d’intégration continue (CI) ou manuellement, ou les deux?
Les deux, les tags de versioning git sont créés manuellement et vous pouvez utiliser un outil comme JIRA, Bamboo, Jenkins… Pour gérer le versioning de votre projet indirectement grâce à un système de branche intégré ou par des scripts d’intégration continue.

 

Est-ce une bonne pratique de faire un rebase à chaque pull request avec un pull –rebase ?

Le –rebase de vos pull requests peut améliorer la lisibilité de l’évolution du produit, et dans la mesure du possible, c’est une pratique intéressante. Très peu d’équipes à Atlassian force le rebase cependant.

 

Les développeurs doivent-ils créer une branche perso à partir d’une branche de fonctionnalité ou travaillent-ils directement sur la branche de feature?

Cela dépend de votre fonctionnalité. En général on fait en sorte d’avoir un minimum de développeurs sur une même branche. Pour en apprendre plus (en anglais) Feature branch development workflow.

Attention, lorsque l’on parle de fonctionnalité on veut souvent dire « user story ». À la différence des fonctionnalités, les user stories ont une durée plus courte et existent souvent entre 24 et 72 heures. Pour en savoir plus (en anglais): Inside Atlassian: feature branching on the Stash team

 

Des conseils sur le choix d’un client git sous Windows? Git Bash est un bon choix, mais est-il pensable d’utiliser le plugin Eclipse pour une intégration facile avec l’environnement de développement ?

Oui, notre client Git pour Windows SourceTree et JIRA ainsi que notre Connecteur IDE pour les autres services liés au développement.

Pour une intégration de git dans Eclipse, vous pouvez utiliser http://www.eclipse.org/egit/ et le connecter avec Stash ou Bitbucket.

 

Si on utilise un dépôt git centralisé, l’avantage par rapport à Subversion est-il uniquement les hooks ?

git offre de nombreux avantages par rapport à subversion: offline (pas besoin de parler au serveur distant pour effectuer un commit ou un merge), rapidité (tout est en local), branches et forks simplifier, workflows flexibles, pull requests

 

Quelle est la valeur ajoutée d’un outil comme Crucible lorsque la revue de code se fait via les pull request ?

Crucible est un outil plus puissant est permet une exploration plus complète de votre code pour faire du refactoring. Crucile a aussi l’avantage de supporter d’autres outils de gestion des sources et ainsi donner un accès commun à tous vos dépôts quand vous utiliser en même temps SVN, git et d’autres.

 

Dans le cadre d’une intégration continue, conseillez-vous de synchroniser régulièrement les branches avec le master?

Oui et non, l’intégration continue a pour objectif d’accélérer vos cycles de développement, cependant, vous ne devriez JAMAIS synchroniser du code non testé, ni revu.

 

Est-il possible de « personnaliser » le Git-flow intégré dans SourceTree? (les branches support ne sont pas encore supportées par exemple, on pourrait également vouloir avoir plus de libertés dans la création de branches release,…)

Non, cependant JIRA offre une très grande flexibilité en terme de customisation de Workflow git.

 

Quel est l’ambassadeur pour la Suisse ?

Nous n’avons malheureusement pas encore d’ambassadeur en Suisse.

Mais nous avons un bureau à Amsterdam, passez nous voir quand vous serez dans le coin. Nous avons aussi une super communauté présente à nos Atlassian User Group. N’hésitez pas à visiter https://aug.atlassian.com/display/AUG/Join an AUG pour trouver une ville près de chez vous OU rajouter la vôtre sur la carte.

Vous en voulez plus?

Vous voulez en apprendre plus sur git? Inscrivez-vous à notre newsletter Git pour rester à jour sur les bonnes pratiques.

Prêt à essayer Stash?

Démarrez en quelques minutes grâce à la version d’évaluation gratuite de Stash

 

Sans oublier!

J’en profite pour vous rappeler:

Les licences gratuites pour tous les étudiants grâce au programme Classroom.

Les licences gratuites pour les projets Open Source.

Les licences starter reversées intégralement à l’association Room to Read.

 

N’oubliez pas de suivre Atlassian sur: