Puntos clave
- En las escaleras de Fabric con varios devs (test → staging → main), la punta rara vez está lista del todo.
- Hacer merge de toda la punta promociona el trabajo sin terminar junto con el que está listo.
- La forma más segura: cherry-pick de los commits de squash merge seleccionados a una rama de promoción de corta vida y, después, un PR hacia el siguiente entorno.
- Un cherry-pick sin la rama temporal + el PR es una higiene de promoción incompleta.
- Combina la selección en git con Variable Library y el rebind de los items. git por sí solo no es un despliegue.
- A escala, el infierno del cherry-pick es real. Reduce el conjunto de la release y documenta por escrito la lista de picks.
Tienes tres desarrolladores en test. La feature A está probada. La B está a medio construir. La C todavía apunta a un spike desechable. Alguien abre un PR desde la punta de test hacia staging porque "así funciona la escalera". Ahora staging tiene trabajo sin terminar que nunca quisiste llevar ahí.
Promociona por commit, no por la punta. Selecciona los commits de squash merge que están listos, déjalos en una rama de promoción de corta vida, abre un PR hacia la rama del siguiente entorno y despliega. Así el blast radius es honesto.
Modelo con nombre: promociona por commit, no por la punta
- Punta: el estado actual de una rama de entorno (test, staging, main). En un repo con varios devs suele mezclar trabajo listo y sin terminar.
- Commits seleccionados: los SHA de squash merge que puedes nombrar como el conjunto de la release para esta promoción.
- Rama de promoción: una rama de corta vida creada desde la punta del siguiente entorno. Los cherry-picks caen aquí, no en la rama protegida de la escalera.
- Control del PR: rama temporal → siguiente entorno. La revisión, los checks y el rebind viajan con el PR. El cherry-pick por sí solo no es el control.
- Contrato: el blast radius es igual a los commits que nombraste, no a todo lo que casualmente estaba en la punta.
Figura 1. Modelo con nombre: promociona por commit, no por la punta. El merge de la punta hereda el trabajo en curso. Los commits squash seleccionados dejan lo inacabado en el peldaño inferior.
Contexto y restricción
Esta nota trata de la forma de la promoción en git a lo largo de una escalera de entornos de Fabric. Va junto a blast radius en Fabric CI/CD, que responde a otra pregunta: qué va a reconciliar el desplegador en el workspace cuando lances una promoción. Aquí la pregunta es qué commits dejas entrar en la siguiente rama antes de que se ejecute ese despliegue.
Las restricciones: varios desarrolladores, features sin terminar en test y la necesidad de promocionar de forma selectiva a staging o main sin esperar a todos los cambios en curso. Los diagramas clásicos de "merge por la escalera" quedan limpios en una diapositiva. Se rompen cuando la punta es un aparcamiento compartido.
Los hilos de la comunidad sobre Microsoft Fabric CI/CD acaban siempre en la misma aclaración: el cherry-pick no es un git cherry-pick suelto sobre la siguiente rama protegida. Es un cherry-pick a una rama temporal y luego un PR de esa rama hacia el siguiente entorno. Ese es el modelo que enseña esta nota.
Diseño
1. Dibuja la punta con honestidad
Haz una lista de lo que hay en la punta de test antes de abrir un PR escalera arriba. Feature A lista. Feature B en curso. Restos del spike de C. Si no puedes nombrar lo que está sin terminar, no estás listo para hacer merge de la punta. La figura 2 muestra la bifurcación: merge de la punta frente a commits squash seleccionados.
Figura 2. El camino A hace merge de toda la punta y promociona trabajo en curso. El camino B selecciona los commits squash listos. Lo inacabado se queda en test hasta tener su propio conjunto de release.
2. Usa los SHA de squash merge como unidad de release
Los PR de features que entran como squash merge te dan un SHA por feature. Ese SHA es el átomo de la promoción. Sin squash (o un contrato equivalente de commits limpios), la promoción selectiva se convierte en arqueología entre merge commits ruidosos. Escribe el conjunto de la release como una lista de SHA y responsables antes de que nadie toque git.
3. Usa una rama de promoción de corta vida y luego un PR
Crea promote/test-to-staging-<date> (o algo parecido) desde la punta de staging, no desde la punta de test. Haz cherry-pick de los SHA nombrados a esa rama temporal. Resuelve ahí los conflictos. Abre un PR hacia staging. No hagas push de cherry-picks directamente a las ramas de entorno protegidas. La figura 3 muestra esos cuatro pasos.
Figura 3. El cherry-pick aísla el conjunto de cambios. El PR es el control de la promoción. El despliegue se ejecuta después del merge, con Variable Library y el rebind en el mismo flujo.
4. Desplegar sigue siendo cirugía en el workspace
Después del merge del PR, fabric-cicd o los deployment pipelines siguen decidiendo qué se reconcilia en el workspace. Un historial de git seleccionado no reduce por sí solo una publicación a ciegas en el workspace. Mantén los filtros de items, los dry-runs y la lista de "nunca a ciegas" de la nota sobre blast radius. Combina esta promoción con destinos de despliegue con Variable Library para que los ID de lakehouse y de workspace se reasignen por etapa en lugar de subir con los enlaces de Dev.
5. Saber cuándo el merge de la punta sigue siendo correcto
Si la punta es un tren de release que está listo del todo (cada feature abierta está publicada o fuera de la rama), el merge de la punta es honesto y más barato. El cherry-pick selectivo es para el caso habitual con varios devs, donde test está mezclado a propósito. No montes un teatro de cherry-pick cuando la punta está limpia.
6. Pon límites al infierno del cherry-pick
A escala, una larga cola de commits entre peldaños hace que elegirlos uno a uno sea doloroso. Reduce los trenes de release, mantén las features pequeñas, usa menos SHA por promoción y retira de la rama inferior el trabajo abandonado para que no persiga a cada lista de picks. Documenta la lista de picks en el cuerpo del PR para que la siguiente persona no tenga que adivinar.
Errores comunes
Hacer merge de la punta porque lo dice el diagrama de la escalera. Notebooks y enlaces sin terminar llegan a staging con un merge en verde.
Cherry-pick a la rama de entorno protegida sin PR. Sin superficie de revisión, sin checks, sin conjunto de release escrito y difícil de auditar.
Olvidar el PR después de un cherry-pick local. La rama temporal se queda en un portátil. El siguiente entorno nunca recibe el cambio. La persona cree que ha promocionado.
Tratar el cherry-pick como git puro, sin rebind. Los items se mueven, pero los ID de lakehouse y de conexión siguen apuntando a la etapa inferior. El despliegue "ha funcionado". El plano de datos miente.
Infierno del cherry-pick sin higiene en los trenes de release. Una larga cola de commits, responsables poco claros y tormentas de conflictos. Bajo presión, el proceso vuelve a los merges de la punta.
Saltarse Variable Library y las reglas de despliegue. Una promoción selectiva en git también necesita enlaces seguros para cada etapa. La selección en git no sustituye al mapa de entornos.
Úsalo tal cual o adáptalo
Úsalo tal cual
- Promociona por commit, no por la punta, cuando hay trabajo sin terminar en el peldaño inferior.
- Un conjunto de release escrito con los SHA de squash merge antes de empezar el cherry-pick.
- Una rama de promoción de corta vida creada desde la punta del siguiente entorno y, después, un PR hacia ese entorno.
- Despliegue después del merge con dry-run de fabric-cicd o del pipeline y reasignación con Variable Library.
- Merge de la punta solo cuando la punta está realmente lista del todo.
- Un cuerpo de PR que liste los SHA, los responsables y las notas de rebind.
Adáptalo antes de usarlo
El cherry-pick tiene un coste operativo. El merge de la punta es más barato cuando la punta está limpia. Imponer la promoción selectiva a un equipo trunk-based que despliega main de forma continua puede ser la forma equivocada. Ajusta el modelo a cuántas features sin terminar comparten de verdad una rama de entorno de larga vida. Y no copies "cherry-pick para siempre" sin reducir los trenes: el infierno a escala es una señal de mal diseño, no una medalla al rigor.
Relacionado
- Fabric CI/CD: ¿cómo limitas el blast radius entre workspaces de desarrollo? (lo que reconcilia el desplegador frente al conjunto de cambios en git)
- Variable Library: ¿cómo cambias los conjuntos de valores activos de dev a prod? (reasignación por etapa junto a la promoción en git)
- Fabric Branch Workspaces: ¿listos para git en equipo? (mantener cada cambio en su propio workspace de rama antes de que llegue a la escalera de promoción)
Fuentes (de la comunidad): Fabric CICD branch promotion strategy: merge or cherry-pick, además de la guía de Microsoft Learn sobre Fabric CI/CD y el flujo de git de fabric-cicd para ramas de entorno y promoción.
Nombra los commits. Crea la rama temporal. Abre el PR. Después despliega. La punta no es una nota de release.