Acelerar la entrega de software con una efectiva gestión de cambios

El valor en el software se realiza solo cuando el producto final está en manos de los usuarios previstos. El desarrollo de software tradicional puede ser lento, y requiere múltiples revisiones y aprobaciones manuales, así como equipos de especialistas para realizar tareas específicas a medida que avanza el proyecto de software. Para aumentar la velocidad con la que se crea y entrega el software, muchas organizaciones se están moviendo hacia la integración continua y la implementación continua (CICD), aprovechando el flujo de trabajo automatizado y los pequeños equipos responsables de gestionar un cambio de principio a fin.

Tradicionalmente, los auditores se han basado en revisiones, aprobaciones y segregación de tareas (SoD) para probar que las versiones de software cumplen con las expectativas de la gerencia sobre el producto. Se necesita un proceso de CICD que satisfaga tanto la necesidad de acelerar la entrega de software como los requisitos de los auditores para prácticas de gestión de cambio eficientes y efectivas.

Fundamentos de la gestión del cambio

La Biblioteca de Infraestructura de Tecnología de la Información (ITIL) define el cambio como “la adición, modificación o eliminación de cualquier cosa que pueda tener un efecto en los servicios de TI”.¹ Pueden ocurrir cambios en las aplicaciones, componentes de infraestructura, documentación, configuraciones, políticas, reglas de acceso y cualquier otro elemento que comprenda un producto de software.

La administración de cambios subraya todo el desarrollo de software, lo que permite la capacidad de rastrear la intención de la administración de un producto a través de la entrega del software y los artefactos implementados. La gestión tradicional del cambio se realiza a través de revisiones, pruebas, aprobaciones y SoD. Cada acción a menudo requiere que el proceso se detenga y espere la acción manual, como una designación de aprobación, antes de pasar a la siguiente etapa del proceso. De los 10 subprocesos definidos por ITIL en su proceso de gestión de cambios,² ocho incorporan una pausa inherente en el proceso de evaluaciones y autorizaciones.

Definición de CICD

Los fundamentos de la gestión del cambio de ITIL son atemporales, pero los modelos modernos de desarrollo de software cambian la forma en que se aplican. Por ejemplo, en el CICD, los equipos de desarrollo de software y operaciones desarrollan e implementan cambios continuamente en una aplicación en pequeños incrementos en lugar de en versiones grandes e infrecuentes.

CICD combina dos elementos: integración continua (CI) y despliegue continuo (CD). En CI, los desarrolladores fusionan los cambios en un repositorio de código fuente central. Con cada cambio en el repositorio, la aplicación se reconstruye y se ejecutan conjuntos de pruebas automatizados contra la aplicación reconstruida (“la compilación”). Si un caso de prueba falla, el desarrollador puede investigar y resolver la falla rápidamente. Con la integración continua, el software está en funcionamiento en todo momento.³ En teoría, cada integración mejora la aplicación de forma incremental. El CD expande en el CI al tomar la salida de integración que cumple con los criterios de lanzamiento y actualizar la aplicación en producción con la integración del output. La implementación continua efectiva incluye la capacidad de abortar la implementación y/o revertir a la versión anterior de la aplicación si el resultado de la integración podría degradar la aplicación en vivo en la producción.⁴ El CD depende de la automatización para detectar el éxito o el fracaso de una integración a medida que avanza a través de las etapas de CICD. En un verdadero entorno de CD, no hay interrupción de la progresión de un entregable desde la integración hasta la implementación.⁵

Metas y beneficios de la CICD

El objetivo de CICD es entregar software valioso de alta calidad de manera eficiente, rápida y confiable.⁶ Aunque comúnmente se atribuye a la programación Agile y al primer principio del Manifiesto Agile,⁷ no hay un requisito para practicar Agile, o cualquier otra metodología de programación, para obtener los beneficios de CICD.

Un proceso CICD efectivo y de alto rendimiento brinda muchos beneficios, incluido un menor riesgo de liberación debido a entregas incrementales, comentarios frecuentes sobre la calidad del software, mayor confiabilidad a través de procesos de implementación automatizada y demoras reducidas debido a los hitos manuales.

Características de un entorno que cumple con la CICD

Un proceso de gestión de cambios que cumple es aquel en el que todos los cambios se ajustan al proceso documentado, y las excepciones son raras y aceptables para la administración. Las características comunes incluyen:

• Calidad—Todas las personas involucradas en los procesos de creación, prueba e implementación, y en todas las capas de la fuente, tienen un interés en la calidad del entregable y en garantizar que los errores, que crean reprocesos, se eviten en toda la empresa.
• Coherencia—Un entorno eficaz de la CICD incluye pautas para garantizar que las actividades se realicen de manera coherente y los efectos potenciales de los cambios en cualquiera y todos los componentes relevantes de la CICD se consideren durante la toma de decisiones.
• Pervasividad—Una vez establecido, el entorno de la CICD debe convertirse en el estándar único para implementar todos los artefactos relevantes, incluidos los entregables y la propia fuente de la CICD. Los artefactos incluyen, entre otros, software, documentación, procesos, configuraciones, scripts de ejecución, scripts de prueba, conjuntos de pruebas y credenciales utilizados para asegurar los entregables. Las rutas de implementación para fines especiales deben ser desalentadas, ya que pueden conducir a niveles variables de calidad e interoperabilidad.
• Escalabilidad—El CICD efectivo se basa en la eficiencia en todo el proceso y la pila de tecnología. Detenerse por una sola vez, las acciones personalizadas ralentizan la entrega y anulan el propósito de CICD.El entorno debe estar diseñado para cumplir con el uso previsto y la futura carga de trabajo e incluir la flexibilidad de la automatización para adaptarse a esa carga de trabajo.
• Confiabilidad y adecuación—La automatización es fundamental para CICD, especialmente cuando se trata de pruebas. Dado que no es práctico ejecutar todo el conjunto de pruebas contra cada cambio para cada paso de prueba en el proceso, debe haber una estrategia para realizar pruebas durante todo el proceso de CICD. Esto debe incluir la designación de objetivos específicos para cada etapa de prueba y la selección cuidadosa de pruebas que juntas resulten en pruebas sólidas y representativas a través de la via de entrega. Los datos de la prueba deben ser lo suficientemente completos para validar adecuadamente los entregables sin repeticiones y demoras innecesarias.

Gobernanza para la gestión del cambio de la CICD

La CICD sostenible se basa en una buena gobernanza de la gestión del cambio. Los equipos deben saber qué pueden esperar del CICD, así como qué se espera que hagan para usar el proceso. La gobernanza de la gestión del cambio de la CICD debería respetar estos principios:

• A qué sistemas, procesos y aspectos de una empresa aplica la CICD (aplicabilidad)
• Los procesos, fuentes, protocolos y otros componentes de CICD funcionan como se espera en todo momento (confiabilidad)
• Consistencia en el uso del proceso, canalización y protocolos de CICD, independientemente de qué aplicación o artefacto se esté procesando. Las desviaciones se documentan y los cambios se comunican a las partes interesadas con suficiente aviso para que las partes interesadas hagan los ajustes necesarios para garantizar que la coherencia permanezca intacta.

Además, el CICD debería incluir estas políticas:

• Documentación de cada cambio—Las políticas deben describir el uso aceptable de las herramientas de gestión de cambios, control de fuente y herramientas de flujo de trabajo de compilación ejecutable. Por ejemplo, se puede requerir que un ticket de cambio incluya información específica, como una descripción y el motivo del cambio y cualquier requisito reglamentario para tal cambio.⁸ Para fines de auditoría, se debe mantener la información sobre los contenidos de compilación, la creación, la progresión a través de la vía y la línea de tiempo de esa progresión, preferiblemente a través de la automatización o la configuración de las herramientas utilizadas para generar el entregable.Tanto para la auditoría como para la resolución de problemas, la documentación de los artefactos publicados debe proporcionar un registro de auditoría formal de la evidencia que demuestre las principales actividades que se producen a lo largo del proceso de cambio. Cada cambio debe documentar la razón del cambio, la forma en que se evaluó en cuanto a la efectividad operacional y de diseño, y cuándo se implementó en la producción.
• Documentación de los procesos de la CICD y criterios de aceptación—La documentación del proceso de la CICD debe ser clara y actual. Los criterios para permitir que un cambio progrese automáticamente de una etapa de la fuente de la CICD a la siguiente deben ser consistentes y documentados por escrito. Se deben anotar las excepciones a los criterios, junto con las instrucciones para documentar los requisitos de excepción (por ejemplo, aprobación de la gerencia, pruebas de compensación o expectativas de avance). Si la fuente puede configurarse para adaptarse a las necesidades específicas de los diferentes equipos, se deben usar los patrones de la fuente aprobados para garantizar que todos los componentes requeridos de una fuente de cumplimiento de CICD estén en su lugar.Los procedimientos de cambio de emergencia deben requerir que el equipo ejecute el cambio de manera retroactiva a través del proceso estándar de gestión de cambios y revise qué condujo a la emergencia para evitar que se repita.
• Control de acceso—Debido a que la automatización reemplaza muchos puntos de control tradicionales de “ojos extra”, la integridad de la fuente se convierte en un proxy para SoD. Debe haber una clara delimitación entre los equipos responsables de la fuente de infraestructura y los que la usan. La herramienta de control de fuente se puede configurar para segregar efectivamente las tareas a través del acceso (por ejemplo, solo los ingenieros que trabajan en la fuente de la infraestructura de CICD pueden realizar cambios en los componentes de infraestructura y/o configuraciones y patrones). Las excepciones deben ser raras, aprobadas, documentadas y monitoreadas mientras estén activas.
• Registro de auditoría de todas las aprobaciones y resultados de las pruebas—Las decisiones automatizadas tomadas por los sistemas de CICD, junto con los datos utilizados para tomar dichas decisiones, deben registrarse e, idealmente, documentarse automáticamente en el ticket de solicitud de cambio.
• Registro—Todas las acciones tomadas por los desarrolladores y otros participantes de CICD deben registrarse. No debe haber capacidad para anular los controles para ocultar eventos y acciones tomadas. El acceso a los registros de cambios debe estar restringido. Las actividades de registro deben diferenciarse entre fuentes de actividades (infraestructura), fuente de consumidores (desarrolladores) y componentes sistemáticos (creación de herramientas y herramientas de prueba). Además, se deben emitir alertas para cualquiera que pueda haber eludido el proceso establecido de CICD.
• Gestión de componentes de la CICD—Para obtener el máximo beneficio, el entorno de la CICD y sus componentes deben funcionar perfectamente en todo momento. Un inventario completo de todos los componentes (es decir, código, scripts, pruebas, criterios de desarrollo y prueba), junto con el uso, el propietario, las dependencias y las interfaces para cada componente, debe estar disponible, actualizarse y mantenerse bajo control de origen. Esta información puede reducir la cantidad de tiempo que se detiene la fuente debido a errores de configuración.
• Monitoreo de los criterios de aceptación en la fuente de CICD—La gerencia debe definir los criterios de aceptación, o umbrales, todos los cambios deben cumplir antes de pasar al siguiente paso en el proceso automatizado. La documentación correspondiente debe registrar cómo se determinó cada umbral, los pasos para el procesamiento de excepciones si no se cumplen los umbrales, las revisiones periódicas de todos los umbrales y las acciones y consecuencias por el incumplimiento. Para garantizar la aplicabilidad, confiabilidad y consistencia continuas de la fuente, las aplicaciones y el proceso de CICD a medida que evolucionan, los criterios de aceptación deben ser monitoreados y actualizados según sea necesario y la documentación actualizada para reflejar esos cambios.
• Monitoreo de la infraestructura—La infraestructura, incluida la fuente del CICD, debe someterse a pruebas de regresión periódicas, incluidas pruebas de vulnerabilidad de penetración o seguridad, según se considere apropiado. Debido a que los entornos desde el desarrollo hasta la producción están estrechamente integrados, cada entorno debería asegurarse como si la producción dependiera de él, porque, de hecho, la producción sí lo hace.

Controles para la gestión del cambio CICD

La gestión del cambio se ocupa de dos áreas principales de riesgo:

• Un cambio no autorizado o no aprobado se promueve al entorno de producción.
• Los cambios implementados no funcionan correctamente.

La figura 1 muestra los controles mínimos requeridos para la gestión del cambio en CICD, y la figura 2 enumera controles opcionales adicionales para su consideración. Implementar estos controles y conservar la evidencia de que se han implementado minimizará las áreas de riesgo y cumplirá con las expectativas del auditor.

Cumplimiento con la CICD es alcanzable

En la superficie, el CICD parece descuidar muchos de los elementos centrales en los que se basan los auditores para demostrar la gestión efectiva del cambio: revisiones y aprobaciones independientes, documentación actual y detallada del proceso y segregación de funciones.

Tanto los defensores como los auditores de la CICD pueden aprovechar los beneficios de una CICD eficiente y efectiva, siempre que demuestre los atributos principales de la auditoría:

• Exactitud e integridad del producto en relación con sus requisitos funcionales y no funcionales
• Integridad del procesamiento y uso, de manera que las fallas no pueden ser explotadas o abusadas
• Continuidad de operaciones para apoyar la disponibilidad del producto
• Seguridad de procesamiento y datos
• Trazabilidad del desarrollo y actividades transaccionales de manera que cualquier actividad realizada dentro o en el sistema pueda rastrearse sin un intervalo desde su inicio hasta su disposición final

La implementación de las políticas y los controles de gobierno recomendados en una metodología de CICD admite los atributos enumerados anteriormente y, por lo tanto, permite que una organización siga cumpliendo con las expectativas de auditoría y reglamentarias al tiempo que se da cuenta del valor de entregar cambios de software a los usuarios previstos de manera rápida y eficiente.

Cambio de contenido de la solicitud

Las solicitudes de cambio permiten a los auditores rastrear un cambio a través del proceso de CICD. Las solicitudes de cambio compatibles incluyen:

• Descripción y prioridad del cambio
• Componentes siendo cambiados
• Categoría de artefactos (por ejemplo, código, script de prueba, tabla de base de datos)
• Cambiar categoría (por ejemplo, mejora, error)
• Partes/responsables del cambio
• Pruebas y criterios de aceptación para la progresión del cambio a través del proceso CICD
• Procedimientos de reversión
• Configuración de CICD utilizada

Si bien esta información debe documentarse para todos los cambios, no es necesario que se incluya en cada ticket de cambio. En algunos casos, la información se puede documentar como parte de un proceso común; por ejemplo, si se usa el mismo proceso para administrar las excepciones dentro de una etapa CICD dada, el proceso se puede documentar una vez en un documento de proceso (wiki o de otro tipo) y se puede mantener según corresponda. Cuando se usa un conjunto determinado de pruebas para la regresión o como factores de éxito para pasar a la siguiente etapa, puede ser más eficiente referirse al conjunto de pruebas que enumerar todas las pruebas específicas, o documentar ese conjunto de pruebas en el documento de proceso que describe los criterios de aceptación de la etapa del CICD.

Notas finales

¹ AXELOS Limited, “ITIL Glossary of Terms,” 2011, https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf
² The ITIL subprocesses are: Assessment of Change Proposals, Request for Change Logging and Review, Assessment and Implementation of Emergency Changes, Change Assessment by the Change Manager, Change Assessment by the Change Approval Board, Change Scheduling and Build Authorization, Change Deployment Authorization, Minor Change Deployment, and Post Implementation Review and Change Closure. Design of Emergency and Minor Changes may not incorporate an in-stream stop for review and approval.
³ Humble, J.; D. Farley; Continuous 3 Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation, Addison-Wesley, USA, 2011
⁴ Caum, C.; “Continuous Deliver vs. Continuous Deployment: What’s the Diff?” Puppet, 30 August 2013, https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff
⁵ Some organizations may instead adopt continuous delivery, where a build is promoted to a staging environment, tested extensively and paused to allow a manual inspection to ensure that deliverables are ready for production release. In continuous delivery, every change should be deployable at any time.
⁶ Op cit Humble and Farley
⁷ Agile, “Principles Behind the Agile Manifesto,” 2001, http://agilemanifesto.org/principles.html
⁸ For example, the Payment Card Industry Data Security Standard (PCI DSS) require each change to have documentation of an approval for the change, an assessment of the impact of the change, tests run to validate the change and the status of the testing, and roll-back procedures.