El documento presenta una introducción a la integración continua realizada por Fran Reyes Perdomo y Yeray Darias Camacho. Explican que la integración continua implica construir el software con cada cambio realizado y tener un proceso que permita corregir errores tempranamente. También describen los pasos clave de la integragración continua como la construcción, pruebas y despliegue continuos para lograr feedback constante y mejorar la calidad del código.

1. Integración Continua
Fran Reyes Perdomo
Yeray Darias Camacho
viernes 23 de julio de 2010

2. ¿Quiénes somos?
viernes 23 de julio de 2010

3. Fran Reyes
fran.reyes.perdomo@gmail.com
Curso TDD de iExpertos.com
fran.reyes.perdomo
Participante de AgileCanarias
Coautor del libro de Carlos Blé
viernes 23 de julio de 2010

4. Yeray Darias
ydarias@gmail.com
@ydarias
Curso TDD de iExpertos.com
ydarias Participante de AgileCanarias
viernes 23 de julio de 2010

5. Introducción a IC
viernes 23 de julio de 2010

6. ¿Qué es la integración continua?
(en pocas palabras)
viernes 23 de julio de 2010

7. Construir el software con cada nuevo
cambio que se produce
viernes 23 de julio de 2010

8. Construir el software con cada nuevo
cambio que se produce
Pero en realidad es mucho más que
construir el software
viernes 23 de julio de 2010

9. Necesitamos un PROCESO que permita
corregir los errores antes de que sea
demasiado tarde
viernes 23 de julio de 2010

10. No se trata de desarrollar código, sino de
desarrollar código listo para producción
viernes 23 de julio de 2010

11. ¿Por qué falla la aproximación
clásica?
viernes 23 de julio de 2010

12. Diseño Construcción
Integración
viernes 23 de julio de 2010

13. Diseño Construcción
Integración ???
viernes 23 de julio de 2010

14. ¿Cómo se ha evolucionado hasta la
integración continua?
viernes 23 de julio de 2010

15. viernes 23 de julio de 2010

16. viernes 23 de julio de 2010

17. viernes 23 de julio de 2010

18. ¿Por dónde empezamos?
viernes 23 de julio de 2010

19. Construcción continua
viernes 23 de julio de 2010

20. Se debe realizar la construcción tan
pronto como se producen los
cambios en el código
viernes 23 de julio de 2010

21. Los errores detectados por el servidor
son errores que no llegan al cliente
viernes 23 de julio de 2010

22. Testing continuo
viernes 23 de julio de 2010

23. Toda construcción debe estar
verificada por un conjunto de
pruebas y tests unitarios
viernes 23 de julio de 2010

24. ¿Por qué testear al final no
funciona?
viernes 23 de julio de 2010

25. Es difícil estimar la calidad del
código existente
viernes 23 de julio de 2010

26. Los errores permanecen ocultos
viernes 23 de julio de 2010

27. Es difícil estimar el estado actual
del proyecto
viernes 23 de julio de 2010

28. Se pierden las oportunidades de
feedback
viernes 23 de julio de 2010

29. Inspección continua
viernes 23 de julio de 2010

30. Probablemente es el paso más
discutido de la integración continua
viernes 23 de julio de 2010

31. Su coste es tan bajo respecto a las
ventajas que no merece la pena
saltarse este paso
viernes 23 de julio de 2010

32. Este paso se puede flexibilizar con el
aumento de experiencia del equipo
viernes 23 de julio de 2010

33. Feedback cotinuo
viernes 23 de julio de 2010

34. Todo este proceso no tiene ningún
sentido si nadie se entera del estado
actual de la construcción
http://www.flickr.com/photos/igb
viernes 23 de julio de 2010

35. Hoy en día el correo sigue siendo el
medio más eficaz ... pero no es el
único que podemos usar
http://www.flickr.com/photos/igb
viernes 23 de julio de 2010

36. Despliegue continuo
viernes 23 de julio de 2010

37. Tener una versión siempre actualizada
añade una mayor transparencia
en el proceso de desarrollo
viernes 23 de julio de 2010

38. El valor que proporciona al cliente tener
siempre la última versión de la aplicación
es incalculable y no nos cuesta nada
viernes 23 de julio de 2010

39. Conclusiones
viernes 23 de julio de 2010

40. Se debe ir poco a poco, empezar
por algo sencillo e ir mejorando
http://www.flickr.com/photos/igb
viernes 23 de julio de 2010

41. Montar un servidor de IC es costoso,
pero mucho menos que arreglar
todos los errores unas semanas
antes de la entrega al cliente
http://www.flickr.com/photos/igb
viernes 23 de julio de 2010

42. Incluso con herramientas como
Maven o Hudson requiere de un
esfuerzo por parte del desarrollador
viernes 23 de julio de 2010

43. Se deben realizar frencuentes
commits del código que funciona
correctamente
viernes 23 de julio de 2010

44. Cuando se rompe una
construcción, se ha de reparar de
forma inmediata
viernes 23 de julio de 2010

45. Hay que escribir pruebas para el
código que estamos
desarrollando
viernes 23 de julio de 2010

46. Se debe lograr que la
construcción sea lo más rápida
posible
viernes 23 de julio de 2010

47. Hay que escribir nuevos tests
para cada bug que es reportado
viernes 23 de julio de 2010

48. Hay que estudiar mucho :-)
http://www.flickr.com/photos/igb
viernes 23 de julio de 2010

49. Hay que estudiar mucho :-)
http://www.flickr.com/photos/igb
viernes 23 de julio de 2010

50. Gracias por su
atención
viernes 23 de julio de 2010