Please enable JavaScript.
Coggle requires JavaScript to display documents.
git, Premisas Gestión NVS
Ramas sistema deben estar protegidas para uso…
-
Premisas Gestión NVS
- Ramas sistema deben estar protegidas para uso exclusivo por usuario NVS
- Todo desarrollo se realizará en ramas Feature
2.1. Se configurará el origen para las ramas Features
- Todo Bugfix o Hotfix se realizará en ramas Bugfix o Hotfix
3.1 Ramas Bugfix y Hotfix podrán crearse desde cualquier rama de sistema
Gitflow
- No se puede asociar la misma versión al artefacto o aunque se asocie, la RC será siempre distinta
- Si un artefacto llega a un entorno y ya está en otro pack, el existente en el entorno es abandonado y su RC eliminada
Esto impide "adelantamientos". Siempre el último SHA es el que prevalece. Esto podría no ser cierto dependiendo del momento de colgar el SHA en el pack en desarrollo y su promoción.
Para evitar errores, todo artefacto contará con una marca en NVS sobre el último SHA desplegado (realmente está en el modelo ya, el internal_name del item en el entorno)BUGFIX
- La ruta irá desde "Rama Bugfix" al entorno deseado. En ese entorno DEBE existir una RC
- Se hará el merge en RC y se cambiará el SHA del artefacto existente en el paquete con el nuevo resultante del merge
- Se podría preguntar si aplicar cambio en entornos previos, validando que no haya otra RC (comprobación SHA desplegado artefacto). Si es factible, se realiza el despliegue
HOTFIX
- Ruta de "Rama Hotfix" a Producción
- Merge en master/production
- Posibilidad de retromigración...
La selección de elementos de promoción se hace para ofrecer el alcance definido y que no tenga que asociarse al tipo de paquete, porque "referencia git" es un tipo de elemento común
Idem, pero en este caso para paquetes de tipo gestión de defectos
Meramente informativo, serán los procesos de promoción los que hagan lo que deban hacer...
-