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

10

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.

Michael Chatfield
la source
WHO should be performing said branching/merging.est une décision organisationnelle interne. Pas vraiment quelque chose que nous pourrions vous aider ...
yannis
2
Voulez-vous nous dire les raisons putatives données pour une telle procédure byzantine? Ma conjecture est "conformité CMM niveau N" ou "Sarbanes Oxley".
Bruce Ediger
SOX, mais seulement en partie. Lorsque nous sommes allés pour la première fois à TFS, les développeurs avaient accès à Main et Dev. Mais ensuite, "certains" développeurs (aucun dans mon équipe) ont décidé de faire juste du travail de développement sur Main plutôt que dans une branche Dev, donc maintenant toutes les équipes sont punies.
Michael Chatfield

Réponses:

8

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.

Wyatt Barnett
la source
3
+1, je tapais quelque chose de similaire: documenter le temps et les efforts perdus: laisser les décideurs faire un choix éclairé: le risque de tout ce qu'ils essaient d'éviter avec la politique restrictive actuelle en vaut-il le coût?
Jamie F
Je prévois d'organiser une telle réunion, mais il serait utile que je puisse montrer que cette politique va à l'encontre des "meilleures pratiques" de l'industrie.
Michael Chatfield
Je t'ai eu. Je ne sais pas si quelque chose de spécifique est là-dedans, mais les bits sur le contrôle de source dans The Pragmatic Programmer peuvent contenir des gemmes. D'après ce que cela semble être, il s'agissait d'une réaction exagérée à certains mauvais développeurs plutôt que d'une décision politique réfléchie ou d'une politique. Je me contenterais d'un accord où Ops possède fusionne avec Main. Je pousserais également à rendre les op responsables de veiller à ce que la fusion ne casse rien, ce qui finira probablement par les en sortir. . .
Wyatt Barnett
J'appuie Jamie, tout le temps passé à fusionner ou à attendre une fusion doit être enregistré afin que vous ayez des preuves. Il n'y a pas de «meilleure pratique» qui convient à toutes les entreprises. J'ai travaillé dans une grande entreprise où cette tâche était effectuée par une équipe de gestion de configuration dédiée. Dans mon entreprise actuelle, il existe une équipe de gestion des versions dédiée qui ne fait pas le travail physique de fusion avec le principal, mais ils sont le propriétaire logique et l'audit. Mais les opérations à mon humble avis ne sont généralement pas celles qui touchent le code source.
softveda
2

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.

Jan Hudec
la source
Je serais tout à fait pour un «intégrateur désigné», tant qu'il s'agit en fait d'un développeur de l'équipe. C'est la voie que j'espère de toute façon; c'est une petite équipe (4 personnes dont moi-même). Si tout va bien je peux obtenir l'accès pour créer / exécuter les manuscrits de construction de MS aussi, ce sera idiot pour moi de créer des manuscrits de nAnt pour des déploiements de développement et ensuite pour l'équipe "d'opérations" pour construire essentiellement le même manuscrit pour MSBuild. Mais c'est ce que je ferai si besoin est.
Michael Chatfield
2

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 ...

Murph
la source
1
Oui, essayant très fort de ne pas être conflictuel ... venant d'un gars dont la femme lui a acheté un T-shirt "Je suis d'accord avec vous, mais nous aurions tous les deux tort". :)
Michael Chatfield
C'est un tueur absolu quand vous avez raison (-: Et dans ce cas, il est difficile de prétendre que vous ne l'êtes pas ... mais vous avez besoin de votre gestion de ligne de côté si quelque chose va changer
Murph