Breve descripción de los problemas existentes en el 90% de las empresas españolas que crean software al no utilizar técnicas de integración continua.

1. C R I S T I A N R O M E R O M A T E S A N Z
C 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

2. 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.

3. 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

4. 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

5. 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.

6. 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

7. 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

8. 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

9. 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.

10. Soy Jenkins vengo a poner orden
Os presento a nuestro nuevo amigo a partir de ahora:
JENKINS:
Para servirles

11. 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 

12. Jenkins: Interfaz de usuario
Tareas a realizar con el código de la entidad.

13. Jenkins: Interfaz de usuario
Dependencias entre tareas

14. Jenkins: Interfaz de usuario
Cobertura de los test

15. Jenkins: Interfaz de usuario
Resultado de las ejecuciones

16. Jenkins: Interfaz de usuario
Resultado de las ejecuciones

17. Jenkins: Interfaz de usuario
Ejemplo subida automática a Testflight

18. Jenkins: Interfaz de usuario
Subida automática al servidor de desarrollo

19. 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.