Los enfoques de desarrollo ágil se han convertido en el estándar de facto para toda la industria de desarrollo de software. Si bien la agilidad ofrece lanzamientos más frecuentes de software funcionando, rápidamente se hizo evidente en muchas organizaciones que no podían aprovechar estos lanzamientos frecuentes debido a la desconexión entre las funciones de desarrollo y operaciones, siendo este último el responsable de liberar el software a los clientes.

El desarrollo ágil de software consiste en seguir un conjunto de mejores prácticas para crear software de calidad de manera oportuna. Pero el problema es que las mejores prácticas seguidas involucran a personas que trabajan en Silos.

Silos, quiere decir que hay personas que trabajarán como Desarrolladores, o como testers, o como IT Ops con muy poca comunicación entre ellos. Y dado que hay muy poca comunicación entre ellos, no son conscientes de en qué están trabajando los demás a pesar de ser parte del mismo proceso.

En búsqueda de soluciones para aprovechar las potencialidades de la agilidad, y poner en manos del cliente las soluciones en menor tiempo, es que la agilidad comenzó a mirar hacia DevOps. Con la transformación digital andando, la capacidad tecnológica existente hoy y, clientes cada vez mas apurados por tener sus productos en operación, las compañías fueron a buscar un modelo que les permitiera madurar el framework ágil que usaban, apoyándose en tecnología y cultura.

Este modelo de madurez para la transición desde fabricación de productos con agilidad a entregas continuas la logramos con DevOps.

Simple: DevOps rompe los silos por la mitad. En DevOps, el equipo “Dev”, el equipo “ITOps” y el equipo “QA” no son partes independientes de la gama. Pero, son “uno”.

En un ciclo de fabricación de software tradicional, el equipo de desarrollo arranca “lanzando” una versión de software “sobre la pared” a Operaciones. Operaciones recoge los artefactos de liberación y comienza a prepararse para su implementación.

Operaciones modifica manualmente los scripts de implementación proporcionados por los desarrolladores o crean sus propios scripts. También editan manualmente los archivos de configuración para reflejar el entorno de producción, que es significativamente diferente de los entornos de desarrollo o control de calidad.

En el mejor de los casos, están duplicando el trabajo que ya se había realizado en entornos anteriores, en el peor de los casos, están a punto de introducir o descubrir nuevos errores.

La práctica de DevOps utiliza un ingeniero de DevOps, que hace todo: desarrollar el código, probar ese código e implementar el mismo código en producción.

Entonces, ¿la unificación resuelve el problema?

Sí, resuelve un aspecto importante del problema. Dado que el mismo Ingeniero DevOps tiene múltiples habilidades, se le otorgará la propiedad de todo el proceso: desarrollo del código, prueba unitaria / prueba funcional del código e implementación de ese código en el servidor de ensayo / prueba / producción.

DevOps es un Modelo Cultural y Operacional que fomenta la Colaboración para Habilitar una TI de alto-desempeño que Logra objetivos de Negocio.

El término DevOps es una contracción de las palabras “Development” (Desarrollo) y “Operations” (Operaciones). DevOps es un conjunto de prácticas recomendadas que enfatizan la colaboración y la comunicación entre los profesionales de TI (desarrolladores, administradores, operadores, personal de asistencia técnica) en el ciclo de vida de las aplicaciones y los servicios, lo que conduce a:

Integración Continua

Con la integración continua los desarrolladores integran frecuentemente su código a la rama principal de un repositorio común. En lugar de desarrollar partes del código de manera aislada e integrarlas al final del ciclo de producción, un desarrollador contribuirá con cambios a una parte del repositorio varias veces al día.

La idea aquí es reducir los costos de integración, haciendo que los desarrolladores realicen integraciones más rápidamente y con mayor frecuencia. En la práctica, un desarrollador a menudo descubrirá conflictos entre el código nuevo y el existente en el momento de la integración. Si esta se realiza temprano y con frecuencia, la expectativa es que la resolución de conflictos será más fácil y menos costosa.

Entrega Continua

La entrega continua es en realidad una extensión de la Integración Continua, en la cual el proceso de entrega de software se automatiza para permitir implementaciones fáciles y confiables en la producción, en cualquier momento.

Un proceso de Entrega Continua (CD) bien implementado requiere una base de código que se pueda desplegar en cualquier momento. Con la Entrega Continua, los lanzamientos de nuevos cambios ocurren de manera frecuente y rutinaria. Los equipos continúan con las tareas diarias de desarrollo con la confianza de que pueden mandar a producción un lanzamiento de calidad, en cualquier momento que deseen, sin una complicada implementación y sin tener que seguir pasos de manuales ejecutados por un especialista.

Despliegue Continuo

El despliegue continuo es una modalidad más avanzada de Entrega Continua en la medida en que los despliegues a producción no pasan por una validación humana sino que están totalmente automatizadas.

La única forma de detener nuevos desarrollos en producción es a través de una prueba que falla e identifica los errores. La implementación es una manera de acelerar la retroalimentación, haciendo más eficiente el trabajo del equipo.

Gracias a este tipo de despliegue, los desarrolladores pueden llegar a ver su trabajo funcionando poco tiempo después de haberlo realizado, pero requiere el mayor esfuerzo en buenas prácticas y procesos automatizados.

Si estás convencido de las bondades que puede traer DevOps a tu organización y equipos de trabajo, te invito a ver el siguiente webinar donde hablo del tema con mayor profundidad.

Comentarios

comentarios