Formulario de ALTA de PRODUCTO en DMCM para de Sistemas Distribuidos

Consideraciones para la implementación en Test y en Producción vÍa DIMENSIONS

• Todas las aplicaciones deben tener su ambiente de Compilación (Buildarea), el cual garantice por todos
los medios posibles, la relación entre fuente y ejecutable (si aplicara).
• Todas las aplicaciones deben tener un ambiente de TEST, especialmente las que estén en el catálogo de
aplicaciones relevantes, especificado por Continuidad de Negocio, caso contrario justificado y con las
debidas aprobaciones.
• Los ambientes de despliegue, Unix/Linux, Windows, bases de datos, etc., los crea Ingeniería Informática
y/o Servidores Departamentales a expreso pedido del sector de Sistemas, quien los deber solicitar
oportunamente y con la premura que esto implique. Gestión de Cambios e Implementaciones, solo puede
configurar en Dimensions con los datos de un ambiente ya creado.
• La carga inicial de las aplicaciones y sus próximas actualizaciones no pueden realizarse con instaladores ni
restors, ni deploys, etc.
• Para los scripts de base de datos, todo lo relacionado con estructuras tiene que venir en forma granular,
un scripts por cada componente, le mismo script tiene que poseer el nombre del objeto que está
creando, modificando o eliminando, con extensión .sql. Todo esto motivado por la necesidad de dar
cuenta a todas las entidades y sectores de contralor que así lo solicitaran, sobre el Ciclo de Vida de cada
uno de los objeto de bases de datos.
• El circuito de todos los componentes a implementar sea Windows, Unix, Linux, todos los SQL de
Estructura, Permisos y Datos, deben ingresar al sistema por Dimensions.
• Conforme se haya implementado en el área de TEST, se hará lo propio en PRODUCCION.
• El script DDL deberá contener la inteligencia suficiente (IF’s) para que a pesar de los sucesivos posibles
cambios que se realizan de la estructura en TEST, contando con el mismo archivo SQL se pueda crear con
idénticos atributos de estructura en el ambiente de PROD. (ver punto anterior).
• Gestión de Cambios e Implementaciones centraliza las gestiona de abm de permisos sobre objetos de
bbdd, que estén relacionado con un cambio de una aplicación, pero la tarea que realiza el sector de
Seguridad Informática.
• Las tareas de abm de datos la realiza Tareas Unix, pero que las centraliza Gestión de Cambios e
Implementaciones. Los scripts de modificación de datos pueden tener cualquier nombre, con extensión
.sql, y no necesariamente tiene que ser uno por cada dato, tabla, etc. que fuera a modificar. También, son
los únicos componentes que pueden ser implementados directamente en PRODUCCION sin pasar por
TEST.
• Los pasajes a TEST, pre estabilización de la aplicación entran en el esquema de Gestión de Cambios e
Implementaciones.
• Los pasajes de PRODUCCION, pre estabilización entran en el esquema de Gestión de Cambios e
Implementaciones.
• La única herramienta de Administración de Cambios (llámese así al versionamiento de fuentes,
ejecutables y scripts de base de datos de todo tipo, y la implementación de todos estos) es Dimensions,
con que se gestiona la promoción de los cambios a través de todos sus ambientes, y con la cual se
administran las versiones de estos cambios.
• Cualquier implementación, que no se ajuste a los ítems anteriormente citados, deberá contar con la
correspondiente aprobación de los gerentes de Tecnología Informática y de SISTEMAS, ya que se
estaría dejando al circuito del cambio en un estado de vulnerabilidad ante cualquiera de las entidades de
contralor, tanto interna como externa.
Nombre: Trazabilidad Código:
Objetivos: Recibir mensajes “crudos” de actividad de todos los aplicativos, formatearlos
y enviarlos a BI

Funciones Principales: Recibir mensajes de todos los aplicativos

Identificar el origen del mensaje
Dar formato al mensaje
Enviarlo a BI
Plataforma: BATCH
Lenguaje: JAVA
Tipo de Desarrollo: Interno
(Interno, Externo, Mixto)
Proveedor: -
Ubicación Física de los Usuarios: Torre, Reconquista 40, Reconquista 199
(Edificio/s)

En Dimensions CM

DMCM – Nombre del Producto Trazabldad

El nombre del producto esta limitado a 10 caracteres
DMCM – Descripción del Producto Trazabilidad Multi-Plataforma
Breve descripción de la finalidad del producto
Entrega los Fuentes: ​(Si/No) Si
De no entregar los fuentes debe justificar informando los
motivos, ya que el tema es regulatorio (BCRA), el de garantizar la
correspondencia entre fuente y ejecutable, y si por algún motivo
cree que este criterio no puede ser cumplido, debe dejarlo de
manifiesto.
Pasaje a Test: Consideraciones Especiales: Ninguna
Pasaje a Producción: Consideraciones Especiales: Ninguna
Limitaciones de horario para puesta en Producción: No
Proceso Crítico: ​(Si/No) No
DMCM – Tiene Build Servidor: Bbvas08
Indicar si los Build se Path: /desa/apps/misc/trazabilidad
automatizaran con Dimensions o Analistas con permisos para
no. el uso de este área Legajo: A116116
De no entregar los fuentes debe Nombre: Jorge Bogace
justificar informando los motivos, Legajo: A83352
ya que el tema es regulatorio
Nombre: Gustavo Domínico Rekuc
(BCRA), el de garantizar la
Legajo: A126666
correspondencia entre fuente y
Nombre: Raul Brum
ejecutable, y si por algún motivo
cree que este criterio no puede ser Legajo:
cumplido, debe dejarlo de Nombre:
manifiesto. Legajo:
Nombre:

De necesitar permisos de RO en el 1- ¿Que es lo que hay en esta ruta?

Servidro/Path, por favor, justificar 2 - ¿De que ambiente es esta información?
los motivos: 3 - ¿Cual es el motivo por el que la gente de d&d debe acceder a la misma?
DMCM – Tiene Base de datos Ambiente TEST PROD
Indicar si va a ser un producto para SQLServer, Sybase, Oracle, Oracle Oracle
scripts de base de datos DB2, MySQL
Server de TEST/Producción: Instancia /Server/ Dataserver BBVAODESA02/LDRH BBVAODESA02/LDRH
De no poseer ambiente de TEST OST OST
debe justificar informando los Nombre de la base LDRHOST LDRHOST
motivos, ya que el tema es
regulatorio (BCRA), el de las
pruebas en un ambiente de TEST,
previo a la implementación en los
ambientes productivos. Si por
algún motivo cree que este criterio
no puede ser cumplido, debe
dejarlo de manifiesto.
DMCM – Área de TESTEO: Servidor: bbvas08
Ubicación física del área de testeo Path: /test/apps/misc/trazabilidad
para el producto. Script Pre despliegue:
De no poseer ambiente de TEST Script Post despliegue:
debe justificar informando los Filtros Included: cfg/**
motivos, ya que el tema es lib/**
regulatorio (BCRA), el de las scripts/**
pruebas en un ambiente de TEST, Excluded: syscfg/**
previo a la implementación en los src/**
ambientes productivos. Si por dmscripts/**
algún motivo cree que este criterio launchers/**
no puede ser cumplido, debe .settings/**
dejarlo de manifiesto. directorioDeSI/**
docs/**
test/**
build.*
.classpath
.project
.dmignore
*.launch
*.filter.xml
runtime.*.txt
DMCM – Áreas de PRODUCCION​: Servidor: bbvas08
Ubicación física del área de Path: /prod/apps/misc/trazabilidad
producción para el producto
Script Pre despliegue:
Script Post despliegue:
Filtros Included: cfg/**
lib/**
scripts/**
Excluded: syscfg/**
src/**
dmscripts/**
launchers/**
.settings/**
directorioDeSI/**
docs/**
test/**
build.*
.classpath
.project
.dmignore
*.launch
*.filter.xml
runtime.*.txt
Usuarios y roles a asignar
Indicar que rol va a cumplir cada Legajo: A83352
usuario. Los roles son: Nombre: Gustavo Domínico Rekuc
- ​Líder eMail: gdominico@bbva.com
- ​Developer Sector: Arq Tec
- ​Builder Ubicación: Torre BBVA piso 14
- Testing Interno: 22237
Role/s: Líder

Legajo: A116116
Nombre: Jorge Bogace
eMail: jorge.bogace@bbva.com
Sector: Arq Tec
Ubicación: Torre BBVA piso 14
Interno: 22443
Role/s: Developer

Legajo: A116116
Nombre: Jorge Bogace
eMail: jorge.bogace@bbva.com
Sector: Arq Tec
Ubicación: Torre BBVA piso 14
Interno: 22443
Role/s: Builder

Legajo: A116116
Nombre: Jorge Bogace
eMail: jorge.bogace@bbva.com
Sector: Arq Tec
Ubicación: Torre BBVA piso 14
Interno: 22443
Role/s: Testing

Legajo: A126666
Nombre: Raul Brum
eMail: raul.brum@bbva.com
Sector: Arq Tec
Ubicación: Torre BBVA piso 14
Interno: 21321
Role/s: Developer