Para introducir este concepto vamos a ir a la era: Pre- DevOps. En la que teníamos claramente separados al equipo de desarrollo del equipo de operaciones.
El equipo de desarrolladores o Developer team, tenían para entonces sus funciones claramente definidas:
- Escribir el código que hace adquiera funcionalidad la solución software (el programa o la aplicación), principalmente esta es su tarea fundamental, encargarse de que la lógica de negocio tenga funcionalidad.
- Garantizar la seguridad, los desarrolladores tienen que encargarse de que el código que están desarrollando no tenga “agujeros de seguridad”, por ejemplo: No permitir vulnerabilidades xss o no usar la función eval de JavaScript.
- Empaquetar el código mediante contendores.
Por otro lado, el equipo de operaciones, tenía otras tareas también bien definidas, básicamente es asegurarse de que el código corra en producción, para ello tenían que configurar servidores, redes, dns… etc:
- Administrar la estructura donde se ejecutará el código, esta estructura es tanto hardware como software. Por ejemplo: Encargarse de asegurar la red o introducir parches de seguridad del sistema operativo.
- Garantizar que los servicios software se ejecuten conforme a las especificaciones.
Teniendo en cuenta ya la era pre-DevOps, ahora sí podemos introducir este concepto, DevOps engloba una serie de actividades y herramientas que integran en un proceso continuo las prácticas de desarrollo (Dev) y las prácticas de operaciones (Ops).
Alguien que entiende cómo funciona DevOps, se encarga de asegurar un proceso seguro y automatizado desde el momento en el que se escribe código hasta que ese código se ejecuta en los dispositivos de los clientes.
¿Por qué queremos que el proceso sea automatizado?
Porque obtenemos un incremento en la velocidad gigantesco. Entregamos software más rápido, aquí ya podemos entender que esto tiene mucho que ver con el paradigma ágil.
Pero ¿cómo logramos esto?
- Con pruebas automatizadas: Esto trata de asegurar la calidad del código mediante pruebas unitarias o unit tests, lo que conocemos como TDD (Test-Driven Development o test guiado por pruebas), dicho de una manera muy abstracta es como escribir un test antes de escribir las reglas de negocio para garantizar que estas reglas de negocio sean correctas).
Para que funcionen estos tests, necesitamos ejecutarlos continuamente en nuestra máquina pero esto no acaba aquí, cuando trabajamos en equipo debemos ejecutar los tests de otras personas en nuestro código. Es aquí donde cobran importancia los sistemas de integración continua.
- Los sistemas de integración continua (CI Continous Integration) nos permiten integrar continuamente el código de cada uno de nuestros compañeros del equipo DevOPs, ejecutando pruebas automatizadas, pruebas de seguridad y pruebas de calidad, para poder empaquetar y construir software continuamente, es decir, que las dependencias no rompan la capacidad de construir la aplicación.
- Con sistemas de entrega continua (CD continous delivery), esto nos permite distribuir y entregar continuamente el código a los clientes y usuarios. Por ejemplo: Hasta hace no mucho tiempo, tu podías escribir bloques de código y pasaban semanas o meses hasta que ese código llegaba a producción. Si por algún casual, el código no era lo que esperaba el cliente o tenía algún bug, se hacía muy difícil arreglarlo, porque tras dos meses la mente del desarrollador ya está en otro contexto.
¿Esto no os suena a algunos principios ágiles?
- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
- Entregamos software funcional frecuentemente.
- Los responsables de negocio y los desarrolladores deben trabajar juntos de forma cotidiana durante todo el proyecto.
- Con sistemas de monitorización, obtenemos una visión de lo que está sucediendo en nuestros sistemas que permite que diagnostiquemos todo el tiempo lo que está ocurriendo (que está yendo bien y que está yendo mal), esto nos permite mejorar el rendimiento, detectar cuellos de botella y sobre todo conocer cómo funciona nuestra aplicación.
- Desarrollando en torno a microservicios, de manera que la unidad de deployment se envía como una unidad de producción mucho más pequeña, cuando modularizamos a este nivel, se hace mucho más fácil detectar, aislar y corregir bugs.
- Por último, para lograr el éxito en los proyectos DevOps, es necesario una comunicación y colaboración continua con el cliente. Vamos a estar produciendo software continuamente, y necesitaremos por tanto que mejoren los flujos de comunicación tanto de nuestros equipos como con los clientes y los usuarios finales.
Ciclo de vida de DevOps
El modelo del ciclo de vida de DevOps es un modelo iterativo, donde existen varias etapas en bucle.
Parte de Dev o desarrollo:
Planificación: Aquí es donde definimos los requisitos que se necesitan implementar en nuestra plataforma, podemos usar herramientas como issues o boards.
Creación: Es escribir el código necesario para resolver el problema de negocio que tenemos, todo este código podemos tenerlo en un solo lugar para colaborar, para ello utilizamos los repositorios GIT.
Verificación: Una vez que ya tenemos el código, debemos verificarlo, para ello ejecutamos pruebas automatizadas donde definimos las reglas a probar, por ejemplo, las pruebas de seguridad.
Empaquetación: En esta fase empaquetamos nuestro código para ejecutarse en la infraestructura adecuada, normalmente en un contenedor de Docker. Otra manera de verlo cuando elaborábamos código en C, la empaquetación no era más que preparar ese código para que el procesador pudiera ejecutarlo, también podemos ver esto cuando desarrollamos una aplicación en Android, en este caso empaquetamos todo el código y las dependencias en un paquete de Android (Application Package) APK.
Parte de Ops u operaciones:
Release: Esto representa cuando una nueva versión de nuestro código llega a producción. Es donde manejamos lo que denominamos como Continous Deployment o CD, podemos decir que como se trata de un proceso automatizado, estamos mandando todo el tiempo código a producción, además para detectar si estamos introduciendo nuevos bugs, lo etiquetamos bajo feauture flags.
Configuración: Aquí es donde se lleva a cabo la gestión de la configuración, por ejemplo podemos cambiar el cluster de Kubernetes y mandar instrucciones para manejar el nuevo estado de nuestra aplicación.
Monitorización: Visualizamos en todo momento qué servicios están activos y qué rendimiento están teniendo nuestros clientes.
Beneficios de DevOps
Aumentamos la velocidad para entregar código, ya que cuando tenemos scripts y procesos manuales, introducimos también la posibilidad de equivocarnos como seres humanos, el software nos permite automatizar y alcanzar mayores velocidades que las que se dan en un proceso manual
Conseguimos una distribución más eficiente con Continous Delivey, en este punto, tenemos software que está distribuyendo a producción varias veces al día, podemos contrastar esto a cuando mencionábamos anteriormente que el código tardaba meses en llegar a producción.
Logramos una mayor confiabilidad, ya que estamos comprobando continuamente nuestras reglas de negocio, verificando que el código tenga la seguridad y el rendimiento adecuado para el problema que estamos tratando de resolver
Podemos escalar de forma automática, dado que cuando tratamos de hacer esto de forma manual, tenemos que entrar al servidor y gestionarlo y esto involucra más tiempo que utilizar la infraestructura basada en Kubernetes o el uso de Cloud Functions.
Mejoramos la colaboración al utilizar herramientas de planificación, al poder estar todo un equipo de desarrolladores (Dev), operadores (Ops), y gestión (management) dentro del mismo sistema.
Por último, aumentamos la seguridad debido a que tenemos máquinas automatizadas que están detectando todo el tiempo posibles brechas de seguridad.
¿Qué herramientas hay disponibles para trabajar con DevOps?
Tenemos herramientas para DevOps como GitLab, es un producto open-source para generar proyectos y grupos que nos permitan colaborar de forma eficiente. Otra herramienta es Jenkins orientada a la integración continua o Continous Integration (CI) y a la entrega continua o Continous Delivery (CD).
Tanto GitLab como Jenkins se pueden complementar para obtener un beneficio mayor.
Add new comment