En el post anterior describimos los elementos que deberían tener las herramientas que elijamos en nuestro viaje para implantar una metodología DevOps en nuestra organización.
En este post, queremos compartir con vosotros los aspectos que hemos tenido en consideración para elegir las herramientas que forman parte de Orbis, la plataforma DevOps de Xeridia.
Para seleccionar las herramientas más apropiadas para implementar DevOps en cada entorno será necesario tener en cuenta aspectos como la capacidad de integración, el soporte para metodologías ágiles, la facilidad para implementar los patrones de despliegue (deployment pipeline) en nuestro sistema, la facilidad para hacer llegar el feedback del cliente a los equipos de desarrollo, o la facilidad que ofrecen para favorecer que emerja una cultura de experimentación y aprendizaje continuo en la organización.
CAPACIDAD DE INTEGRACIÓN
El primer punto que hay que resolver es si es buena idea tener herramientas de distintos fabricantes o si es mejor utilizar una suite de productos de un solo fabricante. Todo tiene sus pros y sus contras pero en este punto intentaremos responder a la pregunta básica ¿Qué respuesta favorece más la colaboración y la comunicación entre equipos?
En este aspecto disponer de herramientas integradas que centralicen e intercambien información en tiempo real, con los miembros del equipo, los clientes y usuarios parece la respuesta adecuada.
Si se opta por productos de distintos proveedores lo que tendremos que tener muy en cuenta es su capacidad de integración entre todos ellos. Tenemos que asegurarnos que estos productos ofrecen conectores con los productos de (al menos) los principales fabricantes, o bien proporcionan un API para poder integrar dichas herramientas con productos de terceros.
SOPORTE DE METODOLOGÍAS ÁGILES
Otro elemento importante a tener en cuenta es que la plataforma de gestión de proyectos que se elija deber soportar las metodologías ágiles (SCRUM, Kanban y LEAN, entre otras). Por tanto en este punto deberíamos preguntarnos lo siguiente:
- ¿La herramienta me permite elaborar pilas de producto (o product backlog) priorizadas?
- ¿Puedo establecer Sprints en base a los ítems de dicho product backlog?
- ¿Me permite la herramienta visualizar el trabajo mediante pizarras?
- ¿Puedo establecer límites al trabajo en progreso o WIP?
- ¿Me genera gráficos de Burn Down Chart?
- ¿Me permite la herramienta realizar Value Stream Mapping?
- ¿Permite calcular el tiempo de ciclo de un sistema de manera sencilla?
- ¿Me permite mediante un análisis detectar los cuellos de botella del sistema?
Es decir, ¿la herramienta está orientada al agilismo y la reducción de los tiempos de ciclo?
Por ejemplo, podríamos decir que una hoja de cálculo puede cumplir con esos elementos. Pero, ¿qué favorece más la colaboración entre equipo, una hoja de cálculo o una pizarra de trabajo compartida en un entorno web? Yo personalmente soy de la opinión de que las hojas de cálculo y documentos de texto son muy útiles para una persona que trabaje de forma individual pero no para trabajo en equipo, donde el versionado y la actualización de la información se complica.
¿Una herramienta especializada en elaborar diagramas de GANTT sería adecuada? Pues difícilmente, ya que no responde afirmativamente a las preguntas anteriores. Seguramente será muy útil en otros ámbitos, pero para implementar DevOps, no.
» Disponer de herramientas integradas que centralicen e intercambien información en tiempo real, con el equipo, los clientes y los usuarios favorece la colaboración y comunicación entre equipos. «
En Xeridia hemos elegido Jira Software. Con esta herramienta es posible dar soporte completo al framework SCRUM creando pilas de producto priorizadas, pilas de sprint, pizarras kanban, limitar el WIP, obtener automáticamente Burn Down Charts, generar diagramas de flujo acumulado, gráficas de control de proceso…
Además, el uso combinado con Confluence permite a su vez acumular el conocimiento y hacerlo disponible a todo aquel que lo necesite. El tándem Jira-Confluence se convierte en una herramienta muy potente para la gestión de los proyectos y la colaboración de todos los implicados. Confluence proporciona muchas opciones para favorecer el trabajo en grupo.
DEPLOYMENT PIPELINE
Otro factor fundamental para implementar DevOps es que las herramientas que seleccionemos deben favorecer la reducción del tiempo de ciclo. En este punto es imprescindible que las herramientas se puedan integrar para construir lo que se denomina Deployment Pipeline.
Una pipeline sería la secuencia de tareas o procesos necesarios por los que pasa el trabajo desde que se concibe como idea hasta que se entrega al cliente.
Más en concreto, la deployment pipeline sería la secuencia de tareas ejecutadas desde que el código se sube al servidor de versiones (Commit Stage) hasta que éste se despliega con éxito en producción y se da servicio a los usuarios.
De modo genérico las herramientas necesarias para implementar una deployment pipeline serían:
- Servidor de control de versiones.
- Servidor de integración/entrega continua.
- Servidor de almacenamiento de artefactos generados en la etapa de construcción.
- Frameworks de tests que sirven de control para pasar de una etapa a otra. Se incluyen también herramientas de análisis de calidad de código.
- Mecanismo de despliegue automático.
Lo más importante es que se pueda visualizar dicha pipeline para saber el estado de la misma en cada momento.
Concretando un poco más, dentro de cada tipo de herramienta para la implementación de la deployment pipeline existen multitud de posibilidades y combinaciones. Veamos algunas de las herramientas que Xeridia recomienda:
Primero, en cuanto al servidor de versiones se puede optar por Subversion, Git, Bitbucket, etc.
Siguiendo con la idea de la máxima integración de productos Xeridia propone dentro de su solución el uso de Bitbucket como servidor de versiones y Bamboo como servidor de integración y despliegue continuo.
El servidor para almacenar los artefactos generados seleccionado es Artifactory aunque hay otros disponibles como por ejemplo Nexus.
En cuanto a los frameworks de testing cabe recordar que lo que da realmente consistencia a la pipeline es el conjunto de tests a todos los niveles, es decir, unitarios, integración, sistema y aceptación. Solo podremos hacer entrega continua cuando tengamos una suite de tests que den la confianza al sistema para certificar que se puede promocionar a producción de manera automática. No debemos olvidar nunca que la calidad del código debería ser un factor que debería limitar que se progrese en la pipeline.
La variedad de implementaciones en este punto es muy variada y dependiente de los proyectos y tecnologías. En Xeridia se apuesta por el uso de metodologías TDD y BDD para automatizar las pruebas a todos los niveles. El uso de BDD sigue el principio de maximizar el flujo de comunicación estableciendo un lenguaje común entre los usuarios y los desarrolladores que facilita la comunicación y comprensión entre estos dos grupos de participantes del desarrollo.
A nivel de calidad de código Xeridia apuesta por la herramienta Sonar que integra dentro de la pipeline como controlo de calidad.
Por último, para poder hacer los despliegues de manera automática es necesario elegir una herramienta que permita realizar dicha tarea.
Hay varios posibles como Puppet, Chef, Ansible, etc. En Xeridia, siguiendo con la filosofía de proporcionar el máximo nivel de comunicación, se ha elegido Ansible ya que utiliza un lenguaje (DSL) que genera lo que se denomina “documentación ejecutable”. En otras palabras, la propia documentación es en realidad el código que realiza la tarea de despliegue, olvidándonos para siempre de manuales de despliegue.
EL SEGUNDO CAMINO: FEEDBACK
En este punto ya hemos captado las ideas, desarrollado las mismas y puesto en producción. Hemos seguido el First Way de DevOps acelerando el flujo de izquierda a derecha. Debemos ahora recorrer el Second Way y ampliar el feedback desde la derecha a la izquierda.
Debemos dotar a nuestro sistema de herramientas para proporcionar información de lo que está sucediendo en producción a todos los implicados, desde miembros del equipo de IT, desarrolladores, marketing, negocio…
A nivel de infraestructura es necesario disponer de herramientas que den información en tiempo real de cómo se está comportando el entorno y la aplicación. Solamente con esa información deberíamos saber si un pase que acabamos de realizar se está comportando como esperábamos o no.
En Xeridia elegimos New Relic como herramienta de monitorización (APM) porque proporciona visibilidad en tiempo real sobre todos los componentes de la plataforma:
- Aplicaciones y su comportamiento interno llegando a nivel de código a través de New Relic APM.
- Servicios asociados como bases de datos, colas, plataformas Big Data, etc. a través de New Relic Plugins.
- Comportamiento de los servidores a través de New Relic Infraestructure.
- Comportamiento de las aplicaciones en los navegadores de los clientes a través de New Relic Browser.
- Comportamiento de aplicaciones móviles a través de New Relic Mobile.
- Y todo ello con un potente motor de alertas para la detección temprana de problemas (New Relic Alerts), otro de visualización y explotación de toda la información recolectada (New Relic Insight) y múltiples integraciones con plataformas de ticketing, Chat (Ops) etc. que garanticen un seguimiento efectivo del comportamiento de los entornos.
En definitiva, es una plataforma clave para que operaciones pueda trabajar de manera proactiva en un contexto DevOps.
Pero no nos olvidemos de los usuarios. Es de vital importancia conocer cuanto antes el feedback de los usuarios y que dicho feedback se integre inmediatamente en el desarrollo para poder responder a sus peticiones cuando antes.
Para ello hay que buscar una herramienta de soporte moderna y flexible y que se integre con nuestro ecosistema. En este punto el uso de Jira Service Management nos reporta grandes ventajas ya que se integra directamente con Jira y Confluence sin necesidad de esfuerzo adicional.
En ciertas situaciones y con el objetivo de facilitar más la comunicación con el cliente se podría integrar con HipChat o Stride para proporcionar soporte en vivo al usuario. La ventaja de usar HipChat es que se integra con todas las herramientas antes mencionadas lo que habilita la posibilidad de implementar una estrategia ChatOps.
CULTURA DE EXPERIMENTACIÓN Y APRENDIZAJE CONTINUO
Por último hay que tener en cuenta que los errores ocurren y hay que estar preparados para aprender de ellos. Hay que realizar blameless postmortems de cada proyecto o problema en producción, registrar lo acontecido y aprender de dichos incidentes. Para ello Confluence nos permite mediante sus plantillas tener documentados de manera adecuada y disponible para todo el mundo estas reuniones de postmortem, así como las retrospectivas de los equipos. Esto fomenta una cultura transparente, carente de miedo y proclive a la experimentación, básica para la mejora continua del sistema. Por otro lado, para hacer un seguimiento de los problemas que ocurren en el sistema, se puede utilizar Jira Service Management con su flujo de gestión de problemas.
Todas estas herramientas DevOps en su conjunto hacen que se desarrolle una cultura de colaboración y confianza entre desarrollo y operaciones que hacen posible que el enfoque DevOps prospere.
En este post hemos hecho un repaso de algunas de las herramientas que se pueden usar para implementar DevOps. Este repaso no es completo y se pueden combinar muchas otras siempre teniendo en cuenta que sigan los tres caminos: acelerar el flujo, amplificar el feedback y crear una cultura de experimentación y aprendizaje continuo.
Las herramientas son importantes pero no por usar un conjunto de herramienta se consigue implementar DevOps. El aspecto humano también es esencial para implementar con éxito DevOps en una organización y en ocasiones es el más complejo de gestionar.
Por tanto, en los siguientes posts analizaremos también otros elementos clave para el éxito en la implementación de DevOps.
Emiliano Sutil es Project Manager en Xeridia
