Comment configurer le contrôle de source avec plusieurs produits, tous dépendants d'une même bibliothèque de classes

Question

Je suis le directeur technique et le développeur exclusif de mon entreprise. Je me prépare à embaucher notre premier développeur et éventuellement un second dans les 6 à 12 prochains mois. Je suis gêné de dire que je n'ai jamais utilisé le contrôle de code source dans le cadre de mon flux de travail. Je suppose que le fait d'être une équipe de développement composée d'un seul membre m'a permis d'être un peu paresseux. Ce n’est pas que je n’ai pas voulu, j’ai un petit blocage mental sur la façon de commencer.

Nous avons créé et mis à jour cinq applications Web. Nous utilisons ASP.NET et chaque application Web fait référence à une seule bibliothèque .NET de classes (DLL) copiée dans le répertoire "bin". dossier pour chaque application. J'ai développé avec une seule solution Visual Studio. qui comprend la bibliothèque de classe et toutes les applications Web. Je suis sûr que c'est un peu exagéré, mais cette méthode m'a permis de minimiser les erreurs en me permettant d'effectuer des opérations globales de recherche et de remplacement sur toutes mes applications (et la bibliothèque de classes) en même temps.

Je me rends compte que la mise en œuvre du contrôle de code source est un grand changement pour mon flux de travail, mais l'introduction d'un autre développeur dans mon processus m'a un peu dépassée. Je cherche de l'aide sur la manière de développer un flux de travail qui permettra à ma petite équipe de se déplacer rapidement sans processus fastidieux. Je voudrais éviter les discussions sur le choix du système SCC (nous allons utiliser Mercurial). Je suis plus intéressé par la discussion sur les aspects de la structure et du flux de travail.

Voici les questions pour lesquelles j'ai besoin d'aide:

1. Dois-je diviser chaque application en un "projet" distinct ou gardez-les tous ensemble pour que nous puissions continuer à tirer parti des opérations mondiales de recherche et de remplacement, si nécessaire. Je crains de les séparer à cause de la situation de la bibliothèque de classe (voir n ° 2).

2. Si vous divisez les applications en projets distincts, je ne sais pas comment procéder avec la bibliothèque de classes dont chaque projet a besoin d'une copie. Par exemple, supposons que les modifications apportées à l'une des applications (appelez-le "projet 1") nécessitent une modification de la bibliothèque de classes ... si la bibliothèque de classes se trouve dans un projet séparé (appelez-la "projet 2"). , il semble "malpropre" Pour moi, le projet 1 dépendrait des dernières modifications apportées au projet 2 pour fonctionner correctement. Ou bien, apportez-vous simplement les modifications au projet 2 (la bibliothèque de classes), archivez-les, puis copiez la dll nouvellement compilée dans le projet 1 (mais la nouvelle copie de la dll en cours de copie dans le projet 1 ne doit-elle pas être enregistrée dans le SCC en quelque sorte). Je suis confus au moment même où j'écris ceci ...

Merci d'avance pour votre aide.

Answer 1

Tout d’abord, félicitations pour votre décision d’utiliser enfin le contrôle de source. Je sais que changer vos habitudes peut être frustrant, mais à long terme, je suis sûr que vous en verrez les avantages.

1. Il n'y a rien de mal à une solution comportant plusieurs projets. Je garde généralement le mien à environ 10 mais c'est simplement pour améliorer les temps de chargement. Si les garder ensemble vous convient mieux, laissez-le ainsi. L’utilisation du contrôle de source n’aura aucun effet à cet égard.
2. En ce qui concerne la bibliothèque de classe, je pense que ce que vous devez faire est de changer la façon dont vous procédez pour modifier le projet de bibliothèque plutôt que la façon dont vous utilisez les projets qui le référencent. Implémentez des tests unitaires sur le projet de bibliothèque pour appliquer la compatibilité ascendante afin que vous sachiez que le fait de supprimer la dernière version de la bibliothèque ne détériorera pas votre application. Vous constaterez probablement que ce ne sera pas le cas quelques fois, mais si vous développez davantage de tests unitaires pour traiter les cas extrêmes, cela se produira de moins en moins.

Answer 2

Vous pouvez avoir plusieurs projets dans une même solution Visual Studio. Ce que j'ai fait par le passé, c'est d'avoir à la fois le projet ASP.NET et le projet de bibliothèque de classes dans la même solution. Vous pouvez faire en sorte que votre projet ASP.NET fasse référence au projet de bibliothèque de classes (Ajouter une référence, puis accédez à l'onglet Projets pour afficher d'autres projets dans la même solution). Ainsi, chaque fois que vous modifiez la bibliothèque de classes, l'application ASP.NET sera générée à l'aide de la dernière version de la bibliothèque de classes. Vous pouvez configurer plusieurs solutions - une pour chaque application ASP.NET avec chaque solution, y compris le projet libary de classe.

Vous pouvez également configurer une solution volumineuse avec tous vos projets ASP.NET ainsi que votre bibliothèque de classes, mais cela peut devenir un peu difficile à utiliser, en particulier avec plusieurs développeurs travaillant sur les différentes pages ASP.NET.