Wiki

Has cargado una revisión vieja del documento! Si la guardas crearás una versión nueva con estos datos.

====== ScriptsDB - Proceso: Creación de Scripts ======
Esta sección define el proceso de creación de scripts para soportar los desarrollos, ajustes, mejoras y solicitudes de cambios que impacten el modelo entidad relación de **SICOF ERP**.

Antes de describir el proceso es importante la compresión de los siguientes conceptos.

===== Conceptos Previos =====

* **Script de Actualización**: Son los scripts que contienen instrucciones [[https://es.wikipedia.org/wiki/Lenguaje_de_definici%C3%B3n_de_datos|DDL]]((lenguaje de base de datos o lenguaje de definición de datos (Data Definition Language, DDL por sus siglas en inglés))) o instrucciones [[https://es.wikipedia.org/wiki/Lenguaje_de_manipulaci%C3%B3n_de_datos|DML]]((Lenguaje de Manipulación de Datos (Data Manipulation Language, DML))) que serán aplicadas como solución en el modelo entidad relación de **SICOF ERP**, para soportar nuevos desarrollos, ajustes, mejoras o solicitudes.
  * **Script de Reversión**: Son los scripts que contienen instrucciones [[https://es.wikipedia.org/wiki/Lenguaje_de_definici%C3%B3n_de_datos|DDL]]((lenguaje de base de datos o lenguaje de definición de datos (Data Definition Language, DDL por sus siglas en inglés))) o instrucciones [[https://es.wikipedia.org/wiki/Lenguaje_de_manipulaci%C3%B3n_de_datos|DML]]((Lenguaje de Manipulación de Datos (Data Manipulation Language, DML))) que serán aplicadas devolver el estado anterior del modelo entidad relación de **SICOF ERP**.
  * **Funcionalidad Propietaria**:Se identifican como aquellos procesos un opciones que son utilizadas directamente por un usuario de **SICOF ERP**. 
  * **Archivo Leeme.txt**: Es un archivo interno que debe estar en el directorio raíz de cada Funcionalidad Propietaria. Este archivo es de obligatorio registro y gestión por cada cambio realizado y debe contener por cada actualziación la lista ordena y secuencial de los scripts que integran la actualización además las reglas u observaciones a tener en cuenta.

===== Proceso de Nombramiento de Scripts =====
A continuación se describe el proceso de nombramiento de scripts

==== Síntesis ====
Asumiendo la siguiente Url genérica http://adacsc.co:1443/svn/repository/ADA/SICOF/ScriptsDB/SICOFERP/ se presentan los siguientes ejemplos:

* branches/Versión 1.0/00000000 FUNCIONALIDAD PROPIETARIA/1001 CREATE TABLE ESQUEMA.MAE_PRUEBAS.sql
  * branches/Versión 1.0/00000000 FUNCIONALIDAD PROPIETARIA/Revert/1001 CREATE TABLE ESQUEMA.MAE_PRUEBAS REVERT.sql
  * branches/Versión 1.0/00000000 FUNCIONALIDAD PROPIETARIA/1001a ALTER TABLE ESQUEMAMAE_PRUEBAS.sql
  * branches/Versión 1.0/00000000 FUNCIONALIDAD PROPIETARIA/1002 CREATE OR REPLACE FORCE VIEW ESQUEMA.V_PRUEBAS.sql
  * branches/Versión 1.0/00000000 FUNCIONALIDAD PROPIETARIA/1003a CREATE OR REPLACE PACKAGE ESQUEMA.PCK_PRUEBAS SPEC.sql
  * branches/Versión 1.0/00000000 FUNCIONALIDAD PROPIETARIA/1003b CREATE OR REPLACE PACKAGE ESQUEMA.PCK_PRUEBAS BODY.sql

A lo largo de la sección se definira cada fragmento del nombramiento de scripts

==== Almacenamiento ====
Según el [[ada:howto:sicoferp:factory:sicoferpscriptsdb:process:flujoregistersvn|Flujo de Registro]] los scripts deben almacenarse según la siguiente sección [[ada:howto:sicoferp:factory:sicoferpscriptsdb:process:repositorysvn#Estructura|Repositorio SVN]]

==== Versionamiento ====
Toda [[#Conceptos Previos|Funcionalidad Propietaria]] debe estar versiona empezando con **Versión 1.0**. a Continuación se definen los siguientes lineamientos:
  * La evolución de las versiones serán responsabilidad del lider técnico que soporte la funcionalidad.
  * Cada versión debe tener su respectivo archivo Leeme.txt y su directorio Revert

==== Extensión ====
Se deben utilizar las extenciones registradas en la sección [[ada:howto:sicoferp:factory:sicoferpscriptsdb:process:standardandpref#PL/SQL|Estandares y Prefijos PL/SQL Extensiones de archivos]]

==== Agrupación ====
Cada script debe agruparse de acuerdo a la [[#Conceptos Previos|Funcionalidad Propietaria]] y estar contenido en el directorio raíz de la funcionalidad.

==== Numeración Externa ====
Cada directorio que represente una [[#Conceptos Previos|Funcionalidad Propietaria]] debe iniciar con una numeración de 8 dígitos, ser secuencial e iniciar a partir de 10000000.

Ejemplo:
<code sql>
00000000 FUNCIONALIDAD PROPIETARIA
</code>

=== Nota ===
La numeración [00000000 - 09999999] está reservada para scripts de procesos internos y no debe ser utilizada para registrar scripts de lógica del negocio.

==== Numeración Interna ====
Cada directorio que represente una [[#Conceptos Previos|Funcionalidad Propietaria]] deberá contener scripts de evolución de la funcionalidad, estos también deben estar numerados con 4 dígitos de forma secuencial y deben iniciar a partir de 1000.

Ejemplo:
<code sql>
1001 CREATE TABLE ESQUEMA.MAE_PRUEBAS.sql
</code>

=== Nota ===
La numeración [0000 - 0999] está reservada para scripts de procesos internos y no debe ser utilizada para registrar scripts de lógica del negocio.

==== Independencia / Segregación por Objeto ====
Los scripts deben ser generados por objetos, no se deben agrupar.

==== Nombramiento por Sentencia ====
Cada script debe registrar en su nombre la sentencia general que describirá y debe estar en mayúsculas.

Ejemplo:
<code sql>
1001 CREATE TABLE ESQUEMA.MAE_PRUEBAS.sql
1002 CREATE OR REPLACE FORCE VIEW ESQUEMA.V_PRUEBAS.sql
</code>

==== Evolución de Scripts ====
Según el tipo de objeto se pueden presentar los siguientes tipos de evoluciones de scripts:

=== Evolución por sustitución ===
Este tipo de cambios modifican el script inicial. No es necesario crear un nuevo script ya que el control de versiones permitirá la gestión de cambios. Aplica para los siguientes tipos de objetos:

* FUNCTION
  * PROCEDURE
  * PACKAGE
  * TRIGGERS
  * VIEW
  * MATERIALIZED VIEW
  * TYPES
  * Cualquier instrucción que permite el comando CREATE OR REPLACE

Ejemplo:
<code sql>
1002 CREATE OR REPLACE FORCE VIEW ESQUEMA.V_PRUEBAS.sql
</code>

**Nota**
Todos los objetos que en su definición tengan especificación y cuerpo deben registrarse en archivos separados de la siguiente manera:

* Crear un script para la especificación y otro para el cuerpo o definición
  * Deben tener la misma numeración
  * La especificación debe tener la letra (a) después de la numeración y deben terminar con la palabra SPEC
  * El cuerpo o definición debe tener la letra (b) después de la numeración y deben terminar con la palabra BODY
  * Aplica para PACKAGE, TYPES

Ejemplo:
<code sql>
1003a CREATE OR REPLACE PACKAGE ESQUEMA.PCK_PRUEBAS SPEC.sql
1003b CREATE OR REPLACE PACKAGE ESQUEMA.PCK_PRUEBAS BODY.sql
</code>

=== Evolución por estado ===
Este tipo de cambios se anexan al script inicial por medio de otro script. No es posible modificar el archivo inicial porque los objetos no permiten la instrucción CREATE OR REPLACE. Aplica para los objetos:

* TABLE
  * ALTER TABLE
  * Scripts DML (Insert, Delete, Update)

Los scripts de evolución por estado deben ser nombrados por el mismo nombre del script original pero la numeración debe estar acompañada de letras en minusculas (al final de la numeración) de la [a-z] en caso de alcanzar el limite se procederá con las combianciones [aa-az] y asi sucesivamente.

Ejemplos:
<code sql>
1002 CREATE TABLE PRESUP01.MAE_PRUEBAS.sql
1002a ALTER TABLE PRESUP01.MAE_PRUEBAS.sql
1002b ALTER TABLE PRESUP01.MAE_PRUEBAS.sql
1002c ALTER TABLE PRESUP01.MAE_PRUEBAS.sql
</code>

==== Reversión de Scripts ====
Cada [[#Conceptos Previos|Funcionalidad Propietaria]] contiene un directorio llamado **Revert** el cual almacenará los scripts de reversión. A continuación se dictan los lineaminetos para crearlos:

* El nombre del [[#Conceptos Previos|Script de Reversión]] debe ser el mismo del script de actualización y debe finalizar con la palabra REVERT
  * El [[#Conceptos Previos|Script de Reversión]] deberá devolver el estado anterior del objeto modificado por el [[#Conceptos Previos|Script de Actualización]], esta situación puede tener algunas excepciones con sentencias DML en los casos donde se afecten secuencias o disparadores concatenados
  * En las sentencias DML los [[#Conceptos Previos|Script de Reversión]] deben considerar cargas previas a una modificación.

Ejemplos:
<code sql>
Script de Actualización: 1001 CREATE TABLE ESQUEMA.MAE_PRUEBAS.sql
Script de Reversión: 1001 CREATE TABLE ESQUEMA.MAE_PRUEBAS REVERT.sql
</code>

==== Personalizaciones / Clientes ====
En algunas situaciónes algunos procesos tienen particularidades entre clientes. En estas situaciones la [[#Conceptos Previos|Funcionalidad Propietaria]] tendra en sus versiones el código estandar que aplica a todos los clientes y la particularidades deben registrarse en un directorio interno con las siguientes condiciones:

* Debe empezar con la descripción //ConfigCliente// seguido del nombre del cliente Ej: **ConfigClienteADA**
  * Debe contener internamente su respectivo archivo **Leeme.txt** 
  * Debe contener internamente su directorio **Revert**
  * Desde el archivo Leeme.txt de la [[#Conceptos Previos|Funcionalidad Propietaria]] se debe orquestar la ejecución del directorio de personalización según la actualización que aplique.

[[ada:howto:sicoferp:factory:sicoferpscriptsdb:process|←Volver atrás]]

Resumen de la edición

Wiki

Herramientas de usuario

Herramientas del sitio

Herramientas de la página