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

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.

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.

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.

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