Cómo trabajamos en Plastic SCM

#PAM2016

1. Cómo desarrollamos Plastic SCM PAM 2016 #PAM2016 Pablo Santos Luaces @ psluaces

2. Voy a contar una historia

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

4. Su control de versiones es

5. Desarrollamos Plastic SCM luchamos 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.

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

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

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

9. Probamos en carga regularmente https://www.plasticscm.com/under-heavy-load Amazon 1 server 100s de clientes Simulamos operaciones de usuarios

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

11. Viernes – tercer día de incidencia Se había producido otro reinicio durante la noche Necesitábamos ya una solución urgente

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

13. El ciclo de rama por tarea Ahora comenzaba el ciclo “normal” para llegar tener una release

14. Nuestro ciclo de trabajo

15. Nuestro ciclo de trabajo… explicado

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

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

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

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

20. ¿ Qué pinta tiene una tarea en nuestro TTS?

21. TTS

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

23. User pain controlado = proyecto manejable Evolución del “user pain” total – a nosotros no nos ha funcionado usar el “ tts ” como “ descarga conciencias ”

24. Foco en bugs detectados por clientes

25. 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í!!!

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

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

28. Code Review

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

30. Exploratory testing

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

32. 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í ;-)

33. Branch per task De ese modo, tu desarrollo en vez de ser así:

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

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

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

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

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

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

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

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

42. 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 :-)

43. Preguntas @ psluaces