Entornos de Ejecución del Software bajo DevSecOps

Introducción

Contexto

Desde la Oficina Técnica de Impulso DevSecOps de la Dirección General de Estrategia Digital -en adelante DGED-, de la Agencia Digital de Andalucía –en adelante ADA-  y con la colaboración y participación activa del Servicio de Explotación de Sistemas Corporativos, en adelante SESC, también dependiente de dicha Dirección General, se impulsa el Proceso de transición a DevSecOps.

DevSecOps supone un cambio en el modo en el que se gestiona el ciclo de desarrollo de software, a nivel tecnológico pero sobre todo a nivel cultural, garantizando procesos mucho más rápidos y seguros, entregas más fiables y productos de calidad.

El objetivo del "Proceso de transición a DevSecOps" aplicado en el ámbito de un Sistema de Información es crear el contexto adecuado, proporcionando los recursos (herramientas, procedimientos y técnicas...) que permitan que el desarrollo y operación del mismo se lleve a cabo conforme a las normas y buenas prácticas de la Organización.

Para lograr ese objetivo, se implantarán progresivamente procedimientos, normas y buenas prácticas de colaboración, en su mayoría basadas en prácticas ágiles. Esto requiere, para nuestra organización, la redefinición y evolución de una serie de prácticas, normas y convenciones que rigen la forma de trabajar de los distintos equipos que participan en el desarrollo y operación del software y, por tanto, la prestación de los servicios a los que contribuyen.

El presente documento forma parte de la definición de prácticas, normas y convenciones necesarias para la transición hacia prácticas DevSecOps en la DGED. Asimismo estas prácticas y normas serán de aplicación al Modelo Operativo DevSecOps desarrollado en la ADA para la implantación de los sistemas de información en la Plataforma Pre-Cloud.

Objeto

El objeto del presente documento es definir los distintos entornos de tránsito del software durante su ciclo de vida, desde la entrega temprana para su integración continua hasta el despliegue final en producción. 

Alcance

Desde el punto de vista organizativo, el alcance del documento es la ADA y todos los sistemas dentro de su ámbito que participen en el Proceso de transición a DevSecOps y adquieran el Modelo Operativo DevSecOps como modelo de operación. No está incluido en el alcance del documento definir cuándo un sistema está en el Proceso de transición a DevSecOps.

Desde la óptica del ciclo de vida del software, el alcance del documento abarca los entornos destinados tanto a la integración y pruebas, entornos expuestos a un mayor grado de cambio e inestabilidad, como los entornos de formación, preproducción y producción, entornos más estáticos y con menor tasa de cambios, al menos hasta que la agilidad del ciclo de integración continua pueda trasladarse al ciclo de despliegue continuo, lo que permitirá llevar a cabo esa alta tasa de cambio a todos los entornos, incluidos los productivos, sin riesgo para el negocio.

No se ha incluido expresamente la existencia de un entorno de certificación (entorno exclusivo y aislado en el que certificar el software), si bien pueden ser definido e incluido en futuras iteraciones del presente documento.

En cuanto a la perspectiva tecnológica, el ámbito del documento será el de los sistemas vinculados a DevSecOps independientemente de la plataforma de ejecución en la que se desplieguen puesto que en nuestro proceso se ha priorizado la migración tecnológica que apoye el modelo basado en la nube. Están fuera del alcance de este documento los entornos de desarrollo, por lo que los casos de uso propios de esta actividad (la de desarrollo) no estarán cubiertos.

Términos y acrónimos

Los términos y acrónimos utilizados en este documento han sido definidos en el Modelo Operativo DevSecOps.

Entornos

Para facilitar la comprensión de la definición de los entornos, se presentará la siguiente información:

• Definición de entornos: Identificación de los entornos de ejecución contemplados así como sus usos principales y secundarios.
• Resumen de usos vs entornos: Tabla resumen de usos contemplados en cada entorno.

Definición de entornos

CI - Integración Continua

Entorno de Integración Continua, principalmente utilizado por el Equipo de Desarrollo.

Requisitos

Se solicitará la creación  de este entorno si se presentan alguna de las siguientes situaciones:

• Las pruebas de integración con otros sistemas no se puedan realizar en el entorno de desarrollo por motivos técnicos.
• La realización de las pruebas de integración en el entorno de TEST pueda interferir con las pruebas de usuario.
• De forma temporal, mientras existan impedimentos en la creación del entorno de TEST.

Uso principal

• Pruebas de integración con otros Sistemas: Las integraciones, en el caso de existir, deberán ser con sistemas o servicios ya existentes en el entorno de INT o PRE en su defecto. En caso de no ser posible lo anterior, se podría realizar con sistemas simulados (mockeados) o con otros entornos diferentes a producción.
  No confundir con el entorno de INT, en el que el sistema ofrece sus servicios estables para la integración de terceros.
• El entorno de CI no es un entorno de desarrollo, por lo que es necesaria la existencia del entorno de desarrollo del proveedor.

Otros usos

• Pruebas de despliegue: Cuando exista, este entorno será utilizado para realizar las pruebas de despliegue, utilizando los artefactos generados y los automatismos definidos para ello. De no existir, será el entorno de TEST el que asumirá este uso.
• Pruebas funcionales: Cuando exista, este entorno será utilizado para la realización de pruebas funcionales por parte del Equipo de Desarrollo. De no existir, será el entorno de TEST el que asumirá este uso.

TEST

Entorno principalmente utilizado por el Equipo de Desarrollo.

Uso principal

• Validación de la infraestructura: Entorno utilizado para definir o validar la infraestructura a utilizar por el sistema de información. 
  Se tenderá a la utilización del  paradigma Infraestructura como código (IaC), en los elementos que se desplegarán sobre las plataformas quedando todos los ficheros de configuración necesarios en el repositorio de código. Dichos ficheros deben  permitir la automatización del aprovisionamiento completo del sistema de información.

Otros usos

• Pruebas de despliegue: Este entorno será utilizado para realizar las pruebas de despliegue, utilizando los artefactos generados y los automatismos definidos para ello.

• Pruebas de integración con otros Sistemas: Pruebas de integración con otros sistemas, especialmente cuando estas no ha sido posible realizarlas en los entornos de desarrollo por motivos técnicos. Las integraciones, en el caso de existir, deberán ser con sistemas o servicios ya existentes en entorno de INT o PRE en su defecto. En caso de no ser posible lo anterior, se podría realizar con sistemas simulados (mockeados) o con otros entornos diferentes a producción. 

  Las pruebas de integración con otros sistemas se realizarán en el entorno CI cuando no sea posible cubrir la necesidad en el entorno de TEST.  Es motivo de diferenciación  de los entornos de CI y TEST,  sin limitarse a este, la imposibilidad técnica temporal o permanente de implementar las integraciones en el entorno de desarrollo, cuando la realización de pruebas de integración con otros sistemas pueda interferir las pruebas de usuario.

• Pruebas funcionales: Este entorno será utilizado para la realización de pruebas funcionales por parte del Equipo de Desarrollo, proyecto o interesados, en un entorno de similares características al que será utilizado en entornos posteriores.
• Presentación de nuevas funcionalidades: Presentación a interesados de nuevas funcionalidades o versiones.
• Certificación de la calidad: Salvo excepciones y casos específicos, en este entorno se realizarán las pruebas de certificación del software por parte de la Oficina de Calidad.

INT - Integración

Entorno de Integración, principalmente utilizado por equipos de desarrollo de terceros sistemas de información. 

Es un entorno más estable que el entorno de TEST, se recomienda que tenga asociado un canal de comunicación ágil con los integradores que facilite la comunicación, en particular para hacer referencia a cambios de versión, paradas por mantenimiento y otra información relevante.

Requisitos

Se solicitará la creación  de este entorno si se presentan alguna de las siguientes situaciones:

• Cuando sea necesaria probar la integración con terceros sistemas, pruebas con versiones concretas del software o necesidades especiales en el tratamiento de datos.

Uso principal

• Integración de sistemas: Se usará principalmente para dar soporte a terceros sistemas que necesiten integrarse con el Sistema de Información.

  Este entorno estará cubierto por preproducción (PRE) salvo que por necesidades especiales sea necesaria la existencia de un entorno independiente, como por ejemplo la necesidad anticipada de probar las integraciones con versiones concretas del software, o necesidades especiales en el tratamiento de los datos.

  Debe disponer de la versión que va a ir próximamente a producción con antelación suficiente para que los integradores puedan probarla antes de que se despliegue en producción. En este sentido, puede ocasionar algún conflicto si se utilizase el entorno de PRE para ello, por lo que la frecuencia con lo que esto ocurra será determinante para decidir si necesita un entorno independiente.

PRE - Preproducción

Entorno de Preproducción, último entorno donde detectar posibles problemas antes del paso a producción. Este entorno tendrá una arquitectura y configuración equivalente al entorno de PRO.

Uso principal

• Validación del despliegue en PRO: El objetivo principal de este entorno será, principalmente, la correcta validación del proceso de puesta en producción, con el fin de comprobar y asegurar que no se produzcan errores en dicho proceso. 

  Dicho entorno deberá ser idéntico  al entorno productivo en cuanto a arquitectura, llegando si es necesario a compartir los mismos datos  (mediante replica de los diferentes almacenes de datos antes del proceso de actualización) y visibilidades o reglas de acceso

  El proceso de replicación de datos deberá ser definido por el Equipo de Desarrollo con la periodicidad y volumetría requerida por el ciclo de vida de cada sistema de información. Cualquier cambio mayor de un sistema de información requerirá que el conjunto de datos sea actualizado.

Otros usos

• Realización de pruebas de aceptación: Pruebas de aceptación por parte del Equipo de Desarrollo / usuarios expertos sobre la versión que se quiera implantar en producción con datos similares a los que existen en producción.
• Hacer otro tipo de pruebas que requieran una infraestructura similar a la del entorno de PRO, como las de rendimiento. 

PRO - Producción

Entorno de Producción.

Uso principal

• Entorno donde finalmente se ejecuta la aplicación de cara al usuario final y donde se trabaja con los datos de negocio.

FOR - Formación

Entorno de Formación, para la formación y divulgación relativa al sistema.

Uso principal

• Acceso al sistema para actividades de formación: El objetivo principal de este entorno es el de poder mostrar y usar el sistema de información en jornadas de formación. El entorno tiene que estar activo a demanda, es decir, solo cuando se vayan a impartir estas jornadas de formación. Las características no tienen que ser iguales que en los entornos de PRE o PRO ya que solo lo usarán un número limitado de personas y durante un periodo limitado de tiempo.

Creación y disponibilidad de entornos

El Equipo de Desarrollo deberá realizar una propuesta sobre la disponibilidad necesaria de los diferentes entornos que se consensuará con el Equipo de Operaciones.

En los entornos no productivos, se deberá priorizar la creación de infraestructuras volátiles mediante el uso de definiciones de infraestructura como código de manera que dichas infraestructuras puedan ser creadas a demanda y destruidas tras su uso.

La propuesta realizada deberá basarse en los principios de ahorro de costes en cuanto al consumo de recursos (energéticos, proceso , memoria y capacidad de datos).

Resumen de usos vs entornos

Con el fin de facilitar la visión completa de usos contemplados en cada entorno, se presenta a continuación una tabla resumen de Usos vs Entornos.

Casos de uso	CI1/TEST		INT2/PRE		PRO	FOR3
Construcción y empaquetado		Sí
Validaciones estáticas de código		Sí
Pruebas automatizadas Unitarias		Sí
Pruebas automatizadas API	Opcional4	Sí
Pruebas automatizadas E2E	Opcional4	Sí
Certificación del software		Sí	Opcional	Opcional	Opcional
Pruebas de Carga			Sí	Sí
Pruebas funcionales (del Equipo de Desarrollo, usuarios expertos, etc.)	Opcional4	Sí
Pruebas de integración desde otros sistemas		Opcional	Sí	Sí
Validación del despliegue en PRO				Sí
Pruebas de aceptación previas al despliegue en PRO				Sí
Operación del sistema					Sí
Pruebas de humo					Sí
Formación a usuarios						Sí

¹Entorno opcional, si puede cubrirse con TEST.
²Entorno opcional, se puede utilizar en el entorno de PRE.
³Entorno opcional, solo si se requiere su uso.
⁴Solo para versiones, a decisión del Equipo de Desarrollo.

	Oficina de Calidad
	Equipo de Desarrollo
	Equipo de Operaciones

Las capacidades del entorno de INT serán asumidas por el de PRE, salvo que sea necesario por necesidades especiales en la gestión de las versiones del software (el software no pueda ser el mismo que en PRE) o porque las necesidades de copias de datos lo hagan necesario.

En ocasiones, se puede necesitar un entorno para la certificación de entregas que requiera una copia frecuente de la información de la base de datos, y que no pueda ser realizado en el entorno de PRE. Este caso se tratará como un caso especial y se someterá a estudio, siendo la opción preferida cubrir esta necesidad con otro entorno.

Anexo I: Requisitos y Restricciones

Se detallan los requisitos y restricciones que se han tenido en consideración al definir los entornos, junto a un resumen de cómo los entornos definidos satisfacen dichos requisitos y restricciones.

Requisitos

Para la definición de los entornos se han tenido en cuenta una serie de requisitos aportados por los interesados de las distintas áreas involucradas en el ciclo de vida de las aplicaciones.

REQ1: Debe existir un entorno de Integración Continua, en adelante CI, en el que realizar con alta frecuencia tareas de construcción, empaquetado, pruebas estáticas y pruebas dinámicas e, incluso, despliegues automatizados.

REQ2: Adoptar progresivamente el paradigma de Infraestructura como Código (IaC), facilitando la automatización del proceso de creación de entornos y despliegue del software.

El objetivo final será avanzar hacia patrones de infraestructura inmutable, esto significa que, una vez creada la instancia, esta no será modificada. Si se requiere algún cambio sobre la infraestructura, la instancia se recreará por completo.

REQ3: Disponer de entornos en los cuales se expongan de forma estable y con datos de pruebas válidos los servicios de integración necesarios para el correcto despliegue de las distintas aplicaciones.

REQ4: Disponer de un entorno de Formación donde los usuarios puedan instruirse en el uso de las distintas versiones, versiones en producción o versiones de próxima liberación. 

REQ5: Disponer de un entorno de Preproducción en el que poder replicar con la máxima fidelidad los despliegues, y realizar pruebas y certificaciones de software que deban repetirse o no se hayan podido realizar en otros entornos.

Este documento debe cubrir los requisitos y necesidades mencionados anteriormente.

Restricciones

En base a los requisitos expuestos se adoptan restricciones tanto en materia de seguridad como en materia de racionalización y sostenibilidad económica, debido esta última a la alta inversión que requeriría satisfacer todas las necesidades de entornos por aplicación.

Por tanto, se acuerda:

• Minimizar el número de entornos necesarios. Aunque podrán existir entornos opcionales, si la necesidad no puede ser cubierta por otro entorno.
• Disociar u ofuscar los datos personales utilizados en los entornos de Formación.
• Disociar u ofuscar los datos personales utilizados en los entornos externos a la ADA.

No es el objetivo de este contenido definir el procedimiento de ofuscación o disociación. El Equipo de Desarrollo es responsable de su definición tras analizar los riesgos, aportando el procedimiento, manual o automático, definido al Equipo de Operaciones.

Las solicitudes de entornos que no se ajusten a las restricciones especificadas serán estudiadas de forma individualizada, remitiéndose, en primera instancia, a la Oficina de Calidad para dicho estudio.

Cobertura de los requisitos

La siguiente tabla resumen muestra cómo se ha dado respuesta a los requisitos planteados.

Requisito	Solución
REQ1: Debe existir un entorno de Integración Continua, en adelante CI, en el que realizar con alta frecuencia tareas de construcción, empaquetado, pruebas estáticas y pruebas dinámicas e, incluso, despliegues automatizados.	Buscando un equilibrio entre este requisito y la restricción que persigue minimizar el número de entornos, se llega a la siguiente definición: La Plataforma CI/CD se configurará para la compilación, empaquetado y análisis estático del código subido al repositorio. El despliegue automático se realizará solo cuando sea necesario y lo decida el Equipo de Desarrollo, en el entorno de TEST. Solo cuando existan impedimentos técnicos y  dificultades para simultanear las pruebas de usuario en TEST con las pruebas de desarrollo de integraciones, se creará un nuevo entorno de CI, mientras existan las dificultades.
REQ2: Adoptar el paradigma de Infraestructura como Código (IaC), facilitando la automatización del proceso de creación de entornos y despliegue del software.	Se cubre con el uso de la plataforma de ejecución basada en contenedores. Y de manera progresiva en la plataforma de ejecución de máquinas virtuales.
REQ3: Disponer de entornos en los cuales se expongan de forma estable y con datos de pruebas válidos los servicios de integración necesarios para el correcto despliegue de las distintas aplicaciones.	Esta función queda cubierta por PREPRODUCCIÓN, salvo que, por necesidades especiales, se requiera un entorno de INT independiente.
REQ4: Disponer de un entorno de Formación donde los usuarios puedan instruirse en el uso de las distintas versiones, versiones en producción o versiones de próxima liberación.	Se define, como opcional, un entorno de FOR.
REQ5: Disponer de un entorno de Preproducción en el que poder replicar con la máxima fidelidad los despliegues, y realizar pruebas y certificaciones de software que deban repetirse o no se hayan podido realizar en otros entornos.	Se define un entorno de PRE, complementario a PRO.