Introducción
Estoy participando en un proyecto para realizar el seguimiento de tareas internas en una compañía de distribución comercial de bienes y servicios. Para llevar a cabo correctamente esta gestión de tareas decidimos instalar la solución JIRA de la compañía Atlassian. Sobre esta herramienta instalamos un par de plugins a través del marketplace y realizamos la configuración de tres workflows para el seguimiento personalizado de las tareas. Como este sistema de seguimiento no era crítico para la compañía decidimos crear dos instalaciones diferenciadas: la instalación de desarrollo, donde desarrollar y probar las configuraciones y nuevos desarrollos, y una instalación productiva donde la compañía llevaría a cabo su trabajo productivo.
A principios de este mes llegó el momento de poner en producción las instalaciones, configuraciones y desarrollos que se habían ido realizado en el entorno de desarrollo, y claro está surgieron inquietudes tipo; ¿perderemos algo a la hora de realizar el traspaso? ¿cómo comprobaremos que todo ha sido traspasado correctamente? ¿habrá que parar el entorno productivo? ¿Cuánto tiempo deberá estar parado en caso afirmativo?.
Este post es la recopilación de las diferentes alternativas que contemplé para realizar el despliegue en producción del desarrollo en JIRA.
Buenas prácticas para facilitar los despliegues entre entornos de JIRA.
En cualquiera de los métodos que se van a enumerar a continuación es una buena práctica, a la hora de desarrollar en JIRA seguir una metodología que nos lleve a documentar las diferentes configuraciones y desarrollos que realizamos. Normalmente la documentación es uno de los entregables que menos se cuida cuando se realiza la entrega de un producto software, pero sin embargo en JIRA es una pieza esencial para entender qué se ha hecho y facilitar los despliegues y migraciones posteriores.
Otra buena práctica es contar, con un entorno de desarrollo donde personalizar las configuraciones, realizar los desarrollos y probar los plugins que vamos a llevar a producción, con un entorno pre-productivo, donde si la instalación de JIRA es crítica para el negocio, poder probar que no se rompe nada con el desarrollo que queremos llevar a producción, y con un entorno productivo que es el que finalmente da servicio al negocio.
Por supuesto, y esta va a ser una buena práctica basada en el sentido común, si se está desarrollando un plugin para JIRA, el nombre de los paquetes java debe ser propio y concluyente. Sería lioso si utilizáramos como nombre com.atlassian.jira.plugins, mucho mejor sería org.mycompany.jira.plugins.
Recopilación de diferentes métodos para estos despliegues.
Una vez terminado el desarrollo, normalmente en un entorno no productivo, el siguiente paso es ponerlo en producción. Para ello existen varios caminos de los cuales elegiremos el que mejor nos cuadre con nuestra manera de trabajar. A continuación enumero aquellos métodos que tuve en cuenta en la puesta en producción del proyecto que teníamos entre manos, y después os contaré cual elegimos y el motivo.
Método manual.
Si se ha cumplido la premisa de que el desarrollo está correctamente documentado, y tenemos un inventario claro y ordenado de los cambios que se han realizado, este método proporciona varias ventajas y algún que otro pero.
La principal ventaja es que el control y conocimiento en el despliegue es total. Paso a paso se replican los cambios realizados en desarrollo y que han llevado al buen funcionamiento en dicho entorno. Si surge algún problema, se soluciona y se procede a actualizar la documentación hasta dejarla correctamente depurada.
Este método permite que el despliegue productivo lo realice personal técnico ajeno al desarrollo, que no solo valida la documentación, si no que adicionalmente adquieren conocimiento de la instalación.
Como contra, de todos los métodos que voy a enumerar, este es con diferencia el más lento de todos ellos, pudiendo llevar horas cada implantación a producción. Además, es esencial contar con un entorno pre-productivo donde depurar la documentación y poder probar que todo funciona correctamente antes de poner el software en producción.
Método basado en herramientas out-of-the-box.
Para agilizar los despliegues de los workflows, con los que hemos personalizado nuestra instalación, podemos utilizar las herramientas de exportación que se proporciona con la instalación básica de JIRA. Estas herramientas permiten exportar los workflows en un fichero empaquetado. Este fichero empaquetado se puede incluso desplegar en el Atlassian Marketplace pasando a estar disponible para replicar en otros entornos JIRA de nuestra compañía, e incluso en entornos JIRA de otras compañías.
La documentación de Atlassian explica paso a paso en la documentación la manera de proceder para la exportación e importación. Atlassian Documentation: Sharing your workflow.
Ni que decir tiene que al ser un método basado en las herramientas que proporciona el propio JIRA es un método seguro y fiable, que exporta los workflows con total garantía y que cuenta con la ventaja de que al publicarse en el Atlassian Marketplace, automáticamente queda disponible para ser utilizado en otros entornos de JIRA.
Por supuesto, al automatizar parte del proceso de despliegue, éste se hace más rápido y las implantaciones duran menos que siguiendo el método manual.
Como contra decir que la exportación e importación de JIRA solo funciona con workflows, quedando fuera ventanas, plugins y otros elementos que habría que seguir exportando manualmente.
Método basado en herramientas de terceros.
Ante la inexistencia de herramientas nativas que manejen el ciclo de vida de los desarrollos y sus despliegues a diferentes entornos, terceras empresas han desarrollado herramientas que facilitan estas tareas y que ofrecen a través de plugins, normalmente de pago.
Los plugins mejor valorados en el marketplace de Atlassian son:
Configuration Manager
El plugin fue creado para automatizar la migración de las configuraciones de proyectos teniendo en cuenta todo tipo de componentes.
El plugin está creado por Botron Software, un desarrollador de plugins certificado por Atlassian con un soporte de 8 horas al día, 5 días a la semana. El plugin está soportado por el propio Atlassian.
La versión 5.1.4 del plugin es compatible con Jira Server desde la versión 6.3 hasta la versión 7.7.0.
Entre otras cosas el plugin:
- Permite realizar snapshots de JIRA a nivel de Proyecto, incluso a nivel de Sistema que pueden ser desplegadas en otros servidores JIRA.
- Analiza automáticamente todos los cambios y determina si existe impacto en otros proyectos publicados en el servidor JIRA destino.
- El despliegue de los snapshots lleva unos pocos minutos, en vez de las horas que implica llevar a cabo todas las operaciones de un despliegue manual.
- Proporciona una trazabilidad completa de las operaciones realizadas.
A día de hoy, el licenciamiento de esta herramienta es el siguiente:
10 users
10$ |
25 users
500$ |
50 users
1000$ |
100 users
1800$ |
250 users
3200$ |
Project configurator
El plugin fue creado para mover proyectos, o solo sus configuraciones, de una instanacia de JIRA a otra.
El plugin está creado por Adaptavist, un desarrollador de plugins certificado por Atlassian con un soporte de 8 horas al día, 5 días a la semana. El plugin está soportado por el propio Atlassian.
La versión 2.3.0J7 del plugin es compatible con Jira Server desde la versión 7.0.0 hasta la versión 7.6.3 de JIRA. Como ventaja adicional, están compatibilizando esta versión con la versión JIRA Service Desk.
Entre otras cosas el plugin:
- Exportar uno o múltiples proyectoen un único fichero de exportación.
- Exportar todo el proyecto o sólo las configuraciones.
- Proporciona trazabilidad completa de la información exportada.
- Simular como afectan los cambios de configuraciones en la instancia destino de JIRA.
A día de hoy, el licenciamiento de esta herramienta es el siguiente:
10 users
10$ |
25 users
125$ |
50 users
235$ |
100 users
395$ |
250 users
565$ |
La gran ventaja de utilizar cualquiera de estas herramientas es que son capaces de gestionar el despliegue de proyectos y esquemas completos, pudiendo exportar toda la estructura o solo las configuraciones. Además, proporcionan trazabilidad completa de las operaciones que se llevan a cabo, permitiendo simular la implantación y detectar antes de implantar si existe o no algún riesgo de incompatibilidad entre lo que se sube y lo que ya existe en el servidor.
Por supuesto, al realizarse de manera automática, los despliegues tardan muchísimo menos en finalizar, no por ello dejándose a un lado la seguridad de un buen despliegue.
Por contra, lo bueno cuesta dinero, y dependiendo del número de usuarios de la licencia de JIRA nos costará más o menos poder utilizarlos.
Otros métodos
Adrede dejo fuera del estudio otros métodos, como la clonación del esquema de la base de datos de desarrollo en producción, o la realización de un exportador a medida utilizando el REST API de JIRA, porque o bien no lo considero adecuado, o bien no considero que el despliegue sea tan complejo que el esfuerzo merezca la pena.
Conclusión.
La elección del método depende de varias variables:
- la primera del esfuerzo y participación que se quiere tener en el despliegue
- la ventana horaria que hay para realizar los despliegues
- el presupuesto
Tanto si el despliegue no debe suponer un gran esfuerzo, como si la ventana horaria no es muy grande deberíamos elegir un método lo más automático posible, las herramientas de terceros es el método más rápido y más desatendido, como contra está el presupuesto del que disponemos para dedicar a los despliegues. El método manual queda relegado a aquellas personas a las que le gusta tener el control absoluto de la implantación y tienen un profundo conocimiento tanto de lo que están haciendo como de la administración de JIRA, sin importarles el tiempo que les lleva el despliegue.
Links
Tecnicomio 