Méthodologies de développement lorsque des centaines de développeurs travaillent sur une seule solution?

Nous sommes une organisation composée d'environ 200 développeurs qui travaillent en continu sur un seul produit (en utilisant le contrôle de révision Git) qui devrait sortir à une certaine date.

En raison du grand nombre de développeurs, nous essayons de créer des équipes «interfonctionnelles» avec environ 10 développeurs dans chaque équipe, ce qui donne environ 20 équipes de développement dans l'organisation.

Étant donné que nous souhaitons maintenir un "standard élevé" continu (c'est-à-dire lorsque le développeur effectue un pull, le produit doit au moins être compilable, etc.) du produit dans le référentiel principal, nous aimerions utiliser une sorte de portes de qualité.

Je ne sais pas trop comment formuler la question, mais je me demande si je pourrais obtenir des conseils sur les méthodologies de développement pour un si grand groupe de développeurs travaillant sur un seul produit.

À notre avis, une extrémité du spectre consiste à permettre à chaque développeur de s’engager directement dans le référentiel principal, mais nous craignons qu’en raison du nombre élevé de développeurs / commits, le «référentiel principal» puisse être constamment en rupture, en raison nous ne pouvons pas avoir une «porte de qualité» exigeante pour chaque commit.

L'autre extrémité du spectre pourrait être (nous pensons que Linus Torvalds / Linux le fait) un arbre ou une structure pyramidale, où le "référentiel principal" n'a que trois sources d'extraction, ces trois n'ont qu'une poignée de sources d'extraction de confiance, etc. Cependant, nous pensons qu'avec une structure comme celle-ci, les changements ont une longue chaîne à gravir pour entrer dans le "référentiel principal". De plus, si un conflit de fusion se produit, le problème se pose sur un autre développeur que le "développeur d'origine".

Avec toutes ces informations et opinions exprimées, comment pouvons-nous apprendre et lire les méthodologies de développement recommandées pour tant de développeurs? Comment les grandes organisations (Microsoft, Facebook, Ubuntu, etc.?) Structurent leur développement?

Vous devriez certainement envisager de diviser le produit en modules avec des équipes d'interface réunissant ces modules constitutifs en un produit. À son tour, cela signifierait la division des référentiels pour correspondre au partitionnement et à la hiérarchie des modules. S'il apparaît que vous ne pouvez pas le faire, le projet s'arrêtera probablement par fusion, compte tenu du nombre de développeurs contribuant.

Si vous prévoyez d'utiliser Git pour le contrôle de version, je recommanderais d' utiliser un système de révision de code (comme Gerrit ) pour améliorer la transparence et garantir la qualité de chaque référentiel. De cette façon, tout travail devrait être approuvé avant d'être fusionné dans un référentiel faisant autorité. Dans ce scénario, il est logique d'accorder à certaines personnes de confiance des autorisations pour passer d'un référentiel sous un système de révision de code à un autre référentiel (également éventuellement sous un système de révision de code). S'il est utilisé correctement, ce devrait être un processus rapide et très bénéfique qui n'entrave pas le processus de développement.

En ce qui concerne la vérification de la construction, vous auriez besoin d'un serveur d'intégration continue (CI) dont le but est de générer et de vérifier automatiquement le code. Par vérifier le code, je veux dire que le code se compile avec succès et que les tests réussissent. Infact Jenkins (CI Server) peut être lié au système de révision de code Gerrit dans le cadre de l' étape de vérification Gerrit , automatisant entièrement le processus.

En plus de ces outils d'intégration, il est important de rechercher une intégration fréquente dans le cadre de la méthodologie de développement, afin de minimiser la fusion temporelle.

Il peut être utile d' envisager un processus de développement Agile comme Scrum dont le but est de décomposer un produit complexe en morceaux gérables d'incrément de produit (appelés Sprints). Celles-ci fourniraient des opportunités d'intégration entre les référentiels.

De toute évidence, avec une équipe de développement de 200 personnes, vous devez avoir une sorte de structure hiérarchique. Un individu ou un petit groupe de personnes prend des décisions concernant la conception du produit logiciel. Votre processus de développement doit refléter cela: vous avez besoin de révisions de code et de tests pour vous assurer que le logiciel en cours de création correspond réellement à ce que vous vouliez créer (ainsi qu'à des fins de qualité).

Même les petites équipes ont besoin de leaders pour guider les équipes et revoir leur travail lors du développement de composants individuels. Leurs processus de contrôle de la qualité devraient également être en place au niveau de l'équipe.

Donc, oui, vous devez suivre une structure hiérarchique en ce qui concerne le référentiel. Cela correspond à la structure hiérarchique du projet dans son ensemble.

Les composants individuels doivent être construits et testés à un certain niveau d'adéquation avant même de penser à les assembler tous. Permettre à 200 personnes de s'engager directement dans le projet principal serait le chaos. Vous devez avoir des zones distinctes pour chaque groupe où les individus peuvent valider leurs modifications au jour le jour, sans affecter la construction principale du projet.

C'est une très bonne chose si "les changements ont une longue chaîne à gravir pour entrer dans le référentiel principal" car cette chaîne permet d'assurer la qualité. Cela peut sembler plus rapide si toutes les modifications s'appliquent immédiatement au référentiel principal, mais en fait, ce ne sera qu'un énorme casse-tête, car vous aurez une version principale constamment boguée et inutilisable de votre logiciel.

C'est également une bonne chose que «si un conflit de fusion se produit, le problème se pose sur un autre développeur» - en particulier, c'est un développeur de niveau supérieur qui doit décider comment résoudre un conflit.

Lorsque vous avez quelque chose de gros et (par conséquent) ingérable, la solution consiste à le diviser en morceaux plus petits et plus faciles à gérer.

Il y a plusieurs étapes qui vous aideraient à mieux maintenir l'équipe et le projet:

1. diviser la fonctionnalité en modules. La fonctionnalité doit être divisée en modules indépendants maximum utilisant les principes de cohésion élevée, de faible couplage et d'inversion de dépendance. Le premier principe vous aidera à créer des modules logiquement cohérents. Le second aidera à garder ces modules aussi indépendants que possible. Le troisième aidera à développer simultanément des modules dépendants (si le module A dépend du module B, B devrait fournir une interface que A peut utiliser même lorsque B n'est pas complètement prêt).

2. avoir une documentation claire. Quand il y a tellement de gens qui travaillent ensemble, les choses peuvent facilement être oubliées ou mal comprises. Vous devez donc porter une attention particulière à toute la documentation, des exigences aux solutions architecturales.

3. les gens pour les tâches (jamais les tâches pour les gens). Après avoir divisé la fonctionnalité en ensembles plus petits, créez des équipes pour travailler sur ces ensembles. La création d'équipes sera plus facile à ce stade, car vous savez déjà sur quoi chaque équipe doit travailler. Et des tâches telles que les révisions de code seraient effectuées au sein de chaque équipe.

4. système clair de tâches. Chacun des 200 développeurs doit clairement savoir sur quoi travailler. Cela vous aidera à garder une trace de ce qui est déjà fait, sur quoi chaque personne travaille et combien de travail il reste.

5. contrôle de source. (Je pense que cela est assez bien décrit dans d'autres réponses)))

Et enfin, essayez de créer une structure d'équipes et de modules aussi simple que possible. Vous ne pouvez pas vous permettre la complexité d'un projet aussi énorme.

En plus des autres réponses suggérant une structure hiérarchique: cela implique que vous devrez planifier des points `` d'intégration '' dans le temps où l'accent est entièrement mis sur le déplacement du code dans la hiérarchie et sur `` le rassemblement ''. Ce n'est pas très différent des petits projets avec une phase finale où aucun autre travail n'est fait que le test et la correction de bugs, mais plus fréquemment. Puisque vous travaillez dans un grand groupe en quête de normes élevées, la plupart de ces éléments (état d'esprit) seront probablement déjà en place.

En plus de la réponse de hotpotato (qui est directement sur la marque IMHO), je suggérerais également de mettre en œuvre des portes de contrôle de source, comme vous le suggérez. Lorsque nous avons déplacé une grande équipe et une base de code vers git pour SCM, nous avons décidé d'utiliser ce que l'on appelle la méthode du «dictateur bienveillant», similaire au modèle que vous avez décrit.

Dans ce scénario, il existe de nombreuses branches différentes de la base de code complète qui sont régulièrement mises à jour à partir de leur branche source, mais la responsabilité de promouvoir le code dans des zones plus visibles / publiques incombe à une seule personne (ou à un petit groupe de personnes), et est généralement lié à un processus de révision du code. Avec une structure de branchement bien organisée, cela peut très bien fonctionner. Pour plus d'informations, consultez ce lien .

J'ai travaillé sur un énorme système sur lequel plusieurs centaines de développeurs travaillaient simultanément avec environ 150 millions de SLOC. C'était sur un mainframe, donc nous ne parlons pas de Visual Studio, mais les principes peuvent toujours être adoptés.

Tout d'abord, si vous utilisez Java, je dirais certainement utiliser Maven. Si vous utilisez VS, vous pouvez également utiliser Nuget, même si je ne suis pas sûr de savoir s'il existe déjà avec Maven (il est également quelque peu différent). L'utilisation d'un tel système vous permettra de tirer vos dépendances et de leur permettre de fonctionner individuellement. Vous auriez un script de génération extraire les dépendances pertinentes et créer en tant que lot.

Étant donné que vous ne posez pas directement une question mais que vous demandez une méthodologie, je vais vous dire comment mon ancien employeur l'a traitée.

Le système a été divisé en grappes . Les grappes représentaient des secteurs d'activité et des infrastructures de système. Je ne vais pas les nommer, mais pour une énorme entreprise de vente au détail, vous pourriez penser à des choses telles que le marketing, les opérations de vente au détail, les opérations en ligne, l'approvisionnement, la distribution. L'infrastructure système représentait des éléments tels que les clients et la sécurité. Au sein de chaque cluster, il y avait des composants . En utilisant l'analogie précédente, vous pouvez considérer des composants de sécurité par exemple - connexion unique, services d'annuaire, audit, rapports, etc. Chaque composant avait ses routines relatives stockées en son sein.

En tant qu'espace de noms ou package, vous auriez par exemple Organisation.Security.DirectoryServices. En contenant toute la logique de ses domaines pertinents, les équipes ont travaillé de manière assez autonome. De toute évidence, de grands projets nécessitant la contribution de plusieurs équipes se sont produits, mais il s'agissait en grande partie d'opérations fluides.

J'espère que ça aide.