Your SlideShare is downloading. ×
Cas 2011 Integración continua vs controlada
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Cas 2011 Integración continua vs controlada

3,564

Published on

Integración continua vs controlada. Los pros y contras de por qué usar CI y por qué "feature branches" (branch per task) es el futuro de la integración continua. Presentada en CAS2011 en Castellón.

Integración continua vs controlada. Los pros y contras de por qué usar CI y por qué "feature branches" (branch per task) es el futuro de la integración continua. Presentada en CAS2011 en Castellón.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,564
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
33
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Integración continua vs controlada pablo santos luaces @psluaces @plasticscm
  • 2. Sobre mi• Plastic SCM - founder• Coder• Blog writer… (a ratos) ;) @psluaces
  • 3. En el show de hoy…• La guerra de la integración• Qué método es más «agile»?
  • 4. Hay una guerra ahí fuera
  • 5. Y hay que elegir un bando
  • 6. Una guerra ahí fuera
  • 7. Una guerra … de bandos… ;)
  • 8. De opciones
  • 9. Las opciones son• Integración continua• Integración controlada
  • 10. Las opciones son• Integración continua (piedra angular de agile)• Integración controlada
  • 11. Las opciones son• Integración continua != integración constante (!)• Integración controlada
  • 12. Pero antes un paso atrás…SCM es importante en «agile»porque:• Collective code ownership• Continuous Integration• Mapeo entre tareas y código• Coordinación del equipo
  • 13. Qué es «mainline» development?• Trabajar en una única rama…
  • 14. Qué es «mainline» development?• Trabajar en una única rama…• ¿Es bueno?
  • 15. Qué es «mainline» development?• Trabajar en una única rama…• ¿Es bueno?• Sí, si no hay otra opción … :P
  • 16. ¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama… 0
  • 17. ¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama…
  • 18. ¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama…
  • 19. ¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama…
  • 20. ¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama…
  • 21. ¿Cómo reconocer «mainline»?• Si tu desarrollo tiene esta pinta… es lineal, mainline, no paralelo!
  • 22. Esto es desarrollo lineal
  • 23. Y esto es desarrollo paralelo
  • 24. Si no hay ramas… no es paralelo
  • 25. Refuerzo positivo…
  • 26. La batalla entre diferentes visiones
  • 27. De dónde viene todo esto?
  • 28. Ventajas del desarrollo paralelo• Romper la dependencia de tareas
  • 29. Ventajas del desarrollo paralelo• Romper la dependencia de tareas
  • 30. Ventajas del desarrollo paralelo• Puntos de partida conocidos – do not shoot a moving target!!!
  • 31. Ventajas del desarrollo paralelo• Puntos de partida conocidos
  • 32. Ventajas del desarrollo paralelo• Reforzar la creación de baselines estables
  • 33. Ventajas del desarrollo paralelo• Código siempre bajo control
  • 34. Ventajas del desarrollo paralelo• Detener la «bug spreading»
  • 35. Ventajas del desarrollo paralelo• Detener la «bug spreading»
  • 36. Ventajas del desarrollo paralelo• Trazabilidad mejorada
  • 37. Ventajas del desarrollo paralelo• Keep the mainline … pristine
  • 38. Integración continua – mainline glorificado• The «poorman’s approach»
  • 39. Refuerzo positivo…
  • 40. Lo opuesto solía ser «big bang»
  • 41. Lo opuesto solía ser «big bang»
  • 42. Y para arreglarlo, integración frecuente
  • 43. El futuro de CI • How can builds get faster? • How can broken builds be prevented?http://codicesoftware.blogspot.com/2008/03/continuous-integration-future.html
  • 44. El futuro de CI
  • 45. El futuro de CI
  • 46. Feature branches
  • 47. ¿Qué es una tarea? • ¿Usáis un issue tracker? • Cada entrada en el issue tracker Nota: las tareas son cortas…http://www.plasticscm.com/infocenter/quick-start/intro-task-driven-development.aspx
  • 48. Integración controladahttp://drdobbs.com/architecture-and-design/205917960
  • 49. Alternativas de integración• El integrador hace merge• El integrador ejecuta tests• El integrador empaqueta y etiqueta Integration Server For each task to check whether it is valid or not baseline main line baseline task 1120 task 1140 Release Engineer rebased Release Developer Engineer task 1121 task 1129 Developer
  • 50. Alternativas• Los desarrolladores hacen merge y ejecutan tests• El integrador empaqueta y etiqueta…• Evita mini-big-bangs• Recorta tiempos de compilación Integration Server baseline main line baseline task 1120 Integration is just task 1140 labelling and packing Release and running specific Engineer integration tests rebased Developer task 1121 task 1129 Developer
  • 51. Alternativas de integración• Desarrolladores hacen merge y ejecutan tests• La línea principal se mantiene limpia baseline main line baseline task 1120 Integration is just task 1140 promoting, labelling and packing and Release running specific Engineer line rebased integration tests Developer e main te to th Promo task 1121 task 1129 Developer integration line Integration Server
  • 52. En el mundo distribuido – integration manager workflow 1. The project maintainer pushes to their public repository. 2. A contributor clones that repository and makes changes. 3. The contributor pushes to their own public copy. 4. The contributor sends the maintainer an e-mail asking them to pull changes. 5. The maintainer adds the contributor’s repo as a remote and merges locally. 6. The maintainer pushes merged changes to the main repository.
  • 53. Dictator… 1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator. 2. Lieutenants merge the developers’ topic branches into their master branch. 3. The dictator merges the lieutenants’ master branches into the dictator’s master branch. 4. The dictator pushes their master to the reference repository so the other developers can rebase on it.
  • 54. Distributed branch per task
  • 55. Conclusión - Alternativas
  • 56. Conclusión –Que no te limite tu SCM
  • 57. pablo santos luaces @psluaces @plasticscm

×