Integración continua vs controlada

pablo santos luaces

@psluaces

@plasticscm

Sobre mi• Plastic SCM - founder• Coder• Blog writer… (a ratos) ;)

@psluaces

En el show de hoy…• La guerra de la integración

• Qué método es más «agile»?

Hay una guerra ahí fuera

Y hay que elegir un bando

Una guerra ahí fuera

Una guerra … de bandos… ;)

De opciones

Las opciones son• Integración continua

• Integración controlada

Las opciones son• Integración continua (piedra angular de agile)

• Integración controlada

Las opciones son• Integración continua != integración constante (!)

• Integración controlada

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

Qué es «mainline» development?• Trabajar en una única rama…

Qué es «mainline» development?• Trabajar en una única rama…

• ¿Es bueno?

Qué es «mainline» development?• Trabajar en una única rama…

• ¿Es bueno?

• Sí, si no hay otra opción … :P

¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama…

0

¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama…

¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama…

¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama…

¿Cómo reconocer «mainline»?• Fácil… sólo hay una rama…

¿Cómo reconocer «mainline»?• Si tu desarrollo tiene esta pinta… es lineal,

mainline, no paralelo!

Esto es desarrollo lineal

Y esto es desarrollo paralelo

Si no hay ramas… no es paralelo

Refuerzo positivo…

La batalla entre diferentes visiones

De dónde viene todo esto?

Ventajas del desarrollo paralelo• Romper la dependencia de tareas

Ventajas del desarrollo paralelo• Romper la dependencia de tareas

Ventajas del desarrollo paralelo• Puntos de partida conocidos – do not shoot a moving target!!!

Ventajas del desarrollo paralelo• Puntos de partida conocidos

Ventajas del desarrollo paralelo• Reforzar la creación de baselines estables

Ventajas del desarrollo paralelo• Código siempre bajo control

Ventajas del desarrollo paralelo• Detener la «bug spreading»

Ventajas del desarrollo paralelo• Detener la «bug spreading»

Ventajas del desarrollo paralelo• Trazabilidad mejorada

Ventajas del desarrollo paralelo• Keep the mainline … pristine

Integración continua – mainline glorificado

• The «poorman’s approach»

Refuerzo positivo…

Lo opuesto solía ser «big bang»

Lo opuesto solía ser «big bang»

Y para arreglarlo, integración frecuente

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

El futuro de CI

El futuro de CI

Feature branches

¿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

Integración controlada

http://drdobbs.com/architecture-and-design/205917960

main line

task 1140

task 1120

task 1121

baseline

Developer

baseline

Developer

task 1129

rebased

ReleaseEngineer

ReleaseEngineer

Integration Server For each taskto check whether it isvalid or not

Alternativas de integración

• El integrador hace merge• El integrador ejecuta tests• El integrador empaqueta y etiqueta

main line

task 1140

task 1120

task 1121

baseline

Developer

baseline

Developer

task 1129

rebased

ReleaseEngineer

Integration Server

Integration is just labelling and packing and running specific integration tests

Alternativas• Los desarrolladores hacen merge y ejecutan tests• El integrador empaqueta y etiqueta…• Evita mini-big-bangs• Recorta tiempos de compilación

main line

task 1140

task 1120

task 1121

baseline

Developer

baseline

Developer

task 1129

rebased

ReleaseEngineer

Integration Server

Integration is just promoting, labelling and packing and running specific integration tests

integration linePr

omot

e to

the

mai

nlin

e

Alternativas de integración

• Desarrolladores hacen merge y ejecutan tests• La línea principal se mantiene limpia

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.

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.

Distributed branch per task

Conclusión - Alternativas

Conclusión – Que no te limite

tu SCM

pablo santos luaces@psluaces

@plasticscm