Comment structurer un VCS avec plusieurs projets dépendants

Question

Je suis sûr que c'est un problème commun que d'autres ont résolu auparavant, alors je fais appel à la sagesse collective d'autres développeurs/chefs de projet pour de l'aide.

J'ai un certain nombre de projets:

• application
• WebApp
• ServerApp
• Dev Utils
• ORM

Toutes les applications/utils dépendent sur l'ORM: lorsque l'ORM change, il doit être compilé et toutes les applications besoin d'être recompilé contre elle puis déployé. En ce moment, ma structure de VCS est une sorte de pêle-mêle:

• AppName
  • Tronc
    • application
    • WebApp
    • ServerApp
    • Dev Utils (environ 4 dossiers en ce moment, mais en croissance)
    • ORM
  • Relase
    • ProjetName (que ce soit l'application ou application Web) version.number
  • Branches
    • ExperimentName_DevName

Idéalement, j'aimerais avoir un dossier racine par application (Application/WebApp/ORM etc.), chacun avec ses propres Trunk/Branches/Releases etc. pour les séparer logiquement et physiquement. Mon raisonnement est que parce que beaucoup de travail est fait sur l'Application, et qu'il est libéré beaucoup plus souvent, chaque branche de publication a des copies identiques des mêmes utils etc. Vérifier également le Tronc pour travailler dessus signifie toujours que tous les autres les projets viennent pour le tour. Séparer reviendrait à arracher certains projets à des solutions et à modifier simultanément tout projet en faisant un saut de douleur entre 2 et 3 IDE (surtout en cas de modification de l'ORM).

Je pense à cela parce que très bientôt je vais mettre en place une machine CI (être prêt pour des questions à ce sujet dans une semaine ou deux) et j'essaie de trouver un moyen de faire les versions automatiquement créé/déployé. Normalement, seule l'application est déployée, via une copie de script sur le serveur où toutes les stations de travail tirent au démarrage, mais comme je l'ai déjà dit, si l'ORM change/libère, toutes les autres applications devraient être reconstruites et déployées.

(Aujourd'hui, je me suis cassé notre site Web et 3 services parce que je changé le ORM et déployé avec une version mise à jour de l'application, mais il a oublié de reconstruire/déployer les autres applications avec le nouveau ORM -. Oups)

Answer 1

Diviser votre base de code en différents "projets" peut être très difficile. Nous l'avons fait à chaque limite «déployable» séparément. Y compris une couche "plate-forme" commune/utilisée par les autres, en tant que projet séparé. Mais ce n'est pas vraiment parfait non plus. La seule chose que je ne peux pas souligner assez est qu'il faut avoir une forme de régression/test continu qui court après les vérifications et avant que vous ne déployiez quoi que ce soit. En outre, un processus de «libération» qui pourrait même impliquer certains tests manuels peut être utile et a définitivement empêché quelques œufs sur les situations de face. (Il vaut mieux relâcher quelques jours tard puis cassé.)

(Désolé de ne pas répondre directement à votre problème)

Answer 2

Mettez-vous dans la peau de votre développeur. Cela ne devrait pas être difficile car il semble que vous soyez l'un d'entre eux :-) Regardez votre mise en page de contrôle de version non pas d'un point de vue architectural, mais d'un point de vue de la convivialité. Demandez-vous: au jour le jour, quelles sont les choses les plus communes que nous faisons en tant que développeurs avec notre code source? Pensez spécifiquement en ce qui concerne vos interactions avec votre système VCS et les dispositions du projet. Vous voulez rendre les choses communes faciles d'esprit. Il est normal que les cas d'utilisation les plus courants soient plus difficiles à obtenir, à condition que vous ayez une trace de la façon de les faire, de sorte que lorsque les gens oublient, ils sauront où chercher pour se rappeler comment . J'ai vu beaucoup de mises en page VCS qui essayaient d'être «parfaites» sur le plan architectural, mais qui finissaient sans problème par des tracas et des maux de tête d'un point de vue de l'utilisation quotidienne. Je ne dis pas que les deux ne peuvent pas coïncider et maille bien ensemble, je dis juste de le penser du point de vue des utilisateurs, et que ce soit votre guide. Du point de vue d'un CI, je suivrais toujours cette approche. Même si votre configuration devient de plus en plus complexe à définir dans votre CI de votre choix, vous ne devez y effectuer la configuration qu'une seule fois. Si la mise en page est facile à utiliser pendant le développement, la plupart de votre configuration de CI devrait également être relativement facile. Vous vous concentrez ensuite sur les derniers bits qui prendront plus de temps.