Skip to main content

git-workflow

A patir de la version 2114 el nombre de las branches tendra la siguiente sintaxis: VERSION_NAME-VERSION_TYPE

CĂłdigoDescripciĂłn
VERSION_NAMERepresenta el nombre de version determinado por la gerencia del proyecto (2112, 2114, 2116 para SAD; misma sintaxis para NAD solo que impares).
VERSION_TYPESon dos dev y rc.

RC: Release Candidate, sera la rama con los cambios aprobados por el tester que fueron revisados en la rama DEV. DEV: Development, contiene los cambios aun no testados (Los reworks se corrigen aqui).

Ejemplo​

  • 2114-dev
  • 2114-rc

Flujo de trabajo

Desarrollo​

  1. La branch de trabajo debera ser creada a partir del codigo limpio (rama RC).
  2. El Pull Request del codigo realizado sera inicialmente enviado a la rama de desarrollo (rama DEV); el PR debera ser comunicado incialmente al Squad Leader, el aprobará y negociará la aprobacion con los demas revisores.

Test​

  1. Si existieran observaciones del tester deberan ser corregido en la rama de desarrollo (rama DEV); el PR debera ser comunicado incialmente al Squad Leader como el paso anterior.
  2. Si los cambios cumplen con los requerimientos del User Story/Bug, el tester llevara la tarea a la columna TO RC/VERIFICATION reasignandola al desarrollador.
  3. El tester enviara un mensaje para notificar el desarrollador que el cambio cumple con los requerimientos y el codigo debera ser llevado a la rama release candidate (rama RC)
  4. El Desarrollador estará siempre pendiente de ver si hay una tarea suya (o asignada a el) en la columna TO RC/VERIFICATION.

Cambios a RC​

  1. El desarrollador hara cherry pick de los cambios de su PR original (debera considerar su orden basado en el tiempo del commit) a una nueva rama con destino a release candidate (rama RC).
  2. Informará al tester sobre el nuevo PR, quien sera el primero en aprobar el cambio.
  3. El tester informará al Squad Leader sobre el PR listo para produccion.
  4. El Squad Leader negociara su aprobacion con los demas revisores.
  5. Cuando el cherry pick haya sido aprobado y este en el sitio RC, debera reasignar la tarea al tester, para su verificacion final.

NOTA:

  • La aprobacion de un cambio en el PR de DEV a RC, seran tomados como una firma de validacion del cambio.
  • Una vez cumplido el ciclo anterior el User Story/Bug sera llevado a READY TO PROD/CLOSED segun corresponda.
  • Las branches a RC seran eliminadas una vez realizada la aprobacion.

Nombres de branch

Los nombres de las branches deberan seguir las siguientes convenciones:

  1. Todo el texto siempre va en minuscula.
  2. Debera contener su prefijo de acuerdo al trabajo.
  3. debera contener el nombre de la branch objetivo para el pull request de sus cambios.

Reservados (nombres puros)​

Las ramas con nombres puros (una sola palabra, ejemplo master, 2112, 2150) son ramas especiales y sus nombres una vez creados seran tomados como nombres de branch prohibidos y/o reservados.

Estructura basica de ramas de trabajo​

Las ramas de trabajo deberan cumplir la siguiente estructura: PREFIX/BRANCH/SHORT_DESCRIPTION-TASK_NO

CĂłdigoDescripciĂłn
PREFIXESPrefijos que dependen del trabajo que se esta haciendo.
BRANCHNombre de la branch a la cual la rama realizara el Pull Request.
SHORT_DESCRIPTIONDescripciĂłn corta separada por barras bajas (dash).
TASK_NONumero de tarea.

Prefijos para ramas​

feature: Para codigo de un llamado de tipo User Story hotfix: Para hotfixes, codigo que se aplicara directo a live o ira a la rama CURRENT. bugfix: Para codigo de un llamado de tipo Bug. support: Para codigo relacionado con soporte. Ejemplo: correciones internas de compilacion. release: Para merges hechos de arriba hacia abajo. Ejemplo: publicacion de version. merge: Para merges hechos de abajo haia arriba (merges escalares). Ejemplo: actualizacion de ramas futuras.