Stratégie de lancement de projet/code

Question

Contexte: Je travaille dans une petite entreprise de logiciels qui a traditionnellement fait du travail de recherche et qui n'a pas beaucoup d'expérience dans l'espace commercial. Nous essayons maintenant de pousser dans le monde commercial. En raison de nos origines dans la recherche, nous sommes habitués à un cycle de développement très rapide et très peu structuré en termes de maintenance des versions correctes des projets. Problème: Le manque de structure s'avère maintenant être un peu gênant, car chaque développeur a une vue légèrement différente de la base de code. Un problème qu'un développeur découvre n'est pas reproductible par un autre développeur, et les problèmes rencontrés dans un build peuvent disparaître dans le suivant (ou pire, de nouveaux problèmes peuvent apparaître). Cela crée une expérience très frustrante pour quelqu'un qui est responsable de l'intégration de tous les projets et de s'assurer que les normes de qualité et de performance sont respectées - c'est-à-dire moi-même.

Solution potentielle: Personnellement, je suis convaincu que nous devons appliquer une meilleure structure via des numéros de version fixes et des versions régulières. Il devrait être évident que le bon versioning aiderait à résoudre beaucoup de nos problèmes, mais bien sûr cela ne va pas sans poser de problèmes - les développeurs doivent faire un travail supplémentaire pour effectuer et tester les versions, et ne pourront plus utiliser les dernières versions de tout. Question: Pour arriver à un point - quelles sortes de stratégies recommandez-vous pour garantir que le processus et l'effort requis pour les rejets se déroulent aussi facilement que possible? Nous utilisons git pour le contrôle de version, maven pour notre système de construction, et nous avons des systèmes de suivi de bogues et d'intégration continue, donc je crois que les outils sont là. Je ne suis tout simplement pas sûr de ce à quoi devrait ressembler un bon processus de libération.

Answer 1

Vous avez les trois grands en place: contrôle de version, construction en un clic via Maven et votre serveur de build continu, et suivi des bogues. Il semble que vous soyez attirés par les méthodologies Agile, et vous devriez donc essayer de garder la version trunk de votre produit dans un état presque livrable à tout moment. Lorsque vous décidez de créer votre première version, créez une branche de votre version de ligne pour cette version. Décidez d'un système d'étiquetage et assurez-vous d'étiqueter la version de la succursale. Par exemple, votre première version peut être 1.0.4530, où 1 signifie la première version, 0 signifie que c'est la première version et 4530 le numéro de version du contrôle de version. Vous testez cette branche de publication et corrigez des bogues importants. Après un certain temps, vous émettez un autre candidat, par exemple 1.1.4807. Ce processus répète quelques fois (disons), votre version devient assez bonne, et vous expédiez la version 1.3.5167. Pendant ce temps, votre nouveau développement se produit uniquement dans la version du tronc, et de temps en temps, vous devrez fusionner les corrections de bogues de la branche de publication 1.x vers le tronc. Plus tard, vous allez séparer une branche 2.x du tronc pour répéter le processus de votre seconde version. Vous aurez généralement plusieurs branches actives (plus le tronc), avec un développement limité au tronc et chaque branche gardée vierge et indépendante du développement.

Les gars vont prendre le coup de tout et vos problèmes de coordination des développeurs deviendront moins fréquents. Mais ces problèmes vont presque tous se limiter au tronc, pas aux branches de lancement.

Answer 2

Un problème un développeur découvre est pas reproductible par un autre développeur, et problèmes rencontrés dans une construction peut disparaître dans l'autre (ou pire, de nouveaux problèmes peuvent apparaître). Cela fait une expérience très frustrante pour quelqu'un qui est responsable de intégrant tous les projets et assurant la qualité et la performance normes sont respectées - c'est-à-dire moi-même.

solution potentielle: Personnellement, je suis convaincu que nous besoin d'appliquer une meilleure structure de via les numéros de version fixes et mises à jour régulières.

Je ne pense pas que vous ayez besoin d'avoir des versions très fréquentes juste pour coordonner en interne. Vous pouvez le faire grâce au contrôle de version. Demandez aux gens de parler de révisions git spécifiques lorsqu'ils rapportent des problèmes. Notez également que vous devrez également coordonner toutes les dépendances/bibliothèques externes. Une sorte de vendor branches pourrait aider avec ceci.

Answer 3

Il y a des livres écrits sur le sujet général; La recherche Amazon renvoie même trois titres pour le "contrôle de version spécialisé avec git".

Je pense que vous bénéficierez de la définition d'une vue canonique de la base de code. Appelez le test. Un problème est un problème s'il apparaît dans Test. Si un problème n'apparaît pas dans la vue d'un développeur, il appartient à ce développeur de déterminer quelle est la différence importante; et de même pour un problème qui apparaît dans la vue d'un développeur, mais pas dans Test.

Une convention prévoit que le test soit reconstruit à partir des sources chaque nuit. Une convention plus exigeante est que Test soit reconstruit à chaque mise à jour.Si votre équipe est petite (cinq ou moins) et n'est pas dispersée sur de grandes distances ou plusieurs fuseaux horaires, une première approximation raisonnable est de faire un espace de travail Test sur un serveur sur lequel votre chaîne d'outils a été installée avec quelques tâches cron afin que cet espace de travail est mis à jour et reconstruit chaque nuit (habituellement).

Answer 4

Il semble que les développeurs doivent utiliser des "branches de test" et respecter un peu plus la "branche stable/de production". Vendez dans le concept de «faites vos affaires de Far West dans cette branche», et quand vous êtes heureux avec les résultats alors vous le fusionnez dans cette «branche ennuyeuse de production stable» .... (ou quelque chose comme ça