Contrôle des sources: rôles et responsabilités - Meilleures pratiques

Je suis à la recherche de "meilleures pratiques" concernant les rôles et les responsabilités, en particulier qui est responsable des fusions des branches de développement vers le tronc (ou principal). Fondamentalement, je cherche des munitions pour aider ma cause.

Permettez-moi de décrire à quoi je fais face. Je suis le développeur principal (propriétaire) d'une application particulière. Notre entreprise est récemment passée de VSS (où j'étais l'administrateur de la base de données VSS dans laquelle mon application était stockée) à TFS (où je n'ai que des autorisations sur les branches de développement créées par notre équipe "opérations"). Dans les emplois précédents, j'étais administrateur TFS, donc je connais bien TFS et MSBuild.

Je n'ai pas de problème avec la stratégie de branchement et de fusion utilisée (branche principale, avec des branches de développement de bogues / projets créées au besoin, fusionnées de nouveau à main puis promues en branche de publication). Les problèmes que j'ai sont:

1. Je ne peux pas créer mes propres succursales. Je dois créer une tâche TFS pour qu'un membre de l'équipe «opérations» crée la branche pour moi.

2. Je ne peux pas fusionner de Main vers ma branche de développement. Je dois créer une tâche TFS pour qu'un membre de l'équipe «opérations» effectue la fusion, puis j'espère qu'il n'effectuera aucun changement dans mes équipes, car le «gars des opérations» peut ou non être un développeur et a certainement peu ou pas de connaissance du code qu'il fusionne.

3. Je ne peux pas fusionner du développement au Main. Encore une fois, je dois créer une tâche TFS pour que le "gars des opérations" effectue la fusion, en espérant qu'il le fasse correctement. Ensuite, je dois créer une autre tâche TFS pour la fusionner avec ma branche afin de pouvoir résoudre tous les problèmes qui se sont produits en faisant fusionner un non-développeur avec Main.

4. Je ne peux pas créer ou modifier des scripts MSBuild. Encore une fois, je dois travailler avec l'équipe "ops" qui est nouvelle dans MSBuild afin que seules les tâches de construction les plus élémentaires puissent être effectuées. (Oubliez tout ce qui est complexe, ou interdisez une tâche personnalisée).

5. Je ne peux pas exécuter de script MSBuild. Encore une fois, seule l'équipe "ops" peut le faire.

6. Pour couronner le tout, il s'agit généralement d'une ressource "off-shore" qui exécute les tâches demandées, donc même si je crée la tâche vers (branche / fusion / build) tôt le matin, elle ne sera probablement pas terminée jusqu'à ce soir.

Maintenant, je n'ai plus de problème avec l'équipe "opérations" qui gère les branches de publication. Comme tout ce qu'ils font, c'est (essentiellement) prendre la dernière version de Main et la promouvoir dans la branche de publication; aussi longtemps que "Main" est stable et prêt, la branche de publication sera bonne.

Mon opinion est que les responsables techniques (comme I) devraient être responsables de la maintenance du tronc ("Main") et de toute fusion vers / depuis les branches de développement. Le chef d'équipe doit également avoir la capacité de générer des scripts MS Build à construire et à déployer dans l'environnement de test d'intégration.

Quelqu'un peut-il me diriger vers un document sur les meilleures pratiques qui m'aidera à prouver mon cas? Toutes mes recherches n'ont révélé que les meilleures pratiques concernant les techniques de ramification et de fusion, et aucune mention de l'OMS ne devrait effectuer cette ramification / fusion.

Mon point de vue général sur les meilleures pratiques est que tout membre de l'équipe de développement devrait être en mesure d'effectuer n'importe quelle action sur l'arborescence en supposant que ces actions ne font pas des choses comme lancer un déploiement de production. Dans les cas où une branche / balise / référentiel spécifique agit comme une source de déploiements automatisés, il est logique de mettre en place un contrôle des modifications raisonnable ou des barrières à l'entrée, plus du point de vue des erreurs de conservation que des erreurs de contrôle plutôt que de l'angle de contrôle. J'encourage les développeurs à créer des branches et à améliorer les scripts de construction. Je trouverais des moyens d'obtenir l'accès des développeurs à la production si nécessaire. Une partie du point de contrôle des sources est qu'il s'agit d'une gomme magique efficace d'erreurs - le pire que vous devrez faire est de faire reculer un ou deux tours et de le dériver.

Malheureusement, cela ne ressemble pas à l'approche qu'ils ont adoptée ici. Pour vaincre cela, je pense que vous devez couvrir quelques angles:

a) Prouver que ces politiques sont préjudiciables au développement des choses. Enregistrez tout le temps que vous passez à attendre des opérations pour commencer à travailler sur quelque chose. Cela seul devrait vendre une gestion raisonnable des raisons pour lesquelles il s'agit d'une mauvaise politique.

b) Faites-vous des amis à Ops - il y a peut-être une raison à cette politique. Peut-être que ce raisonnement pourrait être traité de manière plus efficace.

J'espère que cela t'aides.

Les pratiques que j'ai vues sont:

1. N'importe qui peut créer des branches de travail à sa guise. Un développeur doit être capable de créer une branche de fonctionnalité dans la seconde où il trouve qu'il est utile de stocker son travail en cours. Parce qu'ils veulent / devraient le sauvegarder à la fin de la journée, veulent le partager avec un autre membre de l'équipe, doivent être protégés des changements dans le principal ou autre.

2. Tout le monde peut absolument tout faire pour les branches de développement. Le développeur doit pouvoir fusionner à partir de main à la minute où un autre développeur lui dit que quelque chose dont il a besoin a été intégré à main.

3. Pour fusionner vers main (intégration), il existe trois options:

   • Les développeurs le font eux-mêmes. Ils discutent simplement des risques avec le développeur principal et testent les fonctionnalités de manière appropriée. Cela implique que n'importe qui a les autorisations; si quelqu'un enfreint les règles, il est simplement grondé et le mauvais changement est annulé.
   • Un autre développeur le fait après avoir examiné les modifications. Cela nécessite toujours que tout le monde soit autorisé à le faire; les règles sont toujours appliquées par le développeur principal.
   • Il y a un intégrateur désigné qui passe en revue et fusionne en main. Mais l'intégrateur fait partie de l'équipe et doit comprendre le code. Sur une petite équipe, ce serait la même personne que l'architecte, sur une plus grande, ils seraient séparés, mais devraient coopérer étroitement.

4. Celui qui prépare une fonctionnalité doit adapter le script de construction. Mais je ne sais pas comment cela fonctionne avec TFS; dans les systèmes que j'utilisais, le script de construction était toujours juste un fichier versionné, donc les développeurs l'ont édité comme n'importe quel autre et il a été intégré avec tout le reste.

5. S'il y a un intégrateur désigné, ils s'occupent généralement de définir (quel script exécuter) et de démarrer les builds. Sinon, le chef d'équipe le fait, le membre désigné de l'équipe le fait ou n'importe qui a des autorisations et le chef d'équipe délègue la configuration et le démarrage de builds particuliers au cas par cas.

6. Les opérations ci-dessus ne doivent en aucun cas nécessiter un opérateur extérieur à l'équipe. L'opérateur n'est nécessaire que pour configurer les autorisations, créer des répliques, etc.

Peu importe les «meilleures pratiques» (soyez indulgents), c'est un problème de gestion - fondamentalement, vous n'êtes pas en mesure de faire votre travail correctement en raison des contraintes qui vous sont imposées.

Peu importe en fait ce que sont les "meilleures pratiques" - il s'agit d'un problème simple et démontrable qui affectera la productivité de vous et de votre équipe et vous devez vous en tenir à votre gestion hiérarchique sur cette base.

Je peux voir que le fait de brandir un document sur les meilleures pratiques pourrait (mais seulement pourrait ) être une aide pour tenter de les persuader, mais bien mieux est la notion que vous devrez avoir des membres de l'équipe de développement assis sur leurs mains en attendant quelqu'un dans un fuseau horaire différent de se ressaisir à moins que les processus ne soient améliorés / rationalisés.

Et ne soyez pas trop conflictuel - autant que tout ce que vous voulez savoir pourquoi les restrictions sont en place, quelle est la justification ...