Simular un set de cambios de estilo tfs en la versión empresarial de github

Tengo tres ambientes; desarrollo, testing y puesta en escena / prod. En nuestro model anterior de uso de Team Foundation Server, tendríamos tres twigs de código que coincidían con cada uno de estos tres entornos.

Los desarrolladores trabajarían localmente y cuando tuvieran su código completo, lo verificarían en la twig de desarrollo. Cuando se registra, TFS crea automáticamente algo llamado set de cambios. Este check-in iniciaría una compilation de los files en código que luego se implementaría en el entorno de desarrollo.

Cuando un desarrollador estaba contento con su código en dev, fusionaban solo su set de cambios en la twig de testing. Buscarían una list completa de todos los sets de cambios disponibles que no se habían fusionado para probarlos, seleccionarían los de ellos y los verificaría en la twig de testing. Una vez más, esto iniciaría una compilation y los files de salida se implementarían para probar.

Una vez que QA estaba contento con los cambios, el desarrollador fusionaría este set de cambios en la twig prod. Comenzar una compilation y los files se desplegarán en el área de ensayo. El desarrollador y el QA los promocionarían a prod.

Todo permitiría que múltiples desarrolladores trabajen en los mismos files usando esta mentalidad de set de cambios. Cuando un set de cambios específico (o set de sets de cambios) se fusionó en otro entorno, solo esos cambios se fusionarían.

En mi exposition relativamente nueva a git, parece que no puedo encontrar una manera de seleccionar "requestes de extracción" específicas (que supongo que es similar a un set de cambios de TFS) de una twig a otra. Cuando trato de hacer una request de extracción de una twig a otra, quiere incorporar no solo mi request de extracción, sino también otras requestes de extracción realizadas en la twig inferior por otros desarrolladores. ¿Cuál es la forma mágica de hacer que esto suceda?

Nota : Desafortunadamente no tenemos la idea de un "lanzamiento". Tenemos cinco equipos de scrum trabajando en un website con más de 200 páginas. Cada equipo de scrum tiene sus propios sprints y puede lanzar múltiples historias de scrum durante su sprint. Tenemos internamente solo un entorno DEV, y un entorno de PRUEBA y un entorno de PROD. Nuestros cinco equipos scrum no solo utilizan nuestros entornos, sino que estos sitios DEV / TEST / PROD también son utilizados por otros equipos para esfuerzos de integración con aplicaciones que vendemos y también para la administración y compras de counts de clientes. No podemos cambiar esa infraestructura.

Nota : esto no es para una discusión sobre si esta metodología de "set de cambios" es correcta o adecuada. Esta es una cuestión de cómo lograr este comportamiento en github / git.

Nota : somos un set de equipos ágiles basados ​​en el scrum. Trabajamos a partir de historias. Hasta 60 historias pueden estar activamente en desarrollo en un momento dado con nuestro gran equipo de más de 25 desarrolladores. Cuando una historia está list para la producción, la promovemos al entorno de producción como una unidad atómica. Entonces piense en un set de cambios como una historia.

Tengo dos pensamientos:

  1. No lo hagas de esta manera. En cambio, debes mirar a git-flow. http://danielkummer.github.io/git-flow-cheatsheet/ y http://nvie.com/posts/a-successful-git-branching-model/ son buenas explicaciones. En esencia, git-flow es una convención de nomenclatura para las sucursales, por lo que en realidad no está ligada a git. En esencia, tiene twigs de características en las que trabaja cada desarrollador o equipo de desarrollo. Una vez que completan una function, se fusionan en develop . develop es "características hechas", no "hecho hecho", sino "característica completa". Cuando consideramos que es el momento de lanzar, nos dirigimos a una nueva release/someversion twig de release/someversion (nombre para que coincida con el nombre de la versión), y luego trabajamos con QA para reforzar la versión. Los release/someversion twig de release/someversion son solo correcciones de errores. Una vez que es lo suficientemente bueno para implementarlo, avanzamos rápidamente la twig master hasta la twig de lanzamiento a medida que la llevamos a producción. master entonces representa lo que está en producción. A medida que implementamos, también release/someversion en el develop para que las correcciones de errores entren en la línea principal del desarrollo. El gerente del proyecto / propietario del producto puede pensar en la twig de develop como "la última", y los desarrolladores pueden continuar en sus twigs de características hasta que se completen las características. (Sugerencia, haga que las características sean pequeñas, como una hora o un día. Las características no son versiones).

Entonces, ¿por qué es esto mejor que la forma en que lo estabas haciendo? Si la function está list, lo suficientemente list para que el control de calidad comience a golpearla, ya está list para ser parte de la próxima versión. Escoger y elegir características una de la otra te llevará a errores muy sutiles e impnetworkingecibles. Como se está fusionando en cada paso, tiene la posibilidad de que se fusione incorrectamente, creando un error. Ahora también está creando un producto único en cada paso, por lo que podría llegar a la producción con un set de funciones completamente diferente al que comprobó en el desarrollo y la testing. (¿Esto hará cosas malas? Pregúntele a su farmacéutico si estos medicamentos interactúan cuando se toman juntos).

Git-flow funciona muy bien para cadencias en las que tienes lanzamientos bien coordinados, infrecuentes y de mayor tamaño. A medida que te acerques a la entrega continua, esta ceremonia se interpondrá en tu path. En ese momento, puede optar por cambiar al flujo de GitHub o una convención de nomenclatura similar más liviana.

  1. Si estás realmente, realmente (mira el comentario anterior "no deberías hacerlo así") convencido de que deberías hacerlo de esta manera, primero, ve a convencer a un patán de goma y con suerte lo habrás convencido a ti mismo. . Si todavía estás realmente convencido de que tienes que hacer esto, con frecuencia necesitarás aplastar tus compromisos creando una confirmación grande para toda la function, luego selecciona el set de cambios entre las twigs.

Hay algunas desventajas para este enfoque de "squash y cherry pick". 1. Pierdes la historia. Ya que está aplastando la historia, ahora debe mantener las características en packages muy contenidos y, con frecuencia, editar el package en set. Una de las premisas principales del control de fuente es que obtiene un historial de auditoría, tanto para revertir como si algo sale mal, y para hacer reference cuando necesita saber por qué algo funciona de esta manera o con quién hablar sobre ello. (Ver "culpa de git".) Cuando aplastas, intencionalmente eliminas esa herramienta de aprendizaje. 2. Estás reproduciendo funciones en su lugar en diferentes órdenes. Entonces, con frecuencia haces fusiones. Lo que hace que Git sea tan increíble es fusionarse es fácil. Lo que hace que Git Merging sea fácil es hacerlo en pedazos pequeños. Esta metodología de aplastar todo lo relacionado con esta característica en un gran compromiso y seleccionarla entre las twigs significa que estás haciendo fusiones muy grandes … lo que significa que será difícil.

Sí, sé que estás muy enamorada de la forma en que siempre ha sido, y realmente no quieres que nadie te diga que tu bebé es feo. Lo siento. Tu bebé era feo Por el lado bueno, no tiene que ser así. El flujo de Git es increíble y definitivamente puede facilitar la velocidad que su equipo necesita.

Tu comportamiento anterior fue disfuncional. Aunque no es inusual: http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/

En Git lo más probable es que quieras hacer dos cosas. El primero es seguir a Git Flow: http://nvie.com/posts/a-successful-git-branching-model/

Una vez que tenga esto, puede ver cómo crear una canalización de implementación para los binarys, no para la fuente. Deberías hacer una compilation desde MASTER y esa compilation pasa por tus entornos. Feliz de discutir aquí y fuera de línea.