C R I S T I A N R O M E R O M AT E S A N ZC O L E G I A D O 1 0 5 C O L E G I O I N G E N I E R O S I N F O R M ÁT I C O S

Integración continua: el coste de oportunidad

Punto de partida

1. Desarrollos de aplicaciones heterogéneos con estructuras diferentes.

2. Librerías usadas sin soporte actual y con bugs conocidos en productos subidos a producción.

3. Escasez de pruebas unitarias/ integración en desarrollos existentes.

4. Trazas de logs y gestión de excepciones poco clara entre capas.

5. Fases de desarrollo cortas, fases de mantenimiento grandes (por no decir infinitas).

6. Dificultad a la hora de acometer una refactorización.

7. Desarrollo nuevas funcionalidades generan errores en las ya existentes.

Problemática

Si has llegado a esta diapositiva, es que te preocupa el futuro de las aplicaciones dentro de tu entidad.

- La mala noticia son los graves problemas que hemos detectado.

- La buena noticia es que tenemos solución para los posibles dolores de cabeza que generaría los problemas expuestos anteriormente.

Bienvenido a la integración continua

Que es integración continua?

“The essence of my philosophy to software delivery is to build software so that it is always in a state where it could be put into production. We call this Continuous Delivery because we are continuously running a deployment pipeline that tests if this software is in a state to be delivered.”

Definición para toda la familia: la integración continua se basa en tener siempre subido código a nuestro repositorio que pueda ser puesto en producción, el proceso se encarga de ver si nuestro software cumple una seria de requisitos (pruebas, calidad etc..). Caso positivo Despliegue automático en entorno

Caso negativo Correos a los implicados para corregir los errores

Reingeniería de procesos desarrollo del software

1. En los 90 se desarrollaba software de manera atómica y desarrollos basados en clientes pesados.

2. En los años 2000 el auge web trae los desarrollos basados en clientes ligeros con servidores pesados

3. A finales de los años 2000 no solo interesa la web: Servicios Rest, móviles, web… Necesitamos piezas desacopladas y probadas. Ahora

tienen que ser muy reutilizables. Necesitamos un punto central donde se prueba y se

analice todo el código de nuestra entidad para garantizar a quien nos consume las reglas del juego y que todo funciona correctamente.

Necesitamos equipos de expertos concienciados en la necesidad de crear código de calidad.

Símil tecnológico

Madrid Barcelona

A favor En contra• Yo conozco mi coche.• Soy el mejor conduciendo

con este vehículo.• Esto funciona y no lo

cambio.• Sirve para ir de un sitio A

a otro sitio B como otros coches.

• Puedo llegar mas rápido a los sitios.

• Mas comodidad para conductor y acompañantes.

• Menor consumo.• Mayor seguridad en

transporte.• Menor siniestralidad

Símil real uso integración continua

Programación Sin CI Programación Con CI

• Yo conozco mi código• Soy el mejor programando con

mi metodología• Esto funciona y no lo cambio.• Hago lo mismo que el resto con

la “misma calidad”• Mi código es mi tesoro (aunque

el 90% sea copy paste )• He probado y funciona

“perfectamente”

• Todos conocen mi código (maven/gradle, pruebas, frameworks)

• Somos lo mejores desarrollando con una metodología real y tangible

• Menor consumo de “recursos”: equipos pequeños pero con mucha formación.

• Uso recursos en la nube, me centro en mi negocio y en lo que soy bueno.

• Todo se prueba para garantizar su funcionamiento y para facilitar refactorizaciones futuras

Consecuencias de desarrollos sin integración continua

1. No existe un sitio común donde se valide la herramienta. En local cada uno “certifica” que ha terminado y funciona correctamente

2. La realidad es otra: códigos con muchas líneas, con muchos if y poco claros debido a que nadie valida su calidad, solo el propio desarrollador.

3. No se conoce la versiones de las librerías que se usan, ni tan siquiera si estas funcionan correctamente.

4. En mi máquina esto me “funciona”. Se suba código a repositorios que no funciona y sin todas las dependencias: gasto de tiempo y dinero en algo que no aporta valor.

5. Tenemos desarrollos grandes donde cada cambio supone romper cosas que “funcionaban”. Mantenimiento infinito con gran coste.

6. Curva de aprendizaje enorme para nuevos desarrolladores: el conocimiento nunca reside en el código solo en la cabeza de los equipos

Argumentos en contra de su uso

1. Hacer pruebas y comprobar la integridad de nuestros proyectos consume tiempo en algo que no aporta funcionalidad a nuestro proyecto. Resultado: Gran coste de mantenimiento

2. Yo puedo programarlo todo, no me fio en el rendimiento de estas nuevas metodologías y herramientas (complejo del super-programador) Resultado: Reinventamos ruedas cada dia que nos ponemos delante de nuestro IDE favorito.

3. Esta metodología en otras entidades se puede usar pero mi empresa es diferente Resultado: Tiempos de desarrollo infinitos y poca calidad en código. Programemos entonces en ensamblador !!!!

4. No conozco estas nuevas herramientas y por lo tanto me será mas complicado avanzar Resultado: desarrollos repetitivos con programadores poco motivados.

Soy Jenkins vengo a poner orden

Os presento a nuestro nuevo amigo a partir de ahora:

JENKINS: Para servirles

Jenkins: y quien es el ???

1. Es la herramienta de integración continua de libre distribución mas usada en las empresas de todo el mundo. (Dell o Sony, proyectos de código abierto como GitHub y organizaciones varias como pueden ser Ebay, Facebook etc…)

2. Compila nuestro código y lanza un serie de tareas que nosotros le digamos: Lanzamiento de test unitarios y de integración Pruebas de carga Pruebas de integración con otros artefactos que me usan o uso para

ver que no rompe nada que ya estaba funcionando. Comprobación del numero de líneas que prueban nuestros test. Comprobaciones de calidad de código Envió de los posibles errores a las personas que lo han

realizado/responsables. Puesta automática de nuestros desarrollos en servidores/ entornos

de pruebas para tener siempre subido el ultimo código estable. TOMCAT, WAS, TESTFAIRY, TESTFLIGHT ETC….

3. A partir de ahora es un miembro mas del equipo y como tal debe de ser mimado por todos

Jenkins: Interfaz de usuario

Tareas a realizar con el código de la entidad.

Jenkins: Interfaz de usuario

Dependencias entre tareas

Jenkins: Interfaz de usuario

Cobertura de los test

Jenkins: Interfaz de usuario

Resultado de las ejecuciones

Jenkins: Interfaz de usuario

Resultado de las ejecuciones

Jenkins: Interfaz de usuario

Ejemplo subida automática a Testflight

Jenkins: Interfaz de usuario

Subida automática al servidor de desarrollo

Uso local/uso en la nube

Jenkins instalación versus Cloudbeed Jenkins puede ser usado como instalación local, como

servicio o bien corriendo en cualquier servidor de aplicaciones.

Existe una versión en la nube con todo lo necesario para tener entornos reales sin necesidad de mucho conocimiento.

Elegir uno u otro dependerá si queremos primar que nuestro código nunca salga de la entidad o bien queremos minimizar costes de manera enorme, donde solo tendremos que preocuparnos de usar, nunca de instalar.