stratégie de sortie du projet / code

Question

Contexte: Je travaille dans une petite entreprise de logiciel qui a toujours fait un travail de type de recherche, et 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 de structure en termes de maintien de versions appropriées des projets.

Problème: Le manque de structure se révèle maintenant être un peu un obstacle, comme chaque développeur a une vue légèrement différente de la base de code. Un problème un développeur découvre n'est pas reproductible par un autre développeur, et les 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 frustrant pour quelqu'un qui est responsable de l'intégration de tous les projets et d'assurer des normes de qualité et de performance sont remplies - à savoir moi-même.

Solution possible: Personnellement, je suis convaincu que nous devons mieux faire respecter la structure via les numéros de version fixe et mises à jour régulières. Il devrait être évident comment versioning approprié aiderait à beaucoup de nos problèmes, mais bien sûr, ce ne sont pas sans problèmes - les développeurs ont besoin de faire un travail supplémentaire pour effectuer et des versions de test, et ne sera plus en mesure d'utiliser les dernières versions de tout.

Question: Pour venir à un point - quelles sortes de stratégies recommandez-vous pour assurer le processus et les efforts nécessaires pour les versions se produit aussi bien que possible? Nous utilisons git pour le contrôle de version, maven pour notre système de construction, et nous avons suivi des bogues et des systèmes d'intégration continue en cours d'exécution, donc je crois que les outils sont là. Je suis tout simplement pas sûr de ce qui devrait ressembler à un processus de libération approprié.

Answer 1

Vous avez les trois grands en place: le contrôle de version, un seul clic via Maven et construire votre serveur de build continue, et suivi des bogues. On dirait que vous les gars sont graviter vers des méthodologies Agile, et donc vous devriez essayer de garder la version du tronc de votre produit dans un état livrable près à tout moment.

Lorsque vous décidez de faire votre première version, créez une branche hors de votre version de coffre pour cette version. Décider d'un système d'étiquetage et assurez-vous d'étiqueter la version de la branche. Par exemple, votre première version pourrait être 1.0.4530, où 1 signifie la première version, le 0 signifie qu'il est le premier candidat de libération, et le 4530 est le numéro de changement de contrôle de version. Vous testez cette branche de libération et de corriger des bugs importants là-dessus. Après un certain temps vous émettez un autre candidat de libération, dire 1.1.4807. Ce processus itère deux fois plus (par exemple), votre communiqué est assez bon, et vous expédier la version 1.3.5167.

Pendant ce temps, votre nouveau développement ne se produit que dans la version du tronc, et de temps en temps, vous aurez besoin de fusionner des corrections de bugs de la branche de sortie 1.x dans le tronc. Par la suite, vous divisez une branche 2.x du tronc de répéter le processus pour votre deuxième version. Vous aurez généralement plusieurs branches actives (plus le tronc), avec le développement limité au tronc et chaque branche indépendante vierge et gardé du développement.

Vous les gars vous obtiendrez le coup des choses et vos problèmes de coordination de développement deviendront moins fréquentes. Mais ces problèmes sont presque tous vont se limiter au tronc, les branches de libération.

Answer 2

  

Un problème on découvre des développeurs est   pas reproductibles par un autre développeur,   et les problèmes trouvés dans une construction peut   disparaître dans l'autre (ou pire, nouveau   des problèmes peuvent apparaître). Cela fait un   expérience très frustrant pour   quelqu'un qui est responsable de la   l'intégration de tous les projets et   d'assurer la qualité et la performance   les normes sont respectées -. à savoir moi-même

     

Solution possible: Personnellement, je suis   convaincu que nous devons mieux faire respecter   la structure par l'intermédiaire de numéros de versions fixes   et mises à jour régulières.

Je ne pense pas que vous devez avoir les versions très fréquentes juste pour coordonner en interne. Vous pouvez le faire grâce au contrôle de version. Il suffit de faire parler de révisions git spécifiques en cas de problèmes de rapports. Notez également que vous devrez coordonner toutes les dépendances / bibliothèques externes aussi. Une sorte de branches pourrait aider à ce .

Answer 3

Il sonne comme les développeurs ont besoin d'utiliser des « branches d'essai » et respecter la « branche stable / production » un peu plus.

Vendre dans le concept de « faire vos affaires de l'ouest sauvage dans cette branche », et quand vous êtes satisfait des résultats, alors vous fusionner dans cette « branche de production stable ennuyeux » .... (Ou quelque chose comme ça)

Answer 4

Il y a des livres écrits sur le thème général; recherche Amazon retourne encore trois titres pour spécialisés « contrôle de version avec git. »

Je pense que vous bénéficierez de définir une vue canonique de la base de code. Appelez-test. Un problème est un problème si elle apparaît dans l'essai. Si un problème ne figure pas dans la vue de certains développeurs, il est jusqu'à ce développeur pour savoir quelle est la différence importante; et de même pour un problème qui apparaît dans la vue du développeur, mais pas dans le test.

Une convention est pour le test à nouveau construit à partir de sources sur une base quotidienne. Une convention plus intense est pour le test à nouveau construit sur chaque mise à jour. Si votre équipe est petite (cinq ou moins) et non dispersés sur de grandes distances ou plusieurs fuseaux horaires, une première approximation raisonnable est de faire de test un espace de travail git sur un serveur sur lequel votre toolchain a été installé avec certains emplois cron de sorte que cet espace de travail est mis à jour et reconstruit tous les soirs (en général).