Vamos con la última entrega de esta serie de post destinados a enseñarte los conceptos básicos de cara a implantar integración continua.
Como esta parte tiene mucho contenido, voy a dividirlo en 2 post, uno para esta semana y otro para la semana que viene.
Todo lo que voy a contar a continuación es mi opinión personal, fruto de mi experiencia con este tema.
Con este post, lo que quiero es dejarte mi punto de vista sobre cómo empezar a abordar la implantación de la integración continua, y darte algunos consejos que espero te sirvan de ayuda para ello.
Aún así, si tienes otra visión sobre este tema, o alguna duda, no dudes en escribir un comentario o contactarme por correo. Estaré encantada de hablar lo que sea 🙂 .
¡Ah! Y por si te perdiste los primeros post, aquí los tienes:
– Aprende a implantar integración continua desde cero (I): ¿Por qué integración continua?
– Aprende a implantar integración continua desde cero (II): Un esquema simple de integración continua
—
Una vez que ya tenemos una idea de qué es integración continua, y qué beneficios nos puede aportar, vamos a ver cómo podemos implantarla.
Tal y como yo lo veo, no todas las empresas implantarán integración continua de la misma manera, invirtiendo el mismo tiempo. Pero es algo normal.
Todo dependerá del equipo, de la cultura de la empresa, de cómo está de bien definido el proceso de desarrollo software y si se llevan a cabo ciertas buenas prácticas de ingeniería del software o no.
Además, aunque el concepto de integración continua es el mismo y las buenas prácticas asociadas a ella también, puede que de cara a una empresa, sea más beneficioso implementar unas buenas prácticas u otras por cómo es la empresa y el software que desarrolla.
Incluso dentro de una misma empresa, en un primer momento, el proceso de integración continua no tiene por que ser perfecto. Deberemos ir evolucionándolo y mejorándolo.
Por ejemplo, yo no te diría que para todas las empresas lo primero y más primordial es automatizar pruebas unitarias. A lo mejor, por cómo es tu aplicación, si los componentes están muy acoplados entre sí y es complicado empezar por ahí, te viene mejor invertir el esfuerzo primero en automatizar otro tipo de pruebas, tales como integración o de sistema.
Luego en un futuro, si ves que podría aportar un beneficio, puedes mejorar tu plan de pruebas y el pipeline de integración continua, incorporando pruebas unitarias.
Algo muy importante que debes tener en cuenta además, es que el éxito de la integración continua depende del equipo, de las personas, de si están concienciados y de si ven que la integración continua es beneficioso, algo que les ayuda o no.
Esto es así, porque implantar integración continua conlleva un cambio en la forma de trabajo del equipo, en el día a día de las personas, que debe ir siendo aceptado poco a poco.
Por ello, si lo que de verdad quieres es que la integración continua produzca un cambio, una mejora en todo el proceso, en el software, en el día a día del equipo, mi consejo es que implantes integración continua por pasos.
Si en tu empresa la política de control de versiones está muy bien definida, tenéis plan de pruebas de distinto tipo, en definitiva, un proceso bien definido e interiorizado entre la gente del equipo, implantar integración continua será muy sencillo.
Si este no es el caso de tu empresa, ve poco a poco. Empezad definiendo bien las cosas básicas, e introduciendo mejoras paulatinamente.
Por eso, aquí te dejo lo que creo que son los pasos principales para implantar la integración continua, y unos pequeños consejos, puesto que deberás adaptar los pasos a tu empresa, al software etc.
1. Conciencia a las personas y da formación sobre el tema.
Creo que este punto es primordial a la hora de afrontar cualquier cambio en una organización.
Los cambios afectan a las personas, y normalmente, tendemos a no querer cambiar, a aceptar lo malo aunque sea conocido frente al cambio.
Hay que facilitar el cambio, explicando ante todo qué se va a hacer, y por qué se va a implantar integración continua.
Incluso, podría ser un buen momento para hablar con el equipo y que ellos mismos dijeran qué cosas negativas o positivas ven al proceso de desarrollo actual, o cómo lo mejorarían.
Además, es importante ir formando al equipo en las nuevas tecnologías que vayas a implantar, en hacer pruebas unitarias, de integración, en buenas prácticas, patrones de diseño etc.
2. Ten claro el proceso de desarrollo en la empresa.
Con esto me refiero a por ejemplo, tener bien definido cosas como qué entornos hay (por ejemplo, desarrollo, testing, pre-producción y producción), cuáles son los criterios para que las versiones software pasen de un entorno a otro, qué se hace en cada entorno, qué tipos de pruebas se hacen y en qué momento etc.
Cosas muy simples. Recopila toda esa información y si el proceso no está muy claro, defínelo bien.
Además, es bueno que todo el mundo conozca toda esta información.
¿Por qué te aconsejo esto? Si te fijas, un servidor de integración continua como Jenkins va a ser un elemento de enlace para todo esto.
Es decir, vamos a intentar mejorar el desarrollo, introduciendo más comprobaciones, pero también vamos a intentar automatizar todos los procesos repetibles, manuales que se puedan automatizar para invertir tiempo en otras cosas.
Por ejemplo, podríamos programar el servidor de integración continua para que cuando el código que alguien suba al control de versiones se compile y pase ciertas pruebas, se despliegue automáticamente y promocione a otro entorno.
Por ello, tenemos que tener claro cuál es el proceso de desarrollo, qué se hace desde que se programa hasta que se pasa a producción, para poder automatizar o implementar en el servidor de integración continua lo que creamos necesario.
3. Ten clara la política de gestión de la configuración y control de versiones.
Esto también es algo imprescindible. Sin control de versiones, la integración continua no funciona.
Si recuerdas el esquema de integración continua del post anterior, el servidor de integración continua vigila, monitoriza los cambios que se hagan en el sistema de control de versiones.
Por ello, antes de ponernos manos a la obra implantando integración continua es necesario pensar cómo vamos a combinar nuestra estrategia de control de versiones con la integración continua.
Te dejo algunas ideas/preguntas para que os planteéis:
– ¿Desarrollaremos una historia de usuario por rama y tendremos una rama master o principal de integración? ¿El servidor de integración continua monitorizará los cambios en esa rama master?
– ¿Además de eso tendremos rama por equipo de desarrollo?¿Ramas de estabilización y bug-fixing antes de pasar a producción?
– ¿El servidor de integración continua también monitorizará las ramas de historias de usuario que se vayan creando?
– ¿Optaremos por una estrategia de rama única que será la que monitorizará el servidor de integración continua?
En este caso, ¿cómo gestionaremos las subidas de código al repositorio de control de versiones que no están terminadas, que no quiero que compilen ni pasen las pruebas en el servidor de integración continua?
– ¿Cuándo se cierra la versión de código? ¿Cómo numeramos las versiones?
Por ponerte algunos ejemplos. Ten en cuenta que para decidir la estrategia de control de versiones a seguir (sobre todo el tema de crear ramas o no) también influirá qué herramienta de control de versiones utilizáis en la empresa.
Subversion o SVN, no son iguales que Git o Mercurial y no gestionan las ramas de la misma manera.
Con Git o Mercurial, una estrategia de rama por historia de usuario es mucho más fácil y eso es algo a tener en cuenta.
Si quieres más ideas, recuerda el post ¿Qué estrategia de control de versiones seguir en un equipo Scrum?
4. Gestión de tareas y trazabilidad
La idea principal de integración continua es llevar a cabo integraciones de código pequeñas y frecuentes.
Y para ello, qué mejor forma que dividir el trabajo en pequeños trozos.
Algo muy útil para controlar esto son las herramientas de gestión de tareas, como Jira (aquí te dejo un enlace a una serie de post sobre Jira) o Redmine.
Y otra cosa importante es conseguir trazabilidad entre las tareas o requisitos, y el código, cuál es el commit (la modificación) del control de versiones en el que dicho requisito se ha implementado.
Esto es indispensable siempre, pero muy útil cuando detectemos fallos en el código.
Así tendremos controlado en qué commit del código se ha dado el fallo y que hay implementado y que no.
—-
La semana que viene cerraremos esta serie de posts de integración continua con los últimos consejos sobre el tema.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
gracias Ana por esta serie de posts, son muy útiles.
Hola Ana, me pareció excelente esta serie de post, me aclararon muchísimo el concepto de integración continua.
Quería saber si has tenido o conoces como implementar IC en herramientas de BI como Qlikview?