Cómo trabajamos en Plastic SCM

#PAM2016 @psluaces @plasticscm

Cómo desarrollamos

Plastic SCM

PAM 2016#PAM2016

Pablo Santos Luaces@psluaces


VOY A CONTAR UNA HISTORIA


Un problema en producción

• Miércoles de hace unas semanas…• Recibimos un email de Telltale Games• Indicando que su servidor había tenido una

incidencia


Su control de versiones es


Desarrollamos Plastic SCMluchamos contra los Git, SVN, Clearcase, TFS y Perforces del mundo

• Arrancamos en 2005.• Equipo de 17 personas - https://www.plasticscm.com/company/team.html

• Clientes en más de 20 países.

https://www.plasticscm.com/company/team.html


Miércoles – primer día de incidencia

• 300 desarrolladores concurrentes usando Plastic• Repositorios de +4 TB (terabytes!)• Estudios en California y Asia (uso 24h)

• Soporte comenzó a estudiar los logs (¿algo puntual?)


Jueves – segundo día de incidencia

• Asignamos a un desarrollador• Paramos para él su sprint – intentando limitar el

impacto• Trabajamos en sprints de 2 semanas• Estábamos terminando el sprint 243


Estudiamos en detalle los logs y…

• Teníamos horas de margen hasta las 9 am en California (18:00).

• La carga se había multiplicado x4 desde Mayo – más proyectos, más descargas de assets.

• No había crash => pero dejaba de atender.• Nuestras pruebas de carga no lo habían

detectado…


Probamos en carga regularmentehttps://www.plasticscm.com/under-heavy-load

• Amazon• 1 server• 100s de clientes• Simulamos

operaciones de usuarios

https://www.plasticscm.com/under-heavy-load


Jueves – todavía sin solución

• Llegaron las 18h y todavía no sabíamos la causa con certeza

• Monitorizamos durante algunas horas más…


Viernes – tercer día de incidencia

• Se había producido otro reinicio durante la noche• Necesitábamos ya una solución urgente


Viernes – tercer día

• Finalmente probamos con nuestro servidor en lugar de el programa de prueba

• Matamos sockets abiertos y…• Encontramos un problema en el conector de

MySQL• Aislamos una versión “cercana” que funcionaba

bien• Teníamos hasta las 17h para una nueva release…


EL CICLO DE RAMA POR TAREAAhora comenzaba el ciclo “normal” para llegar tener una release


Issue tracker(TTS)

Task

Branch

Task validation

Merge

Atlassian Bamboo

A new branch

for each task

Several checkins

per task

Each finished

task is tested

prior to be

merged

Code Review

Validation

Each task is code reviewed

Each task is validated

Only tasks arriving here are merged

Monitors branches. Implement branch-per-task CI.On Windows and Linux:1. Builds2. Runs nunit3. Runs CLI tests4. Runs GUI tests

A new release

every 24 hours

Release testing

Windows (w2k to w8), Linux (several flavors), macosx: plus all backends (oracle, sqlserver,

mysql, sqlite, postgres) + combined win/linux + mac

>24h o

f

automa

ted

testin

g run

in

parall

el

VMWare

New tests

Taskdoc

Wiki


Nuestro ciclo de trabajo


Nuestro ciclo de trabajo… explicado


• ¿Cómo se alimenta?– Servicio vs producto– feedback, uservoice, features

adicionales requeridas por un nuevo cliente, ideas propias.

– + lista de bugs: detectados por el cliente e internamente.

• ¿Dónde se registra?– Excel, wiki, Evernote, etc…

• ¿Cómo se prioriza? – Objetivo: entrega temprana y

continua de valor al cliente.

Backlog


Backlog – también de incidencias

• Como hemos visto, una incidencia urgente también altera el plan

• El objetivo es evitar a toda costa las incidencias para no alterar el plan


¿Cómo estimamos?

• Nosotros usamos PERT para estimar:• Para cada tarea, en horas:–Mejor caso -> si todo te va bien– Peor caso– Caso más probable

• Ejemplo: 4h, 10h, 6h -> con esto se calcula la estimación

• OBJETIVO: controlar el optimismo exagerado.

Para saber más


¿Cómo gestionamos las tareas?

• Issue tracker – nosotros tenemos el nuestro propio TTS, pero hay muchos: JIRA, Bugzilla, Mantis, OnTime, etc, etc. Lo importante es tener uno.

• En el issue tracker metemos todo lo que se hace (ojo, no cajón de sastre de ideas, eso no funciona): bugs, nuevas features, refactors, etc


¿Qué pinta tiene una tarea en nuestro TTS?


TTS


User Pain = objetivizar la prioridad de los bugs

• Lo usamos para intentar ser menos subjetivos (no usar “prioridad”, que siempre es alta).

• Da un valor del 1 al 100 en base a 3 preguntas:


User pain controlado = proyecto manejable

Evolución del “user pain” total – a nosotros no nos ha funcionado usar el “tts” como “descarga conciencias”


Foco en bugs detectados por clientes


Si no es automático… no es un test ;-)

• TDD – test driven development -> escribe tests unitarios antes que el código.

• En nuestro caso: escribe tests antes de terminar la tarea al menos, que TODO vaya probado.

• Cambio de mentalidad: probar es probar con tests automáticos, probar a mano es jugar al software, los pros no lo hacen así!!!


Code Review

• Revisamos TODAS las tareas que hacemos.• Ninguna tarea va sin code review.• Esto ayuda a mantener la calidad del código.• Sirve de training para los nuevos (les vas tutorizando todo el

rato, no te llevas la sorpresa).

• Herramientas: primero un buen control de versiones, luego un buen sistema de diff (Plastic :P, pero tb Git y otros + Gerrit ó SmartBear ó GitHub con sus reviews integradas, etc).


¿Cómo era la code review de hoy?

• Era una situación excepcional porque no era un cambio en nuestro código

• El revisor estudió todos los cambios del conector entre nuestra antigua version y la nueva


Code Review


Validar = aplicar visión de producto a cada tarea

• Cada tarea la validamos: es decir, alguien prueba a mano que hace lo que debe hacer.

• NO es testing como tal, es más comprobar que el resultado tiene sentido, como producto!

• Es como un “exploratory test” pero corto.

• ¿Qué es un exploratory test?

Para saber más


Exploratory testing


Pero la validación de hoy también era diferente

En este caso la validación también era diferente• A) Montamos un entorno de tests de carga• B) Simulamos de nuevo los fallos


Branch per task

• Muy fácil: para cada tarea en el issue tracker, creamos una rama en el control de versiones!

• De ese modo eres libre de hacer tantos checkins como quieras.

Pero: ¡¡son muchas ramas!!, ¿no? -> sí, pero no pasa nada, a menos que uses SVN o algo así ;-)


Branch per task

• De ese modo, tu desarrollo en vez de ser así:


Branch per task• Será así: con líneas paralelas


Branch per task• Y todas esas ramas al

final se juntan, se MEZCLAN, se integran (diferentes nombres para lo mismo).

• Tras el merge se compila el código, se prueba, y se hace una nueva release.


Release – el latido del proyecto

• En nuestro caso tenemos un ingeniero que se encarga 100% de hacer releases. Es el build master.

• Cada release pasa montones de test: 40h paralelizadas en un montón de VMWares para que tarde menos de 3h en probarse!

• Pasamos tests unitarios, smokes + tests gráficos.

• Intentamos hacer una release CADA DÍA: por eso las releases son tan importantes, son el latido del proyecto!! Es lo que hace que todo funcione, que nos demos prisa con las reviews, las validaciones.

• El objetivo de todo el ciclo es lanzar software que no se rompa… que no falle!!


Estilos de integración – integrator o equipo

Integrador• Ventajas

– Sentimiento de responsabilidad sobre las releases de alguien (en lugar de muchos con “esto no es cosa mía”).

– Liberas de la responsabilidad al equipo (puede ser bueno con juniors).

– Marca el “ritmo” empujando para sacar releases.

– El “integrator” trabaja todo el rato en mejorar y automatizar.

• Desventajas– Tareas “a medio cerrar” porque la gente

confunde el “done”.– Puede ser un freno a automatizar porque ya

cuentas con que alguien se encarga…

Cada uno hace merge de lo suyo• Ventajas

– No hay un “cuello de botella”.– Se puede repartir el trabajo y la

responsabilidad.– Puede llegar a forzar más automatización –

no quieres a nadie haciendo release a mano.

• Desventajas– Todo el mundo hace merges (a veces es

una desventaja, juniors).– No hay un “supervisor final” de cada merge

a main.


3 pilares - tests, control de versiones y tareas

• El build y los tests condicionan el ciclo de release.• Hemos visto en clientes builds de +10h –> no

puedes hacer CI.• También tests muy lentos o frágiles -> condicionan

automatización.• En nuestro caso: seguimos teniendo tests frágiles

–> punto clave a mejorar.


Nuestro ciclo ideal = branch per task + CI (o delivery)


Información interesante

• ¿Qué pinta tienen nuestros GUI tests? Mira: https://youtu.be/7mEqkUaMxJI• Todo sobre branch per task en nuestra web:

https://www.plasticscm.com/branch-per-task-guide/index.html• Nuestro ciclo de trabajo explicado en nuestro blog:

– http://codicesoftware-es.blogspot.com.es/2012/07/ciclo-de-trabajo-de-codice-software-i.html– http://codicesoftware-es.blogspot.com.es/2012/07/ciclo-de-trabajo-de-codice-software-ii.html– http://codicesoftware-es.blogspot.com.es/2012/08/ciclo-de-trabajo-de-codice-software-iii.html– http://codicesoftware-es.blogspot.com.es/2012/08/ciclo-de-trabajo-de-codice-software-iv.html– http://codicesoftware-es.blogspot.com.es/2012/08/ciclo-de-trabajo-de-codice-software-v.html– http://codicesoftware-es.blogspot.com.es/2012/08/ciclo-de-trabajo-de-codice-software-vi.html

https://youtu.be/7mEqkUaMxJI

https://www.plasticscm.com/branch-per-task-guide/index.html


Conclusión

• Pudimos entregar la version antes de las 17h• Y no se volvieron a registrar incidencias• El conector gestionaba mal ciertos errores y eso

provocaba otros… pero eso es ya otra historia :-)


Preguntas @psluaces

Cómo trabajamos en Plastic SCM

Software

Transcript of Cómo trabajamos en Plastic SCM