PROCESOS GDC Y GDE

2020
Índice
Creación de proyecto .................................................................................................................... 3
Solicitud de MERGE a Desarrollo. ................................................................................................ 4
Solicitud de MERGE a Test ........................................................................................................... 6
Solicitud de generación de OC UAT ............................................................................................. 7
Proceso RC ................................................................................................................................... 9
Creación de TTP ......................................................................................................................... 11
Sincronización a master .............................................................................................................. 14

TIGO

2
 1 Creación de proyecto
Cuando se requiera un nuevo proyecto en GitLab, el desarrollador Solicita por correo y Jira la creación del
proyecto a GDC.
La solicitud debe proveer la siguiente información.
 Nombre de la aplicación.
 Objetivo y descripción del proyecto.
 Subir línea base a un servidor FTP o si el proyecto es nuevo informarlo.

Creación de ramas.
El desarrollador solicita a GDC la creación de la rama por Jira y correo, el cual contendrá el proyecto
asociado y los objetos impactados.
Las ramas deberán ser creadas con base en la siguiente nomenclatura:
 Feats RQ-numeroRequerimiento
 Fix OC-numeroOrdenCambio o
 Flujos Express FE-numeroFlujoExpress, según sea el caso. Ejem. RQ-51928.

TIGO

3
 2 Solicitud de MERGE a Desarrollo.

Una vez finalizado el desarrollo, el desarrollador deberá realizar la solicitud de Merge Request a desarrollo
e informar por correo y jira. En el correo debe evidenciarse el nombre del proyecto, la URL de la solicitud de
MERGE y el Jira, todo correo debe ser enviado a Usuario Generico gctigocol gctigocol@indracompany.com.

GDC procederá a realizar las siguientes verificaciones antes de realizar el MERGE.

 Se verifica que la rama sea creada por GDC

 Se verifica que los objetos en la rama sean los mismos cuando informaron por correo la creación de
la rama, si los objetos son diferentes GDC informara por correo si se deben integrar los cambios.
 Si aplica, se verifica el sonar antes de aplicar los cambios y se realiza una captura de pantalla.
 En caso que no se deba integrar un commit de la rama de desarrollo, el desarrollador deberá
informarlo vía correo o asegurarse de hacer revert de dicho commit
 Se verificara que el desarrollador tenga la marca del código, esta marca debe contener (Numero-
Nombre del Requerimiento, Descripción corta de la función, fecha.). Cuando la marca del código no
aplique el desarrollador deberá informar que no aplica y el porqué.

Se evidencia pantallazo de solicitud de MERGE Desarrollo por correo.

Si cumple lo anterior, GDC procederá a realizar el MERGE.

Una vez GDC realice el MERGE y el push se puede evidenciar en el GIT dicho MERGE.

TIGO

4
GDC procedera a responder correo informando que se realizo el MERGE into Desarrollo.

 Se evidencia una captura de pantalla con el MERGE integrado

 Si aplica, se evidencia dos capturas de pantalla del sonar, una antes de aplicar los cambios,
aplicando los cambios.

TIGO

5
 3 Solicitud de MERGE a Test

Una vez el desarrollador termine sus pruebas unitarias deberá realizar la solicitud de Merge Request a Test
e informar por correo y jira. En el correo debe evidenciarse el nombre del proyecto, la URL de la solicitud de
MERGE y el Jira, todo correo debe ser enviado a Usuario Generico gctigocol gctigocol@indracompany.com.

GDC procederá a realizar las siguientes verificaciones antes de realizar el MERGE.

 Verificar que se realizó el MERGE a desarrollo y que el sonar este correcto

 Se verifica sonar de Test antes de aplicar el cambio y se realiza una toma de captura de pantalla.
 En caso que no se deba integrar un commit de la rama de desarrollo, el desarrollador deberá
informarlo vía correo o asegurarse de hacer revert de dicho commit

Se evidencia pantallazo de solicitud de Test Desarrollo por correo.

Si cumple lo anterior GDC procederá a realizar el MERGE.

Una vez GDC realice el MERGE y el push se puede evidenciar en el GIT dicho MERGE.

GDC procedera a responder correo informando que se realizo el MERGE into Test.

 Se evidencia una captura de pantalla con el MERGE integrado

 Si aplica, se evidencia dos capturas de pantalla del sonar, una antes de aplicar los cambios,
aplicando los cambios.
 Se envia la URL de los objetos del Artifactory

TIGO

6
 4 Solicitud de generación de OC UAT

Una vez el desarrollador requiera realizar el paso a UAT del desasollo, realizar la solicitud de Creación de
OC UAT por correo al Usuario Generico gctigocol gctigocol@indracompany.com. y jira. En el correo debe
evidenciarse la siguiente información:

 N° de RQ-OC- ITPAM] Nombre corto del RQ – Aplicativo al que pertenece.

 Entorno: Describir a que ambiente se debe realizar la solicitud.
 Fecha del despliegue:
 Archivos a tener en cuenta en el despliegue:
 Aplicación:
 Módulo: (Si Aplica)
 Grupo ejecutor: (Si Aplica)
 Tarea JIRA:
 URL GDOP:
 Se envia la URL de los objetos del Artifactory enviada por GDC
 Notas: (Si aplica)

En el correo solo debe de ir la solicitud de creación de la OC.

GdE procederá a realizar las siguientes verificaciones antes de realizar la OC UAT:

 Verificar que se realizó la creación de la rama, el MERGE a desarrollo, test y que el sonar este
correcto (cuando aplique).
 Se verifica que los insumos dados en GDOP sean idénticos a los que proporciona el JENKISN. En
caso de no aplicar merge a GIT, se procede a realizar la solicitud.
 Identificar los insumos dé marcha atrás (ROLLBACK) en una carpeta aparte llamada: ROLLBACK
 Carpeta de SCRIPTS

Si la solicitud cumple con todo lo anterior, se produce a realizar la OC de UAT solicitada con la URL del
Artifactory corrrspondiente, la cual se envía por correo al solicitante y al equipo de Operaciones INDRA
para su respectiva ejecución.
En caso de que la OC no sea ejecutada por el grupo de operaciones de INDRA, se envía al solicitante el
número de la OC.
Adjunto correo de solicitud de OC UAT y TTP.

Ejemplo de correo de solicitud de OC UAT

TIGO

7
TIGO

8
 5 Proceso RC

Una vez Se tenga una fecha tentativa para el paso a producción, el desarrollador deberá informar por
correo y Jira la solicitud de creación del RC, En el correo debe evidenciarse el nombre del proyecto, el
número de RQ,OC, FE , todo correo debe ser enviado a Usuario Generico gctigocol
gctigocol@indracompany.com.

GDC procederá a realizar las siguientes verificaciones antes de realizar el RC.

 Se verifica que las integraciones a Desarrollo y Test estén aplicadas en el GIT.

 Se verifica que el sonar este correcto en Desarrollo y Test.
 En caso que no se deba integrar un commit de la rama de desarrollo, el desarrollador deberá
informarlo vía correo o asegurarse de hacer revert de dicho commit

Se evidencia pantallazo de solicitud de RC por correo.

Si cumple lo anterior GDC procederá a realizar el RC.

GDC crea el RC a partir de master, Este RC será protegido para garantizar que no se puedan ingresar
cambios, se realizara un MERGE del Requerimiento al RC con esto se garantiza solo llevar los cambios del
requerimiento.

GDC responde el correo informando que se generó el RC.

 Nota: El RC solo tendrá vigencia de tres (3) días hábiles luego del paso a producción, una vez pasen
esos tres días y no se allá pasado a producción, se procederá a borrar el RC.

Casos Especiales.

En el caso de elite una vez que se cree el RC no se podrá borrar, el RC se genera cuando se termine las
pruebas de UAT.

TIGO

9
En el caso de Prepago y promociones el RC se genera para pasar a UAT, una vez se tenga la fecha estimada
de paso a producción el desarrollador deberá pedir a GDC por correo y jira actualización del RC.

TIGO

10
 6 Creación de TTP

Una vez se hallan realizado todos los pasos anteriores y el desarrollador requiera realizar el paso a
producción del desarrollo, realizar la solicitud de creación de TTP por correo al Usuario Generico gctigocol
gctigocol@indracompany.com y jira. En el correo debe evidenciarse la siguiente información:

 N° de RQ-OC- ITPAM] Nombre corto del RQ – Aplicativo al que pertenece.

 Entorno: Describir a que ambiente se debe realizar la solicitud.
 Origen puede tener los siguientes valores:
 Proyecto
 DM (Para desarrollos menores)
 FIX
 IdentificaciónProyecto, corresponde al ITPAM/Bizflow del requerimiento (proyecto). Se debe tomar
del campo “Código/ID” del archivo de capacidad.
Nota: Para los fix corresponde al número de la OC
 NombreProyecto, corresponde al nombre del requerimiento (proyecto). Se debe tomar del campo
“Proyecto” del archivo de capacidad.
 Fecha del despliegue:
 ET responsable de TIGO:
 Archivos a tener en cuenta en el despliegue:
 Aplicación:
 Módulo: (Si Aplica)
 OC DE UAT:
 Grupo ejecutor: (Si Aplica)
 Tarea JIRA:
 URL GDOP:
 Se envía la URL de los objetos del Artifactory enviada por GDC
 Notas: (Si aplica)

GdE procederá a realizar las siguientes verificaciones antes de realizar el TTP:

 Verificar que se realizó la creación de la rama, el MERGE a desarrollo, test y que el sonar este
correcto (cuando aplique).
 Verificar que se solicitó el RC para el paso a producción y que los insumos a desplegar se tomen del
RC (cuando aplique).
 Validad que se haya realizado OC de UAT y el despliegue sea satisfactorio, con log de ejecución
adjunto y cerrada.
 Que se entregue toda la documentación necesaria:

- OC UAT (Desarrollo)
- Paso entre ambientes (Desarrollo)
- Manual de instalación (Desarrollo)
- Insumos para despliegue (Tomados del RC cuando aplique)
- Matriz de riesgos (Desarrollo)
TIGO

11
 - Formato de generación (Desarrollo)
- Formato de aprobación (TIGO)
- Correo original del Formato de aprobación (TIGO)
- Carta de certificación (TIGO - INDRA)
- Blue print (TIGO)
- Aval del blue print (No desarrollo menor) (TIGO)
- Aval de la PMO (No desarrollo menor) (TIGO)
- Aval Líder técnico aplicación (FIX)
- Aval Líder funcional (FIX)
- Aval Usuario solicitante (FIX)
- Aval del diagnóstico (FIX)
- Correo de excepción (si aplica)
- Aval del dueño de la aplicación (TIGO)

Nota: la documentación que entrega TIGO, GdE se encarga de solicitarla directamente al ET.

Si la solicitud cumple con todo lo anterior, se produce a realizar las siguientes actividades:

- Agendar reunión con Operaciones (Controller jegomez@indracompany.com) y el

desarrollador o solicitante del TTP para socialización del paso a producción, si el
desarrollador no realiza la socialización con el equipo de operaciones, este será cancelado.
- Generar el TTP solicitado, llevando por base de revisión de documentación y realización de
TTP el check list generado.

Una vez realizado el TTP completamente se envía por correo al solicitante el número del TTP y el estado en
el que se encuentra actualmente.
Adjunto correo de solicitud de OC UAT y TTP.

Adjunto checklist que debe realizar GdE para generar TTPs.

Checklist Entrega a
cliente - v2.xls

NOTA: Esto aplica para FIXES y RQ.

Una vez el TTP haya sido aprobado, ejecutado y avanzado por el equipo ejecutor, se solicita al desarrollador
el estado actual del desarrollo desplegado en producción para proceder con el cierre del mismo.
Por favor informar lo siguiente en el estado de los TTP:

- Genero falla
- Genero afectación

TIGO

12
 - Ejecutado satisfactoriamente

Recordar que las indicaciones de TIGO todos los TTPS se deben enviar con 3 días hábiles para las
aprobaciones necesarias.
Todas las solicitudes de TTP deben ser antes de las 5 pm, las solicitudes posteriores a esta hora, serán
atendidas al día siguiente hábil.

TIGO

13
 7 TTP EXTRAORDINARIO
Estos TTPS debe de tener toda la documentación de un TTP normal, la diferencias es que en el Campo
DESCRIPCION, se puede ejecutar el mismos día de solicitud, se debe resaltar que el TTP es
EXTRAORDINARIO, se debe adjuntar el FORMATO DE APROBACION TTP EXTRORDINARIO junto con el
correo de Aval de Alejandro Toro o Jairo Díaz
Estos TTPS se deben enviar antes de las 5 pm para revisión de Administración de cambios.
Hay que asegurarse que quede aprobado el TTP para la ejecución.

8 TTP EMERGENCIA
El desarrollador realizar la solicitud de creación de TTP de EMERGENCI por correo al Usuario Generico
gctigocol gctigocol@indracompany.com y jira, en este debe enviarse la misma información que se da para
los TTPs junto con el TT de falla asociado.

Desarrollo debe entregar la siguiente documentación:

- OC UAT (Desarrollo)
- Paso entre ambientes (Desarrollo)
- Manual de instalación (Desarrollo)
- Matriz de riesgos (Desarrollo)

Estos TTPS deben tener las siguientes características:

- Un TT asociado
- El TT debe está en estado SOLUCION EN PROCESO
- El impacto del TT debe ser: medio, alto o crítico
- Origen del cambio debe ser: EMERGENCIA
- Adjuntar el formato de aprobación de EMERGENCIA
- Aval de Alejandro Toro o Jairo Diaz
- Avanzar las tareas de administración de cambios y
- Cambiar el estado del TTP al estado APROBADO
- Asociar el número del TT al TTP
- Que se entregue toda la documentación necesaria:
Una vez se tenga toda la documentación se genera el TTP y se aprueba para que sea ejecutado.

 Enviar los insumos del RC actual.

 En el correo solo debe de ir la solicitud de creación del TTP.

TIGO

14
 9 Sincronización a master

Una vez el TTP esté cerrado finalizado/Ejecutado con éxito, el desarrollador deberá informar por correo y
Jira la solicitud la sincronización del RC into master.
En el correo debe evidenciarse el nombre del proyecto, URL de la solicitud del MERGE, Numero de TTP,
todo correo debe ser enviado a Usuario Generico gctigocol gctigocol@indracompany.com.

GDC procederá a realizar las siguientes verificaciones antes de realizar la sincronización con master.

 El TTP esté cerrado finalizado/ejecutado con éxito.

 Si aplica, se verifica el Sonar de Test este correctamente.
 Si aplica, se toma una captura al Sonar de master antes de aplicar los cambios
 En el correo solo debe de ir la solicitud de sincronización a master.

Se evidencia pantallazo de solicitud de sincronización a master.

Si cumple lo anterior GDC procederá a realizar la integración.

Una vez GDC realice el MERGE y el push se puede evidenciar en el GIT dicho MERGE.

GDC procedera a responder correo informando que se realizo el MERGE into Master.

 Se envia pantallazo evidenciando que se realizo el MERGE.

 Se evidencia pantallazo del sonar antes de aplicar cambios.
 Se evidencia pantallazo del sonar aplicando los cambios

TIGO

15
Persona de contacto
hggarces@indracompany.com

jbotero@indracompany.com

www.minsait.com