Procedimientos para la Ejecución de Proyectos Internos (A Nivel de Kernel) por parte del Equipo de Proyectos

Para la realización de los Proyectos Internos (A Nivel de Kernel) por parte del Equipo de Proyectos se contará con un ambiente de desarrollo en el servidor Hostik2 (usando PHP5). En dicho ambiente de desarrollo, estarán instaladas las copias más recientes de las dos versiones de laboratorio de Net2Client, es decir, una copia tanto de /n2c como de /nxt, así como también una aplicación net2client de prueba, una copia de la 701 y un sitio WIB de prueba.

Las urls de los distintos ambientes de desarrollo son las siguientes:

701: http://kernel.netoclient.com/n2c/index.htm?gwt100701
Sitio Prueba WIB: http://kernel.netoclient.com/n2c/index.htm?gwt108103
CRM de Prueba: http://kernel.netoclient.com/n2c/index.htm?gwt109518
Setup: http://kernel.netoclient.com/n2c/setup/administracion.htm

NOTA: Para el desarrollo en el directorio /nxt se usan las mismas urls, sólo cambia /n2c por /nxt.

Definición y asignación de Proyectos:

  • El grupo de Kernel y la Gerencia de GWT definirá los proyectos y las actividades asociadas, que se llevarán a cabo en esta área.
  • La distribución de los proyectos y las tareas, se ejecutará por la Gerencia de GWT  de acuerdo a la disponibilidad de los mismos.
  • Estas tareas serán ejecutadas en el tiempo NO Vendido de los recursos, a menos que se le indique otra cosa.

Procedimiento a seguir por los ejecutores de los proyectos:

Se estableció el siguiente procedimiento para ser seguido por los ejecutores de los proyectos.

1. Informar al  grupo de kernel siempre que se inicie, retome o finalice una tarea.
2. Registrar en la tabla TRANSICIONES (aplicación 701) la información relacionada con la  tarea para el control de las versiones de los programas de kernel.
 La información  a llenar en esta tabla es la siguiente:

  • Código de la Actividad (Actividad-Plan) correspondiente.
  • Programa a Modificar.
  • Fecha Fin Plan.
  • Duración Estimada en Horas.
  • Responsable.
  • Status (Con el valor: En Proceso)
  • Directorio /n2c [Si el cambio se hará en este directorio]
  • Directorio /nxt [Si el cambio se hará en este directorio]

3. Descargar del servidor el programa a modificar tanto la versión que está en /n2c como la de /nxt y guardarlas en su máquina como respaldo. El ejecutor será responsable de siempre mantener un respaldo en su máquina de los archivos originales (como los descargó del servidor) sin cambios. De igual forma debe dejar una copia del programa original (sin modificar) en el servidor, con el siguiente nombre: nombreprograma_FECHA_T.ext, dónde nombreprograma es el nombre original del programa, FECHA es la fecha de inicio de la transición (correspondiente al registro en TRANSICIONES), T el código de la transición y ext la extensión del programa (.php, .htm, .js).

4. Desarrollar y documentar  la solución asignada. El programa debe estar documentado con el Estándar manejado por Kernel.

Estándar de Documentación de programas:
  
  /* Modif EC 2008-04-01 Ref. T-XXXX - Explicación del cambio correspondiente*/
 
Donde EC son las iniciales del ejecutor de la tarea y XXXX el número de la transición correspondiente.

.Se recomienda copiar este texto, pegarlo y modificarlo para evitar inconsistencias.

5. Si existen cambios en la estructura de base de datos. Documentar estos insertando un registro en  la tabla TRANS-BD llenando los siguiente campos:

  • Tabla. 
  • Tipo de cambio.
  • Valor Antes Cambio.
  • Valor Después Cambio.
  • Explicación del Cambio.
  • Fecha del Cambio. 
  • Actividad

6. Esperar aprobación de Kernel a través de la certificación de las pruebas.
Una vez realizadas las pruebas, el equipo kernel dará la aprobación para cambiar el status de la transición a “Por Migrar a Producción”. El Equipo Kernel evaluará el momento indicado para pasar el archivo modificado al ambiente de producción de kernel (tanto de /n2c como /nxt). Una vez pasado a producción, el estatus de la transición  quedaría como “Finalizada”.

 7. Informar al equipo de kernel.

Casos Especiales

Caso 1 – Tarea Inconclusa

Si el ejecutor, debe dejar la tarea inconclusa debido a que tiene que cumplir con sus obligaciones con los proyectos externos, debe informar al equipo kernel que la asignación está pendiente para tomar decisiones al respecto sobre la versión del archivo que se dejará operativa en el servidor. De igual forma, debe actualizar en la tabla de TRANSICIONES el campo Status, colocando el valor en “Pendiente”. Una vez cumplida las obligaciones con su proyecto externo se procederá a  retomar la tarea asignada, para esto, el ejecutor debe nuevamente notificar al equipo Kernel que retomará la tarea y realizar el cambio del status de la transición “En Proceso”.

Caso 2 – Tarea Finalizada

Una vez culminada la tarea, se debe notificar al equipo kernel la finalización del trabajo para proceder a realizar las pruebas. También el ejecutor debe actualizar el registro correspondiente en TRANSICIONES colocando el status “En Pruebas”, de igual forma debe llenar los campos Fecha Fin, Funciones php usadas, y Explicación del Cambio, en este último, se debe incluir la explicación técnica del cambio realizado en el programa correspondiente.

Caso 3 – Kernel requiere modificar programas

Si en determinado momento, el equipo kernel debe hacer alguna modificación a algún programa en el ambiente de producción de kernel (/n2c o /nxt) bien sea por una mejora o por la resolución de un ticket, este debe replicar estos cambios en los ambientes de desarrollo de los proyectos internos. Si alguno de los programas a ser replicados están “en transición”, es decir, están siendo modificados por alguien del equipo de Proyectos, el equipo Kernel debe notificar al ejecutor de dicha transición sobre el cambio para que este lo incorpore en su versión del archivo o si no impacta mucho simplemente lo sustituya por el nuevo.