Si ya conoces Jenkins, y trabajas regularmente con dicha herramienta, o practicas la integración continua, ahórrate este post.
Este post está pensando para aquellos que no van a trabajar directamente con Jenkins, pero quieren dejar de poner caras raras y mirar para otro lado cada vez que oyen hablar de esta herramienta. O de la integración continua. Para gente de dirección, interesados en la tecnología, comerciales, inversores en empresas tecnológicas, etc., que en 10 min quieran quedarse con la idea principal. Y también para aquellos que si que puede que algún día quieran implantar la integración continua y quieren empezar por aquí el camino que les queda por recorrer para conocer realmente esta práctica.
Este post pretende enseñarte qué te puede aportar utilizar Jenkins. Y qué beneficios puedes sacar de la integración continua. Así que ¡vamos allá!
—–
En pocas líneas…¿Qué es la integración continua? (Aquella buena práctica que facilita Jenkins)
La integración continua es una práctica de desarrollo software donde los miembros del equipo integran su trabajo frecuentemente (como mínimo una vez al día, aunque normalmente se realizan múltiples integraciones diarias).
Cada integración se verifica compilando el código fuente y obteniendo un ejecutable (a esto se le llama build, y debe hacerse de forma automatizada).Además también se pasan las pruebas y métricas de calidad para detectar los errores tan pronto como sea posible.
Es muy recomendable hacer builds periódicamente y comprobar que funcionen correctamente, para conseguir un producto final más fiable, con menos fallos en producción.
Al integrar frecuentemente el código, y con la ayuda de herramientas como Jenkins, puedes saber el estado del software en todo momento. Sabes qué funciona, qué no y qué errores hay.
También puedes monitorizar la calidad del código y su cobertura de pruebas. La integración continua incluso puede ayudarte a reducir la deuda técnica (aquí puedes saber más sobre la deuda técnica) y mantener los costes bajos.
Así que… ¿Cómo conseguir todo esto? ¡Veamos qué es Jenkins!
Jenkins
Jenkins es un servidor de integración continua, gratuito, open-source y actualmente uno de los más empleados para esta función. Además es muy fácil de utilizar. Lo puedes descargar desde aquí.
Esta herramienta, proviene de otra similar llamada Hudson, ideada por Kohsuke Kawaguchi, que trabajaba en Sun. Unos años después de que Oracle comprara Sun, la comunidad de Hudson decidió renombrar el proyecto a Jenkins, migrar el código a Github y continuar el trabajo desde ahí. No obstante, Oracle ha seguido desde entonces manteniendo y trabajando en Hudson.
Y te preguntarás… ¿Qué papel juega Jenkins dentro del proceso de integración continua?
La base de Jenkins son las tareas, donde indicamos qué es lo que hay que hacer en un build. Por ejemplo, podríamos programar una tarea en la que se compruebe el repositorio de control de versiones cada cierto tiempo, y cuando un desarrollador quiera subir su código al control de versiones, este se compile y se ejecuten las pruebas.
Si el resultado no es el esperado o hay algún error, Jenkins notificará al desarrollador, al equipo de QA, por email o cualquier otro medio, para que lo solucione. Si el build es correcto, podremos indicar a Jenkins que intente integrar el código y subirlo al repositorio de control de versiones.
Pero la cosa no queda ahí. Una de las cosas buenas que tiene Jenkins es que además de poder ayudarte a integrar el código periódicamente, puede actuar como herramienta que sirva de enlace en todo el proceso de desarrollo.
Desde Jenkins podrás indicar que se lancen métricas de calidad y visualizar los resultados dentro de la misma herramienta. También podrás ver el resultado de los tests, generar y visualizar la documentación del proyecto o incluso pasar una versión estable del software al entorno de QA para ser probado, a pre-producción o producción.
Por ejemplo, en esta imagen puedes ver una zona del cuadro de mando de Jenkins, donde aparecen las distintas tareas que se han llevado a cabo, la duración, cuándo se produjo el último fallo… 
Terminando: Cosas a tener en cuenta para llevar a cabo la integración continua con Jenkins
En primer lugar, es imprescindible tener un repositorio de control de versiones (mercurial, git, svn, plastic, etc). Todo lo necesario para realizar el build debe estar allí (código, scripts de test, librerías de terceros…).
Sin esto, no podremos sacar el máximo partido a Jenkins, ya que uno de sus puntos fuertes es que es capaz de monitorizar el control de versiones y actuar ante cualquier cambio.
Además, para que la integración continua funcione, es imprescindible que el equipo esté mentalizado y comprometido.
Por ejemplo (y puede que de tanto repetirlo se haga pesado, pero créeme, hay veces que esto no se sigue. Fíjate en este post, que cuenta una experiencia real lo importante que es el control de versiones ) todo el código debe subirse al control de versiones. Los desarrolladores deben subir su trabajo periódicamente al repositorio. Además los proyectos tienen que tener un proceso de build automático, y si un build falla, lo más prioritario debe ser arreglarlo.
Aún así, y sin dudarlo, con todo lo que nos aporta esta buena práctica, merece la pena llevarla a cabo. Y merece la pena utilzar Jenkins.
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
Gran post. Nos sorprenderíamos al ver cuanta gente «Programadora» no conoce este tipo de herramientas.
Gracias!
Tal vez trabajo en un ambito donde no se utilizaba esas cosas? Es un delito acaso. Fea forma de hablar de colegas….
Ni puta falta que hace !!! Si los administradores sistemas hicierais bien vuestro trabajo no existirian estas herramientas.
JAJAJA… ser un administrador no solo significa hacer tareas rutinarias, el kernel también es programación mucho mas complicada, si sabeis que significa ci/cd es que sois de los tios como yo que se leen cada cosa nueva que llega y les parece lo mejor del mundo porque soluciona problemas que antes tenían que resolver personas que nunca han tocado codigo ni conocen las bases de la programación, ni la cuestión de que el lenguaje al final es solo codigo de maquina en ensamblador sujeto a fallos, fallos propios de builds(compiladores que fallan por una actualizacion de herramientas de compilación… ahhh no lo sabia?, los errores ocurren y hay demasiados para taparlos todos y echarle la culpa a los demás, en vez de criticar y ya que son desarrolladores avanzados de codigo deberían desarrollar una nueva manera de colaboración en sus empresas la programación hoy en día le sirve mas a un economista o incluso a mcgiver…. no entendeís la clase de navaja que hay en el cyberespacio. y una de esas navajas es jenkins… o que lo digan sus empleadores, es mucho mas productivo porque es mas facil, al ser mas facil es aun mas automatizable porque hay diversas herramientas para hacer que nuestro codigo vaya como un reloj suizo ci-cd primer actor git- jenkins :), eso da a cualquier desarrollador mucho poder. y mas a los directivos si se los enseñaran… directivos que no saben programación son una empresa muy poco interesada en surgir.
Gracias por divulgar tecnologías para el gran público 😀
El pejiguera que llevo dentro me obliga a decir: «Todo lo necesario para realizar el build debe estar [en el control de versiones] (código, scripts de test, librerías de terceros…).» Lo de las librerías de terceros no es cierto, puede haber scripts que las obtengan (o procesos de construcción con herramientas como maven).
Gracias de nuevo!
Totalmente de acuerdo.
En mi empresa lo comenté y prefieren no hacer nada de ci, test ni control de calida, ej. Sonar. Asi nos va!!!
No he leído el artículo, conozco bien la integración continua, pero me llama la atención que se haya utilizado Jenkins como ejemplo. Personalmente considero que tiene un mal acabado y lo considero bastante flojo. Si se busca algo equivalente en software libre mucho mejor CruiseControl. De acuerdo que exige picar mucho más XML frente a tanto asistente en Jenkins pero el resultado es bastante mejor.
Si se prefiere un software comercial de integración continua TeamCity es una excelente apuesta. La versión gratuita es interesante para grupos pequeños.
Hola Ana, este tema de la integracion continua no lo he manejado, sin embargo, me he documentado un poco al respecto, e incluso estuve en una empresa donde intentaron implementar la integracion continua con Hudson, sin resultados favorables, pero me preguntaba si recomiendas que se utilice Jenkins o Hudson, si es que tiene una ventaja el uno del otro, e incluso, si Maven participa en con alguno de los dos (creo que Hudson trabaja en conjunto con Maven).
Gracias, excelente post!!!!!
Les recomiendo Jenkins es la mejor opción en integración continua.
Hola, Donde yo trabajo tienen implementado CI, utilizamos: maven, jenkins y git (la notifiaciones del build de Jenkins se envian al chat de Skype) y todo ha funcionado re bien.
Puede ser un poco complicado la configuración y crear la lógica de como funcionarán las herramientas tomadas de la mano, Pero luego de tener la integración creanme que es un alivio para los proyectos.
gracias por el post
Hola Eddy, tendras un correo para poder contactarte. Quisiera saber un poco mas sobre tu experiencia en integracion.
Mi correo es jonavillegas@gmail.com
Buenos días,
Quisiera integrar Jenkins para un desarrollo de una Web API realizada en .Net. Tendrías los pasos para realizar esta configuración?
Para el front-end pude configurar angular CLI + Jenkins + PhantomJS, pero para el back-end que estaría hecho con web api de .net, no se como hacerlo.
Muy buen post!
Muchas gracias, saludos,
Adrian
Excelente post!!! directo al punto. Muchas gracias.
Ana, muy bien explicado 🙂 os dejo mi pequeño aporte en la materia, un pequeño tutorial de cómo instalar Jenkins sobre Ubuntu server, espero que a alguien le sea de utilidad:
Cómo instalar Jenkins
Por cierto, en algún comentario se preguntaba por Hudson, Hudson empezó como proyecto libre, luego fue «comprado» y alejado de la comunidad, con lo que la comunidad hizo un «fork» de Hudson y lo llamó Jenkins; con el paso de los años Jenkins se ha comido la cuota de mercado dado que ha evolucionado (tanto el core como los plugins) más y mejor que Hudson. ¡Open Source al poder!
LLevar a cabo integración continua porque «es guay» es una enorme estupidez. Hay casos, muchísimos, donde no tiene ningún sentido. Solo debe llevarse a cabo en los proyectos donde sea necesario o aconsejable por algún motivo.
Hola que tal! me interesa saber cuales serian esos casos porfavor, gracias por el dato, apenas me estoy documentando en Integracion Continua, y quisiera saber los pros y los cons, gracias.
La integración continua en sí es SIEMPRE un plus. A lo que se refiere Alb. es que si estamos trabajando en un proyecto chico o de pocos desarrolladores, entonces quizas sea demasiado agregar CI porque es algo más de lo que hay que estar pendientes y mantener.
Muy interesante ya que hoy en día es imprescindible la automatización e integración continua.
En la empresa que trabajo aún se utiliza Sonar y cuesta mucho ampliar el campo a nuevos métodos de trabajo.
Hola, entendía que Jenkins tambien se ocupaba del código almacenado en el motor de bases de datos o las configuraciones de manera que verdaderamente se pueda hacer integración continua.
No es asi =
Buen día …
En mi empresa utilizamos TFS de Visual Studio para el control de versiones, no manejamos la Integración continua pero algo hemos iniciado … actualmente están planificando migrar a herramientas Open Source como Git, Jenkins… nuestros sistemas en su mayoría son punto net, otras pocas en Java, PHP y finalmente android , ios.
Como repositorio se esta probando GitLab y se ha mencionado Jenkins para la integración continua.
Me gustaría recibir información de este entorno y experiencias que puedan ayudar en este proceso de migración.
mi experiencia es mínima en productos Open Source pero no rehúyo a lo desconocido.
gracias.
Buenas
Necesito ayuda urgente. Estoy desesperado. Parece que jenkins no me coge los cambios en producción. Me da fallos en líneas que no existen, que acabo de borrar. No tiene sentido porque en los otros entornos me compila bien y no me da este fallo. Estoy desesperado. Gracias de antemano. Un saludo
Gran post . Gracias
Buen aporte para los que estamos empezando en esto. Gracias!