Control de origen: Roles y responsabilidades: mejores prácticas

10

Estoy buscando las "Mejores prácticas" con respecto a los roles y responsabilidades, específicamente quién es responsable de las fusiones desde las ramas de desarrollo hasta el tronco (o principal). Básicamente estoy buscando municiones para ayudar a mi causa.

Déjame describir lo que estoy enfrentando. Soy el desarrollador principal (propietario) de una aplicación en particular. Nuestra compañía se mudó recientemente de VSS (donde yo era el administrador de la base de datos VSS en la que estaba almacenada mi aplicación) a TFS (donde solo tengo permisos en las ramas de desarrollo creadas por nuestro equipo de "operaciones"). En trabajos anteriores, era administrador de TFS, así que conozco bien TFS y MSBuild.

No tengo ningún problema con la estrategia de ramificación y fusión utilizada (rama principal, con ramas de desarrollo de errores / proyectos creadas según sea necesario, fusionadas de nuevo a main y luego promovidas a una rama de lanzamiento). Los problemas que tengo son:

  1. No puedo crear mis propias ramas. Debo crear una tarea TFS para que un miembro del equipo de "operaciones" cree la rama por mí.

  2. No puedo fusionarme de Main a mi rama de desarrollo. Debo crear una tarea TFS para que un miembro del equipo de "operaciones" realice la fusión, y luego espero que no "pise" ninguno de los cambios de mi equipo ya que el "operador de operaciones" puede o no ser desarrollador y ciertamente lo ha hecho. poco o ningún conocimiento del código que está fusionando.

  3. No puedo fusionarme del desarrollo a Main. Nuevamente, debo crear una tarea TFS para que el "operador de operaciones" realice la fusión, con la esperanza de que lo haga correctamente. Luego, tengo que crear otra tarea TFS para volver a fusionarme en mi sucursal y poder resolver cualquier problema que haya ocurrido al tener una fusión que no sea de desarrollador en Main.

  4. No puedo crear ni editar scripts de MSBuild. Nuevamente, tengo que trabajar con el equipo de "operaciones" que es nuevo en MSBuild para que solo se puedan realizar las tareas de compilación más básicas. (Olvídate de cualquier cosa compleja, o el cielo no permita una tarea personalizada).

  5. No puedo ejecutar un script de MSBuild. Nuevamente, solo el equipo de "operaciones" puede hacer esto.

  6. Para completar todo esto, generalmente es un recurso "off-shore" que realiza las tareas solicitadas, por lo que incluso si creo la tarea para (ramificar / fusionar / construir) temprano en la mañana, probablemente no se completará hasta esa tarde

Ahora no tengo ningún problema con el equipo de "operaciones" que mantiene las ramas de lanzamiento. Como todo lo que están haciendo es (básicamente) tomar la última versión de Main y promocionarla a la rama de lanzamiento; así que mientras "Main" sea estable y esté listo, la rama de lanzamiento será buena.

Mi opinión es que los clientes potenciales técnicos (como I) deberían ser responsables de mantener el enlace troncal ("Principal") y cualquier fusión hacia / desde las ramas de desarrollo. El líder del equipo también debe tener la capacidad de generar scripts de MS Build para compilar e implementar en el entorno de prueba de integración.

¿Alguien puede dirigirme a un documento de Mejores Prácticas que me ayude a probar mi caso? Toda mi búsqueda ha dado como resultado las mejores prácticas relacionadas con las técnicas de ramificación y fusión, y ninguna mención de la OMS debería realizar dicha ramificación / fusión.

Michael Chatfield
fuente
WHO should be performing said branching/merging.Es una decisión organizacional interna. Realmente no es algo con lo que podamos ayudarlo ...
Yannis
2
¿Te importaría decirnos los supuestos motivos dados para un procedimiento tan bizantino? Mi conjetura es "cumplimiento CMM Nivel N" o "Sarbanes Oxley".
Bruce Ediger
SOX, pero solo en parte. Cuando fuimos por primera vez a TFS, los desarrolladores tenían acceso a Main y Dev. Pero luego "algunos" desarrolladores (ninguno en mi equipo) decidieron hacer el trabajo de desarrollo en Main en lugar de en una rama de desarrollo, por lo que ahora todos los equipos están siendo castigados.
Michael Chatfield

Respuestas:

8

Mi opinión general sobre las mejores prácticas es que cualquier miembro del equipo de desarrollo debe poder realizar cualquier acción en el árbol, suponiendo que esas acciones no hagan cosas como iniciar una implementación de producción. En los casos en que una rama / etiqueta / repositorio específico actúa como una fuente para implementaciones automatizadas que tienen algún control de cambio razonable o barreras de entrada tienen sentido, más desde una perspectiva de errores de mantenimiento simplemente errores que de un ángulo de control anormal. Animaría a los desarrolladores a crear ramas y mejorar los scripts de compilación. Encontraría formas de obtener acceso de los desarrolladores a la producción si fuera necesario. Parte del punto de control de la fuente es que es un borrador mágico eficaz de errores: lo peor que debe hacer es retroceder una o dos revoluciones y ramificar eso.

Desafortunadamente, esto no suena como el enfoque que han tomado aquí. Para vencer esto, creo que necesitas cubrir algunos ángulos:

a) Probar que estas políticas son perjudiciales para el desarrollo de las cosas. Registre todo el tiempo que pasa esperando en las operaciones para trabajar en algo. Esto solo debería vender una gestión razonable de por qué esta es una mala política.

b) Haz algunos amigos en Ops, quizás haya una razón para esta política. Quizás ese razonamiento podría abordarse de una manera más efectiva.

Espero que esto ayude.

Wyatt Barnett
fuente
3
+1, estaba escribiendo algo similar: documentar el tiempo y el esfuerzo perdidos: dejar que los tomadores de decisiones tomen una decisión informada: ¿vale la pena el riesgo de lo que sea que estén tratando de evitar con la política restrictiva actual?
Jamie F
Planeo tener una reunión así, pero ayudaría si pudiera mostrar que esta política va en contra de las "mejores prácticas" de la industria.
Michael Chatfield
Gotcha No estoy seguro de si hay algo específico allí, pero los bits en el control de fuente en The Pragmatic Programmer pueden tener algunas gemas. Por lo que parece que fue una reacción exagerada a algunos malos desarrolladores en lugar de una decisión política pensada o alguna política. Me conformaría con un trato donde Ops posee fusiones con Main. También presionaría para que las operaciones sean responsables de garantizar que la fusión no rompa nada, lo que probablemente terminará con que salgan de ella. . .
Wyatt Barnett
Segundo Jamie, todo el tiempo dedicado a fusionar o esperar que ocurra una fusión debe registrarse para que tenga evidencia. No existe una "mejor práctica" que se ajuste a todas las empresas. He trabajado en una gran empresa donde esta tarea fue realizada por un equipo de gestión de configuración dedicado. En mi compañía actual, hay un equipo dedicado de administración de versiones que no hace el trabajo físico de fusionarse con main, pero son el propietario lógico y lo auditan. Pero las operaciones de la OMI no suelen ser las que tocan el código fuente.
softveda 01 de
2

Las prácticas que he visto son:

  1. Cualquiera puede crear ramas de trabajo a su gusto. Un desarrollador debe poder crear una rama de características en el momento en que encuentra que hay un punto en el almacenamiento de su trabajo actual en progreso. Debido a que quieren / deben respaldarlo al final del día, quieren compartirlo con otro miembro del equipo, deben protegerse de los cambios en main o lo que sea.

  2. Cualquiera puede hacer absolutamente cualquier cosa para desarrollar ramas. El desarrollador debe poder fusionarse desde main en el momento en que otro desarrollador les dice que algo que necesitan se ha integrado en main.

  3. Para fusionar a main (integración), hay tres opciones:

    • Los desarrolladores lo hacen ellos mismos. Simplemente discuten los riesgos con el desarrollador principal y prueban las características adecuadamente. Eso implica que cualquiera tiene los permisos; si alguien rompe las reglas, simplemente se regaña y se revierte el cambio incorrecto.
    • Otro desarrollador lo hace después de revisar los cambios. Todavía requiere que todos tengan permisos para hacerlo; El desarrollador principal aún aplica las reglas.
    • Hay un integrador designado que revisa y se fusiona con main. Pero el integrador es parte del equipo y necesita comprender el código. En un equipo más pequeño sería la misma persona que el arquitecto, en un equipo más grande estarían separados, pero tendrían que cooperar estrechamente.
  4. Quien prepare una característica debe adaptar el script de compilación. Pero no estoy seguro de cómo funciona con TFS; En los sistemas que utilicé, el script de compilación siempre fue solo un archivo versionado, por lo que los desarrolladores lo editaron como cualquier otro y se integró junto con todo lo demás.

  5. Si hay un integrador designado, generalmente se encargan de definir (qué script ejecutar) y comenzar las compilaciones. De lo contrario, el líder del equipo lo hace, el miembro designado del equipo lo hace o cualquiera tiene permisos y los delegados líderes del equipo establecen e inician construcciones particulares caso por caso.

  6. En ningún caso las operaciones anteriores requieren un operador fuera del equipo. El operador solo es necesario para configurar los permisos, crear réplicas y demás.

Jan Hudec
fuente
Sería todo para un "integrador designado", siempre y cuando en realidad sea un desarrollador del equipo. Esa es la ruta que espero de todos modos; Es un equipo pequeño (4 personas incluyéndome a mí). Espero poder obtener acceso para crear / ejecutar los scripts de MS Build también, será una tontería para mí crear scripts de nAnt para implementaciones de desarrollo y luego para el equipo de "operaciones" construir esencialmente el mismo script para MSBuild. Pero, eso es lo que haré si es necesario.
Michael Chatfield
2

No importa las "mejores prácticas" (tenga paciencia conmigo), este es un problema de gestión, fundamentalmente no puede hacer su trabajo correctamente debido a las limitaciones que se le imponen.

En realidad, no importa cuál sea la "mejor práctica": se trata de un problema simple y demostrable que afectará la productividad de usted y su equipo y debe abordarlo con su administración de línea sobre esa base.

Puedo ver que blandir un documento de mejores prácticas podría (pero solo podría ) ser una ayuda para intentar persuadirlos, pero mucho mejor es la noción de que tendrá que tener miembros del equipo de desarrollo sentados en sus manos mientras esperan a alguien en una zona horaria diferente para actuar juntos a menos que los procesos se mejoren / racionalicen.

Y no sea demasiado conflictivo, tanto como cualquier cosa que quiera saber por qué existen las restricciones, cuál es la justificación ...

Murph
fuente
1
Sí, tratando muy duro de no ser confrontativo ... viniendo de un chico cuya esposa le compró una camiseta de "Estoy de acuerdo contigo, pero ambos estaríamos equivocados". :)
Michael Chatfield
Es un asesino absoluto cuando tienes razón (-: Y en este caso es difícil argumentar que no lo eres ... pero necesitas tu administración de línea de lado si algo va a cambiar
Murph