CONFIGURATION MANAGEMENT

Con el objetivo de que la práctica de Configuration Management se esté cumpliendo, se pueden

realizar las siguientes validaciones:

1. Existencia de repositorio en VSTS con nombramiento adecuado:

<aw>_<nombreRepositorio>. Ejemplo: AW0278001_SVP

Ingresando a la pestaña “Code”, desplegando la opción “Vicepresidencia Servicios de Tecnología” y

dando clic en “All repositories”, se ingresa el nombre del repositorio para validar la existencia de este.

En caso de que no exista un repositorio se debe indagar cual es el motivo.

Algunas aplicaciones por las tecnologías que usan y que son diferentes de Isieries, SAP o
DataStage, tampoco aplican para versionar con GIT. Si no se ha realizado una validación,
se debe contactar al equipo DevOps para que se realice la respectiva validación.
Las aplicaciones que tienen código fuente y éste es propiedad del tercero y NO del banco,
no aplican para versionar en GIT.

NOTA: Tener en cuenta que hay casos en los que el proveedor es el único que
desarrolla la aplicación pero por contrato el código es propiedad del banco. Para
estos casos si aplica el versionamiento.

El versionamiento con GIT no aplica actualmente para todas las tecnologías del
banco.

 No aplica para Isieries, SAP o DataStage

2. Validar que la fecha de actualización de ramas sea acorde a las fechas de desarrollo del
proyecto.
a. Si la fecha de actualización de las ramas principales es antigua indagar cual podría
ser el motivo.
b. Si posterior a finalizar las pruebas, se actualiza la rama release indagar el motivo.
c. El pull request a master no se debe completar antes de que se entregue la carta
de certificación.
3. Validar que existan políticas de Pull Request.
a. Ingresar a la pestaña de “Branches”
b. Al lado izquierdo de la cada branch debe visualizarse una insignia, que es la que
indicar que ya se aplicaron las políticas de Pull Request.
c. Las políticas se deben aplicar en develop, inciativa y master.

4. Validar el cumplimiento de los lineamientos de GIT establecidos en Bancolombia, para el

correcto nombramiento de ramas.

https://bancolombia.sharepoint.com/sites/SitioDevops/Configuration%20Manage
ment/Dojo/Politicas%20GIT/Lineamientos%20GIT.pdf?csf=1&e=7c6c331256a2408
4aeaf1fe369a3f916
5. Existencia de un tag cada que se tenga una salida a producción.

6. Manejo de dependencias
a. Tener tarea “restore package” en el pipeline de IC.

En caso de no tenerla se puede validar en el build. Gradle que exista la conexión a

Artifactoy.
 CONTINUOS TESTING

1. Que tenga análisis estático de código

a. Ingresar al Sonar de Bancolombia.
http://sonar.bancolombia.corp/sonarbc/about
b. Ingresar a los proyectos analizados

c. Buscar el proyecto, por nombre de repositorio

2. Que tengan pruebas unitarias y exista cobertura.
Se puede validar desde sonar. Ingresando al proyecto analizado.

a. Y validando en Coverage que cobertura se tiene y cuantas pruebas unitarias