DevSecOps - una breve introducción
En principio, vamos con definiciones formuladas por una IA corporativa:
DevOps: Enfoque de trabajo que integra el desarrollo, la operación y el mantenimiento de soluciones informáticas mediante prácticas de colaboración, automatización e integración continua, con el propósito de mejorar la calidad, trazabilidad y oportunidad en la entrega de productos y servicios digitales.
DevSecOps: Evolución del enfoque DevOps que incorpora la seguridad de la información y la gestión de riesgos de manera transversal durante todo el ciclo de vida de las soluciones tecnológicas, desde su diseño y desarrollo hasta su operación y mantenimiento.
Como anécdota, empezaba el siglo XXI y debido a un cambio en los formatos de las estadísticas de cultura (hoy solo queda museos) se optó por pasar de un sistema de escritorio (standalone) a un sistema web usando Visual Studio .NET.
Para hacer más ágil el desarrollo se creo una carpeta compartida e incluso se usó un cable ethernet cruzado para que el equipo de cuatro desarrolladores tuviéramos el código disponible y con esto cumplir la meta de tenerlo listo en un tiempo de 3 meses que quizás se alargó a 5, pudiéramos decir que aquí ya estábamos vislumbrando los inicios de DevOps.
En una tesis de maestría, Juan de Jesús Padrón Hernández señala que el antecedente de esta 'cultura' o 'enfoque de trabajo' se remonta a la conferencia de 2009 titulada '10+ Deploys per Day: Dev and Ops cooperation at Flickr', presentada por John Allspaw y Paul Hammond en la conferencia Velocity de O'Reilly . Esta presentación marcó un hito en el desarrollo de software, ya que demostró que era posible realizar múltiples despliegues diarios en una organización tan grande como Flickr, algo que parecía imposible en una época donde los calendarios de entregas solían planificarse en semanas o incluso meses.
Inspirado en esta conferencia Patrick Debois, en este mismo año idea y crea el evento DevOpsDays en su ciudad natal: Gante, Belgica y aquí es donde se acuña por primera vez el termino DevOps.
Y sobre estas fracturas entre operaciones y desarrollo es casi un hecho de facto, en muchas ocasiones no son fracturas sino abismos y en lugar de colaborar para lograr el objetivo, pareciera que se ponen grandes obstáculos entre los integrantes de estos 2 equipos.
Según el libro "DevOps para dummies" las organizaciones adoptan este esquema de acuerdo a una necesidad de negocio - "DevOps aplica principios ágiles y principios de optimización continua a lo largo de todo el ciclo de vida del software. Esto permite a una organización maximizar la velocidad con la que entrega productos o servicios, desde la concepción inicial de una idea hasta su liberación a producción, incorporando la retroalimentación de los usuarios y las mejoras derivadas de dicha retroalimentación" (Sharma & Coyne, 2015, p. 4)
En este mismo texto se señala que no solo se debe enfocarse en las "Tecnologías de la información" sino a su lazo natural con los procesos de negocio.
El retorno de la inversión que nos da DevOps se refleja en tres áreas:
- Mejorar la experiencia del usuario.
- Incrementar la capacidad para innovar
- Tiempo de obtención de valor más rápido
Como casi todo lo que tiene que ver con las tecnologías de la información, este enfoque ha evolucionado de tal forma que de ser DevOps ahora es DevSecOps e inclusive en los primeros trabajos para definir su arquitectura se habla de un ciclo de 4 fases, y ahora verificando el estado del arte actual (o al menos el que encontré) son 10 que las han incrustado en una imagen del símbolo de infinito:
Arquitectura de referencia según libro de "DevOps for dummies, 2nd IBM Limited Edition" del 2015 de Sanjeev Sharma y Bernie Coyne.
Fases y filosofías de DevSecOps según "DoD Enterprise DevSecOps Strategy Guide" del Departamento de Defensa de los Estados Unidos de América, 2021.
El modelo de referencia de DevOps tradicional, que separa las fases de desarrollo, despliegue y operación (ver Figura 2.1 en Sharma & Coyne, 2015), ha evolucionado hacia un enfoque integral donde la seguridad ya no es una fase aislada, sino que impregna todo el ciclo de vida, dando lugar al DevSecOps (Departamento de Defensa de los Estados Unidos, 2021).
Y después de todo esto...¿dónde conecta Git?
Nuevamente retomando el tema de aquel desarrollo de Cultura, cuando nos autoexiliamos a la naciente Dirección de Informática de la antes DGE, a la hora de "tirar código" teníamos nuestro "GIT" artesanal en aquella carpeta compartida de Windows, y que cada vez que alguien compilaba la solución en voz alta decíamos "voy a compilar".
¿Qué es Git? - Los antecedentes.
Este software nace a la necesidad de los desarrolladores del kernel de Linux para tener un sistema de control de versiones para lo cual usaron software propietario de una compañía llamada BitKeeper.
En 2005 dicha compañía revocó los términos para las herramientas gratuitas y la comunidad de Linux tuvo que desarrollar el propio, en base a la experiencia de uso del que les brindaba la compañía.
Git es un sistema de control de versiones distribuido que tiene los siguientes atributos:
- Velocidad
- Diseño simple
- Soporte robusto para desarrollos no lineales (miles de ramas paralelas)
- Totalmente distribuido.
- Capacidad para administrar proyectos grandes como el kernel de Linux eficientemente (velocidad y tamaño de datos) - (Chacon & Straub, 2014, p. 13).
Git no es GitHub ni GitLab.
Si se es un poco deductivo, se puede intuir que Git no solo permite crear repositorios locales, sino que su verdadero potencial como sistema distribuido se manifiesta al sincronizar copias entre diferentes equipos y servidores centrales.
Sin embargo, al igual que gran parte del software de código abierto, Git carece de una interfaz gráfica oficial por defecto (su manejo nativo es mediante línea de comandos), y tampoco incluye funcionalidades avanzadas de gestión de proyectos, automatización o seguridad.
Es aquí donde surgen compañías como GitHub (adquirida por Microsoft) o GitLab, que ofrecen plataformas visuales con planes gratuitos y de suscripción. En este punto, GitLab destaca por ofrecer su edición Community Edition, la cual permite ser instalada en servidores propios, ofreciendo así un control total sobre la infraestructura, al más puro estilo de sistemas como Moodle.
Aquí es donde cobra sentido su uso institucional en nuestra organización, y por ello para gestionar el código es necesario usar Git con GitLab como repositorio en los servidores que tiene el Instituto.
Hasta aquí este breviario, espero haber sido claro y sino estamos a la orden.
Miguel Araujo
Referencias
Padrón Hernández, J. (2021). DevSecOps: integración de la seguridad en entornos CI/CD. Universitat Oberta de Catalunya (UOC). https://hdl.handle.net/10609/132367
Departamento de Defensa de los Estados Unidos. (2021, marzo). DoD Enterprise DevSecOps Strategy Guide (Versión 2.0). Office of the Chief Information Officer.
https://dodcio.defense.gov/Portals/0/Documents/Library/DoDEnterpriseDevSecOpsStrategyGuide.pdf
Sharma, S., & Coyne, B. (2015). DevOps For Dummies (2nd IBM limited ed.). John Wiley & Sons. https://cs.uwaterloo.ca/~ijdavis/teaching/2017spring/cs446/devopsfordummies.pdf
Chacon, S., & Straub, B. (2014). Pro Git (2.a ed.). Apress.
https://dirac.df.uba.ar/_media/progit_v2.1.19.pdf
Revisiones y sugerencias: Copilot y DeepSeek
Comentarios
Publicar un comentario