Développement en équipe avec Git

Version imprimable

25/12/2018, 15h44
shellwhale

Développement en équipe avec Git

Bonjour !
Je suis étudiant et avec les copains on a pour projet un site web.
Seulement je me rends compte que se répartir les tâches efficacement ce n'est pas quelque chose de simple.
L'école nous fourni un abonnement Microsoft Azure, donc on a accès à Azure DevOps, les fonctionnalités proposées ont l'air chouettes. J'ai mis le repo là dessus et on compte utiliser ça.
Seulement je n'ai aucune idée de comment fonctionne le développement en groupe, je ne sais pas quelle approche utiliser, quel genre de conventions appliquer entre nous, vraiment je suis perdu.

Est-ce qu'il n'y aurait pas un tutoriel de qualité reprennant les bonnes pratiques pour du développement en équipe avec Git ?
26/12/2018, 11h26
Drowan
:salut:
Ce qu'il faut se définir entre collaborateur c'est ce qui te permettra d'aller dans le même sens et de se comprendre facilement.
Voici quelques points qu'il faut définir (sans ordre d'importance) :
1. Les interfaces : En gros ce que chacun va utiliser de l'autre. Par exemple si ta partie envoie un message à la partie de Toto, il faut te mettre d'accord à l'avance avec Toto de quelle est le format du message, dans quel ordre sont mises les infos, quel entête, quel séparateur, etc...
2. Le nommage : Comment vous appelez les choses. C'est une manière d'éviter les ambiguïté lors des communications et de donner un aspect global au code. Par exemple nommer toutes les choses en anglais, se mettre d'accord que les identifiant on appelle tout le temps ça "ID" et jamais "Key", etc...
3. La documentation : Là le point c'est de se mettre d'accord sur le fait qu'il faut documentre/commenter. Comme vous allez utiliser du code développer par un autre, il est très important de commenter son code, voir de le documenter. Ainsi il n'y a pas d'embrouille sur ce que font les codes. Faire cela avant de se mettre à coder permet également de se mettre plus clairement d'accord sur l'architecture, sur qui fait quoi, et de pouvoir suivre l'avancement.
4. Se voir régulièrement : Ça permet de pouvoir faire évoluer ce qui a été fixé en fonction de l'avancement ou des nouvelles contraintes.
Y'a surement d'autres choses, mais voilà des points auquel je fais toujours gaffe quand on travail en groupe.
28/12/2018, 13h07
Sodium

Penser à utiliser les branches.
Une nouvelle fonctionnalité = une branche. Une fois qu'elle est finie et qu'elle a été testée, on la push.

Mettre en place des tests unitaires dès que possible est également une bonne idée. Toute modification dans un code a une fâcheuse tendance à impacter des choses que l'on ne soupçonne pas.
05/01/2019, 19h54
Obsidian
Bonjour,

Citation:

Envoyé par shellwhale

L'école nous fourni un abonnement Microsoft Azure, donc on a accès à Azure DevOps, les fonctionnalités proposées ont l'air chouettes. J'ai mis le repo là dessus et on compte utiliser ça.

Attention toutefois à ne pas en devenir dépendant. Tant au niveau financier qu'à celui des conditions d'utilisation, qui peuvent varier avec le temps. L'avantage avec Git est qu'il est fait pour être décentralisé, donc chaque dépôt local, lorsqu'il est à jour, est une copie certifiée conforme de l'état d'un même projet sur un autre dépôt. Il est donc relativement facile de redéployer un projet ailleurs, mais il faut quand même avoir une certaine habitude de l'outil.

Le mieux reste de s'auto-héberger quand on le peut, surtout que Git ne réclame pas grand chose : il s'appuie sur le système de fichier du serveur hôte et communique via SSH ou HTTP. Il est donc extrêmement rapide de déployer un serveur Git quelque part. Si vous avez accès aux serveurs de l'école depuis l'extérieur, ça pourrait être la bonne solution. Sinon, il existe plusieurs forges gratuites autorisant les projets privés de petite envergure (par exemple, jusqu'à cinq développeurs pour Atlassian).

Citation:

Seulement je n'ai aucune idée de comment fonctionne le développement en groupe, je ne sais pas quelle approche utiliser, quel genre de conventions appliquer entre nous, vraiment je suis perdu. Est-ce qu'il n'y aurait pas un tutoriel de qualité reprennant les bonnes pratiques pour du développement en équipe avec Git ?

Personnellement je suis devenu fan des règles du développement du noyau Linux, pour lequel Git a d'ailleurs été conçu (et auxquelles il est donc particulièrement adapté). Je les trouve particulièrement élégantes et c'est aujourd'hui celles que j'applique à mes propres développements (même seul).

Parmi elles, il est demandé d'éviter ceci pour, au contraire, regrouper ses changements en « unités logiques » et préparer des commits distincts et propres pour chacune d'elles. Par exemple, la suppression en une fois de tous les commentaires obsolètes des fichiers d'un sous-module, la correction d'un bug, l'ajout d'une fonctionnalité, etc. Ceci permet à la fois d'éviter de mélanger dans un même changeset des choses qui n'ont rien à voir entre elles, mais comme tout ceci est censé, au départ, être soumis par mail à un mainteneur via une série de patches, ceci permet à ce dernier de rejeter éventuellement certains de nos patches tout en validant l'intégration des autres. Soumettre un travail trop sale et trop intriqué étant un risque, pour le développeur, de voir rejetée l'intégralité de son travail.

C'est pratique également a posteriori, lors des revues de code. Un git blame permet de retrouver facilement quel est le dernier commit en date à avoir modifié une ligne donnée. De là, il est appréciable de retrouver un changeset complet (pour avoir le contexte dans lequel cette modification a été apportée) et bien documenté. C'est également utile si l'on doit retirer un changeset qui s'avère poser problème à l'usage. Si le commit a été bien construit dès le départ, il est possible de l'annuler facilement pendant un certain temps même si d'autres changements ont eu lieu entre temps.

Au niveau de la documentation du commit lui-même, on pourrait résumer ça par « dites ce que fait le commit, pas ce que vous avez fait ». En général, dans le corps du message, on fait quand même les deux. Mais avec le projet Linux, il est possible de séparer les deux parties avec un marqueur spécial, de façon à ce que les commentaires persistent sur la mailing list (sur laquelle les patches sont systématiquement relayés) mais que seule la synthèse des changements apportés sur réellement enregistrée dans le dépôt Git.
Citation:
Envoyé par Drowan

La documentation : Là le point c'est de se mettre d'accord sur le fait qu'il faut documentre/commenter. Comme vous allez utiliser du code développer par un autre, il est très important de commenter son code, voir de le documenter. Ainsi il n'y a pas d'embrouille sur ce que font les codes. Faire cela avant de se mettre à coder permet également de se mettre plus clairement d'accord sur l'architecture, sur qui fait quoi, et de pouvoir suivre l'avancement.
J'ajoute que l'avantage d'utiliser un logiciel de versioning est que cela permet de conserver son code toujours propre.

Avec des fichiers ordinaires, quand on se retrouve à devoir supprimer un grand bloc bien écrit, que l'on a pris du temps à concevoir et à mettre au point, parce qu'il devient obsolète, on a en général tendance à le mettre en commentaire pour le conserver au sein du code. Même chose pour les fichiers de configurations : les changements d'URL, de mots de passe, de type de configuration pour un serveur, etc. Tout cela est précieux et on aimerait les conserver… ne serait-ce que pour pouvoir revenir en arrière si jamais la nouvelle configuration ne fonctionne pas. C'est ainsi qu'on se retrouve avec deux ou trois générations de configurations successives mises à la suite en commentaire au sein du code source.

Avec un logiciel de versioning, c'est fini : il faut prendre l'habitude de supprimer sans vergogne tout ce qui n'est pas en vigueur dans la version sur laquelle on travaille. Non seulement parce que ça permet de conserver un code toujours clair avec le temps (ce qui devient critique avec les grands projets, encore plus si on travaille à plusieurs dessus) mais également parce que cela permet de voir un coup d'œil ce qui a réellement changé d'une version à l'autre. Les blocs « en rouge » (suppressions de lignes) sont aussi informatifs que ceux en vert (ajouts). Même lorsque ces versions sont très éloignées ou qu'elles se trouvent sur deux branches différentes.

Citation:

Envoyé par Sodium

Penser à utiliser les branches.
Une nouvelle fonctionnalité = une branche. Une fois qu'elle est finie et qu'elle a été testée, on la push.

Il y a aussi une « règle » qui l'on retrouve souvent dans les équipes de développement : « ne pas réécrire l'histoire ». Autrement dit : impossibilité de retirer un commit qui a été rendu public (poussé sur le dépôt commun). On demande à la place, et si c'est nécessaire, de pousser un nouveau commit annulant les changements du précédent. Il existe git revert pour faire cela automatiquement avec un commit donné. Ceci est dû au fait qu'une fois publiée, le reste de l'équipe a le droit de se référer implicitement à une ressource, qui devient partagée, ce qui l'interdit d'être unilatéralement supprimée a posteriori. Et c'est aussi généralement imposé parce que cela déroute techniquement les logiciels de versioning eux-mêmes, qui y voient une divergence entre la branche locale et celle du dépôt, et qui essaient alors de la résoudre en tant que telle alors que cela n'en est pas une. Et pour les gens peu habitués à l'outil concerné, cela les conduit en général à percevoir leur dépôt comme corrompu, à l'effacer et à en retélécharger un au propre.

Je suis personnellement assez réservé sur cette règle. D'abord parce que Git permet de gérer ces cas de figure très facilement, ensuite parce que les règles exposées plus haut nous enjoignent justement à faire des commits les plus propres possible. Du coup, cela me fait recourir fréquemment à git commit --amend mais cela me conduit aussi à reconstruire régulièrement le sommet de ma branche, ce afin d'avoir une série de commits la plus propre possible pour qu'elle puisse passer à la postérité et ne plus avoir à changer.

Donc, une bonne méthode pour laisser de la latitude à ses développeurs est effectivement de recourir aux branches, et de n'agréger celles-ci qu'à intervalles réguliers, si possible avec l'accord des protagonistes (possible uniquement avec une petite équipe).

C'est ce qui se passe d'ailleurs peu ou prou avec la branche « linux-next », qui sert justement à ça. La branche « linux » officielle, celle de Linus Torvalds et qui contient les releases officielles du noyau, n'est jamais reconstruite. Elle doit donc être propre du premier coup. En revanche, non seulement c'est difficile en soi pour un programmeur isolé, mais le noyau Linux est constitué d'une multitude de sous-systèmes qui forment chacun un projet en soi, voire un sujet d'étude : la gestion fondamentale de la mémoire, par exemple (qui avait jadis donné naissance à la branche -mm) est très différente de la gestion globale du réseau, par exemple.

Ça veut dire que même une fois chaque sous-système mis au propre par rapport à une même version du noyau courant, et une fois toutes les étapes de déboguage menés à bien par les équipes de chaque projet, on n'est jamais à l'abri de gros effets de bords entres systèmes, provoqués par des changements apportés en dehors du périmètre sur lequel on a une visibilité. La branche « linux-next » est donc reconstruite régulièrement. Un tag, nommé d'après la date de l'opération, est ajouté au sommet de la branche pour conserver son état dans les archives du dépôt puis elle est ramenée au dernier état fonctionnel connu. Elle est ainsi reconstruite plusieurs fois jusqu'à ce qu'elle compile parfaitement. À ce stade, chaque mainteneur sélectionne prépare une branche « pour Linus » dans laquelle il sélectionne les commits à intégrer. L'intéressé peut alors facilement — et rapidement — passer en revue chacune de ces branches (le plus gros du travail étant censé être fait) et l'intégrer au noyau officiel.
10/01/2019, 18h48
shellwhale

Je vous remercie pour les conseils, en particulier Obsidian.
Vu que le branching GitFlow est bien documenté, je pense à adopter un branching similaire pour débuter.

Citation:

Envoyé par Obsidian

Même chose pour les fichiers de configurations : les changements d'URL, de mots de passe, de type de configuration pour un serveur, etc.

Cela m'amène à me poser une autre question. Est-ce que la base de donnée du site web devrait être versionnée elle aussi ? Comment permettre aux développeurs de travailler sur une base de donnée différente de celle de la release pour éviter les gaffes ? De la même manière, est-ce que si je dois empêcher certaines personnes d'accèder à la branche de release si je ne veux pas qu'ils puissent avoir de droits d'écriture ? En somme, si la base de donnée doit être versionnée, comment est-ce que cela se fait en pratique ?
10/01/2019, 21h03
Obsidian

Bonsoir,

Citation:

Envoyé par shellwhale

Cela m'amène à me poser une autre question. Est-ce que la base de donnée du site web devrait être versionnée elle aussi ?

En principe, la réponse est « non » parce que la base de données est changeante par nature. Les méta-données qu'elle contient sont modifiées en permanence par le serveur de base de données. Donc non seulement les changesets seraient en binaire et donc humainement illisibles, mais ils n'auraient aucune sémantique propre. Ce serait comme archiver sa mémoire swap, comme cela s'est vu sur certains canaux… :-)

Ensuite, il faut bien distinguer ce qui relève de la structure de ton logiciel, et ce qui tient de l'exploitation de ce logiciel : un client mail que tu utiliserais tel quel pendant des années ne changerait jamais de version, mais il cumulerait probablement des milliers de mails à terme. Il est évident que ces mails doivent être sauvegardés, mais pas avec le code source dudit client. Et si jamais tu le réinstalles, l'installation ne doit pas non plus aller mettre en place directement les mails accumulés pendant cette période. C'est au client courrier de les réimporter éventuellement, une fois proprement installé.

Par contre, la base doit bien sûr être sauvegardée régulièrement mais ce qui est surtout nécessaire, c'est de versionner avec le logiciel les fichiers de génération de la base. En général, il s'agit simplement d'un fichier SQL ordinaire qui contient tous les « CREATE TABLE » et la gestion des droits associée. Même chose si le logiciel a besoin d'un minimum de méta-données dans la base pour démarrer (ce qui est probable). Mais celles-ci prennent généralement place dans un fichier similaire, si ce n'est pas dans le même.

Si jusqu'ici, tu avais créé tes tables à la volée depuis le client SQL de ton SGBD ou via une interface web d'administration, alors il faudra procéder à un dump de ta base. Tous les SGBD ou presque proposent aujourd'hui un outil pour le faire. Et cet outil te permet en général demander le dump complet de la base, ou de te limiter au schéma (les tables sans leur contenu) ou aux données seules. Ils te permettent en outre, si nécessaire, de te cantonner à certaines tables si tu le souhaites.

Citation:

Comment permettre aux développeurs de travailler sur une base de donnée différente de celle de la release pour éviter les gaffes ? De la même manière, est-ce que si je dois empêcher certaines personnes d'accèder à la branche de release si je ne veux pas qu'ils puissent avoir de droits d'écriture ?

La première chose consiste bien sûr à utiliser des comptes en read-only. Il est possible de créer des utilisateurs aux droits différents avec tous les SGBD.

Si toutefois, le logiciel en développement a besoin d'un accès complet à la base pour fonctionner, alors il faut utiliser une base de test. Et pour que cela fonctionne en conditions réelles, il faut faire de la réplication. Cela consiste formellement à synchroniser plusieurs bases entre elles selon des règles pré-établies à l'aide d'outils conçus pour ça. Mais attention, ce n'est pas trivial à utiliser. Comme les bases de données sont un métier à part entière dans l'informatique, tu auras de meilleures réponses sur le forum qui leur est consacré.

Par contre, si c'est ponctuel, et si c'est pour travailler en petite équipe, le plus simple consiste largement à faire un dump régulier de la base de production, de l'archiver normalement et de se servir du dernier dump en date pour reconstruire une base toute fraîche sur laquelle tu peux travailler. Quitte à la détruire juste après d'ailleurs.

Citation:

En somme, si la base de donnée doit être versionnée, comment est-ce que cela se fait en pratique ?

Comme dit plus haut, il y a une frontière nette entre le schéma d'une base et les données qu'elle contient.

Dans un premier temps, c'est l'un des premiers cas qui conduit en général à mettre une politique sur les numéros de versions. Par exemple, pas de changement du schéma de la base (tables, colonnes, nom, etc.) lors de mises à jour mineures. Si c'est nécessaire, ce sera mis dans la file d'attente pour la prochaine release « moyenne » ou majeure. En contrepartie, ça garantit la compatibilité et ça permet de développer sereinement sur les tâches immédiates.

Après, ça peut être un mal comme un bien : si les modifications à faire sont fréquentes et si, surtout, la base de données n'est pas le cœur de l'activité du logiciel mais simplement une ressource mise à sa disposition (par exemple Firefox qui utilise des fichiers SQLite), tu peux appliquer ta propre politique mais la création de ces bases à l'installation seront de la responsabilité du logiciel d'installation lui-même, et elles seront considérées comme des ressources internes. Si ton logiciel est fait pour exploiter l'existant (et/ou une ressource partagée), il faudra non seulement définir une politique claire à partir de laquelle la compatibilité ne sera plus assurée mais également développer des scripts de migration qui seront fournis avec ton soft.

Si ton logiciel peut le faire lui-même, c'est une bonne chose (genre : « voulez-vous réimporter tous les favoris et bookmarks d'Internet Explorer ») mais avec le temps, convertir les données d'une version arbitraire vers une autre devient un vrai travail, voire une gageure. Donc, en général, cela devient un sous-projet à part entière, qu'il ne faut pas négliger.

Enfin, retiens que tu n'es pas obligé de ne versionner que du code ou des ressources techniques : il est fortement recommandé de versionner en même temps que le logiciel (mais dans un répertoire dédié) la documentation associée, les manuels utilisateurs et les procédures de déploiement. Ainsi, tu es sûr de toujours avoir la bonne marche à suivre quand tu récupères une version arbitraire du logiciel.