Tag Archives: desarrollo

Separación de poderes (Parte 1)

En 1748, Montesquieu en “El espíritu de las leyes” establecía la separación de poderes en el estado (legislativo, ejecutivo y judicial) como método de control del desgobierno.

En la gestion de cambios, el proceso de desarrollo o mantenimiento de uno o múltiples productos en el tiempo, este concepto es básico y a partir de él, definiremos la estrategia.

Los actores son 3 ( 4 si el proceso de auditoría lo lleva otro dpto.):

  • Desarrollo
  • Infraestructuras
  • Operación

Desarrollo controla el código fuente de las aplicaciones y los entornos de desarrollo. No tiene acceso físico a los entornos de test ni producción (dejare para otro día que separa unos de otros) .

Infraestructuras (o Sistemas o Arquitectura o …) tiene control de los entornos de test y producción. Su función es mantener el chiringuito funcionando llueva o nieve. CYA, desarrollo puede hacerte la vida muy difícil, jugar todos con las mismas reglas escritas e inmutables es tu primera linea de defensa.

Operación gestiona los pasos o promociones entre entornos, son los encargados de instalar las aplicaciones u operar sobre ellas. No tienen acceso ni al codigo fuente ni a las maquinas fisicas. Trabajan con aplicaciones (ya hablaremos de ellas otro dia) como Quickbuild o Jenkins montadas por sistemas y son la unica forma legal de instalar una aplicacion en un entorno.

En general operación no tiene mucha libertad (y tampoco se busca) se trabaja con manuales o procedimientos y no se salen de ellos. Si un manual no existe tampoco existe la posibilidad de que lo hagan. A veces pueden controlar el acceso de Sistemas a las propias maquinas mediante herramientas de asignación de usuarios temporales y ventanas de tiempo con permisos.

Este blog tiene el punto de vista del área de sistemas, otras áreas tendrán su perspectiva que seguramente no sea la misma pero tampoco muchas veces están sujetos a las mismas responsabilidades: si una aplicación cae sistemas es quien se da cuenta (o debería, enterarse por el usuario es un no-no, primera y principal causa de mal rollo entre negocio e IT). Quizá haya empresas en las que desarrollo (quien siempre tiene acceso a los logs) se hace responsable (es su aplicación, la conoce, la ha programado) analiza la causa y pone remedio… mi experiencia es que los logs ni se miran, a desarrollo hay que perseguirlo porque “no es crítico para negocio”, la prueba de demostrar esa criticidad corre por parte de sistemas, hay que mantener un SLA pero hay cambios en producción cada 3 dias, etc.

No hay balas de plata o soluciones técnicas  a problemas no técnicos, técnicamente un marco estable de trabajo es el minimo para trabajar, la parte 2 tratará de porque hace falta esta separación y a que peligros se enfrenta y porque. El siguiente tema sera la inmutabilidad del código fuente de una aplicación.