¿Qué ventajas tiene el control de código fuente en un repositorio de entornos de tres etapas?

7

La empresa actual para la que estoy trabajando tiene lo que considero una configuración inusual para su sistema de control de versiones. Estoy trabajando con eso, pero no puedo evitar sentir que lo que están haciendo es subóptimo y que tendrían un proceso mucho mejor si usaran lo que considero un enfoque más estándar de Tronco, Rama, Etiqueta.

Les presenté esta idea y estaban abiertos al cambio, sin embargo, antes de que empiece a presionar para que se produzca este cambio (y posiblemente sea el que lo implemente), quiero asegurarme de que no me falten algunas ventajas. a su configuración actual que se perdería.

Usan lo que podría describirse como un enfoque de 'entorno de tres etapas', cada proyecto tendrá su propio repositorio y en ese repositorio las carpetas de nivel superior siempre serán DEV, UAT, PROD:

Unciclodedesarrollotípicoparaestoeselsiguiente:

  1. EldesarrolladorrevisalacarpetaDEV,realizacambiosylosvuelvearegistrar.
  2. ElequipodesoportetécnicoimplementaloscambiosdeDEVenelentornoUATyverificaloscambiosenlacarpetaUAT.Dadoqueestonoesmiresponsabilidad,noquedaclarosiestoesantesodespuésdelaspruebas.
  3. ElequipodesoportetécnicoimplementaloscambiosdeUATenelentornoProdylosverificaenlacarpetaProd.

EstoymásacostumbradoatrabajarconelmodeloTrunk,Branch,Tag:

(Imagende enlace )

Lo que se asignaría al ciclo de desarrollo actual de la empresa como:

  1. El desarrollador crea una rama para el trabajo de desarrollo, realiza cambios y lo etiqueta.
  2. Admite la implementación de la etiqueta en el entorno UAT. No hay necesidad de que revisen nada.
  3. Todo está bien. Soporta la implementación de la etiqueta en Prod. Contra no hay necesidad de que ellos registren nada (o podríamos etiquetar nuevamente para un registro distinto de un lanzamiento de producto).

Puedo ver muchas ventajas con el método TBT, pero realmente me cuesta encontrar por qué sería mejor el enfoque de tres etapas.

Aunque no puedo encontrar puntos fuertes en esto, aquí están los problemas que encuentro con el enfoque de tres etapas para aquellos a quienes les sería más fácil responder frente a algunos puntos específicos:

  • Casi siempre el código en las tres etapas no coincide y luego hay un período de fusión al inicio de cada proyecto.
  • Cuando me registro en DEV, no puedo garantizar que mis cambios estén en cascada a través de UAT y Prod al final del proyecto. Esto no debería ser mi responsabilidad de verificar (IMHO), pero cuando se necesitan más cambios, se convierte en mi problema porque debo asegurarme de que DEV no se haya alejado de UAT y Prod.
  • La idea de las ramas de características simplemente no encaja con esto, a menos que nos bifurcamos en DEV y hagamos una rama coincidente en UAT donde la rama DEV se promocione a. Normalmente, solo tenemos 1 desarrollador en un proyecto, por lo que no es un problema, puedo trabajar directamente en troncales sin conflictos, pero prefiero seguir las mejores prácticas para poder crecer sin problemas si lo hacemos.
  • No hay una manera sólida de confirmar qué versión está actualmente en qué entorno. Con una etiqueta que puedo decir, la versión UAT1.2.3 se publicó el 1 de enero, con la configuración actual que necesito para consultar el historial de revisiones, ver qué se registró cuando y casarlo con las fechas de lanzamiento.

No sé si es la falta de terminología correcta o simplemente porque es un enfoque intrínsecamente malo, pero me cuesta mucho encontrar recursos que promuevan o discutan esta estructura. Aquí es uno que he encontrado con alguien que pregunta. La misma pregunta y sigo buscando activamente.

¿Qué me estoy perdiendo aquí? ¿Cuáles son las ventajas del enfoque de tres etapas sobre TBT y otros? ¿O no hay ninguno y el enfoque de tres etapas no es realmente una cosa?

    
pregunta RyanfaeScotland 01.11.2017 - 16:12

2 respuestas

5

Las sucursales son definitivamente el camino a seguir, y en los sistemas SCM modernos, trabajar con sucursales es muy eficiente, por lo que no hay razón para no hacerlo.

En los sistemas SCM más antiguos, las sucursales eran tan ineficientes en los proyectos de tamaño moderado a grande que eran completamente inutilizables.

Supongo que su sistema 1) se migró de un SCM donde las sucursales estaban inutilizables y el proceso no se actualizó o 2) Diseñado por alguien que tiene conocimiento de los sistemas SCM está obsoleto, y no se dan cuenta de que las sucursales ahora funciona de manera muy eficiente incluso en bases de código muy grandes.

    
respondido por el bikeman868 02.11.2017 - 05:17
0

He trabajado con un sistema algo similar en el escritorio. Principalmente esto se usó para permitir a los desarrolladores cambiar las versiones de código rápidamente. Esto estaba basado en ramas de código.

  • Dev - desarrollo continuo.
  • UAT: parcheando UAT después de cortar una rama de lanzamiento.
  • Prod - parcheando la rama de producción después de un lanzamiento.

Las diferentes organizaciones utilizan diferentes métodos de promoción de código. Dependiendo de los requisitos, puede haber revisiones significativas del código antes de pasar al siguiente entorno. Sea cual sea el modelo que se utilice, será necesario sincronizar los cambios de nuevo a la secuencia de desarrollo.

Su organización puede usar repositorios de código separados para el desarrollo y la organización. No esperaría un tercer repositorio para la producción. Tener dos repositorios no es tan raro, y funciona bien cuando se requieren o desean migraciones formales. El repositorio de lanzamiento puede tener reglas de acceso bastante estrictas, al tiempo que permite el acceso abierto al repositorio de desarrollo. Los cambios de desarrollo se importan en el repositorio de versiones después de cierta validación. Los cambios rechazados deben revertirse fuera del repositorio de desarrollo.

    
respondido por el BillThor 05.11.2017 - 03:20

Lea otras preguntas en las etiquetas