Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
#PAM2016 @psluaces @plasticscm
Cómo desarrollamos
Plastic SCM
PAM 2016
#PAM2016
Pablo Santos Luaces
@psluaces
#PAM2016 @psluaces @plasticscm
VOY A CONTAR UNA HISTORIA
#PAM2016 @psluaces @plasticscm
Un problema en producción
• Miércoles de hace unas semanas…
• Recibimos un email deTelltale...
#PAM2016 @psluaces @plasticscm
#PAM2016 @psluaces @plasticscm
Su control de versiones es
#PAM2016 @psluaces @plasticscm
Desarrollamos Plastic SCM
luchamos contra los Git, SVN, Clearcase,TFS y Perforces del mundo...
#PAM2016 @psluaces @plasticscm
Miércoles – primer día de incidencia
• 300 desarrolladores concurrentes usando Plastic
• Re...
#PAM2016 @psluaces @plasticscm
Jueves – segundo día de incidencia
• Asignamos a un desarrollador
• Paramos para él su spri...
#PAM2016 @psluaces @plasticscm
Estudiamos en detalle los logs y…
• Teníamos horas de margen hasta las 9 am en California
(...
#PAM2016 @psluaces @plasticscm
Probamos en carga regularmente
https://www.plasticscm.com/under-heavy-load
• Amazon
• 1 ser...
#PAM2016 @psluaces @plasticscm
Jueves – todavía sin solución
• Llegaron las 18h y todavía no sabíamos la causa con certeza...
#PAM2016 @psluaces @plasticscm
Viernes – tercer día de incidencia
• Se había producido otro reinicio durante la noche
• Ne...
#PAM2016 @psluaces @plasticscm
Viernes – tercer día
• Finalmente probamos con nuestro servidor en lugar de el
programa de ...
#PAM2016 @psluaces @plasticscm
EL CICLO DE RAMA PORTAREA
Ahora comenzaba el ciclo “normal” para llegar tener una release
#PAM2016 @psluaces @plasticscm
Issue tracker
(TTS)
Task
Branch
Task
validation
Merge
Atlassian
Bamboo
A
new
branch
for
eac...
#PAM2016 @psluaces @plasticscm
Nuestro ciclo de trabajo
#PAM2016 @psluaces @plasticscm
Nuestro ciclo de trabajo… explicado
#PAM2016 @psluaces @plasticscm
• ¿Cómo se alimenta?
– Servicio vs producto
– feedback, uservoice, features
adicionales req...
#PAM2016 @psluaces @plasticscm
Backlog – también de incidencias
• Como hemos visto, una incidencia urgente también altera ...
#PAM2016 @psluaces @plasticscm
¿Cómo estimamos?
• Nosotros usamos PERT para estimar:
• Para cada tarea, en horas:
– Mejor ...
#PAM2016 @psluaces @plasticscm
¿Cómo gestionamos las tareas?
• Issue tracker – nosotros tenemos el nuestro propioTTS, pero...
#PAM2016 @psluaces @plasticscm
¿Qué pinta tiene una tarea en nuestroTTS?
#PAM2016 @psluaces @plasticscm
TTS
#PAM2016 @psluaces @plasticscm
User Pain = objetivizar la prioridad de los bugs
• Lo usamos para intentar ser menos subjet...
#PAM2016 @psluaces @plasticscm
User pain controlado = proyecto manejable
Evolución del “user pain” total – a nosotros no n...
#PAM2016 @psluaces @plasticscm
Foco en bugs detectados por clientes
#PAM2016 @psluaces @plasticscm
Si no es automático… no es un test ;-)
• TDD – test driven development -> escribe tests uni...
#PAM2016 @psluaces @plasticscm
Code Review
• RevisamosTODAS las tareas que hacemos.
• Ninguna tarea va sin code review.
• ...
#PAM2016 @psluaces @plasticscm
¿Cómo era la code review de hoy?
• Era una situación excepcional porque no era un cambio en...
#PAM2016 @psluaces @plasticscm
Code Review
#PAM2016 @psluaces @plasticscm
Validar = aplicar visión de producto a cada tarea
• Cada tarea la validamos: es decir, algu...
#PAM2016 @psluaces @plasticscm
Exploratory testing
#PAM2016 @psluaces @plasticscm
Pero la validación de hoy también era diferente
En este caso la validación también era dife...
#PAM2016 @psluaces @plasticscm
Branch per task
• Muy fácil: para cada tarea en el issue tracker, creamos una rama en
el co...
#PAM2016 @psluaces @plasticscm
Branch per task
• De ese modo, tu desarrollo en vez de ser así:
#PAM2016 @psluaces @plasticscm
Branch per task
• Será así: con líneas paralelas
#PAM2016 @psluaces @plasticscm
Branch per task
• Y todas esas ramas al final
se juntan, se MEZCLAN,
se integran (diferente...
#PAM2016 @psluaces @plasticscm
Release – el latido del proyecto
• En nuestro caso tenemos un ingeniero que se encarga 100%...
#PAM2016 @psluaces @plasticscm
Estilos de integración – integrator o equipo
Integrador
• Ventajas
– Sentimiento de respons...
#PAM2016 @psluaces @plasticscm
3 pilares - tests, control de versiones y tareas
• El build y los tests condicionan el cicl...
#PAM2016 @psluaces @plasticscm
Nuestro ciclo ideal = branch per task + CI (o delivery)
#PAM2016 @psluaces @plasticscm
Nuestro ciclo ideal = branch per task + CI (o delivery)
#PAM2016 @psluaces @plasticscm
Información interesante
• ¿Qué pinta tienen nuestros GUI tests? Mira: https://youtu.be/7mEq...
#PAM2016 @psluaces @plasticscm
Conclusión
• Pudimos entregar la version antes de las 17h
• Y no se volvieron a registrar i...
#PAM2016 @psluaces @plasticscm
Preguntas @psluaces
Próxima SlideShare
Cargando en…5
×

Cómo trabajamos en Plastic SCM

356 visualizaciones

Publicado el

#PAM2016

Publicado en: Software

Cómo trabajamos en Plastic SCM

  1. 1. #PAM2016 @psluaces @plasticscm Cómo desarrollamos Plastic SCM PAM 2016 #PAM2016 Pablo Santos Luaces @psluaces
  2. 2. #PAM2016 @psluaces @plasticscm VOY A CONTAR UNA HISTORIA
  3. 3. #PAM2016 @psluaces @plasticscm Un problema en producción • Miércoles de hace unas semanas… • Recibimos un email deTelltaleGames • Indicando que su servidor había tenido una incidencia
  4. 4. #PAM2016 @psluaces @plasticscm
  5. 5. #PAM2016 @psluaces @plasticscm Su control de versiones es
  6. 6. #PAM2016 @psluaces @plasticscm 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.
  7. 7. #PAM2016 @psluaces @plasticscm Miércoles – primer día de incidencia • 300 desarrolladores concurrentes usando Plastic • Repositorios de +4TB (terabytes!) • Estudios en California y Asia (uso 24h) • Soporte comenzó a estudiar los logs (¿algo puntual?)
  8. 8. #PAM2016 @psluaces @plasticscm 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
  9. 9. #PAM2016 @psluaces @plasticscm 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…
  10. 10. #PAM2016 @psluaces @plasticscm Probamos en carga regularmente https://www.plasticscm.com/under-heavy-load • Amazon • 1 server • 100s de clientes • Simulamos operaciones de usuarios
  11. 11. #PAM2016 @psluaces @plasticscm 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…
  12. 12. #PAM2016 @psluaces @plasticscm Viernes – tercer día de incidencia • Se había producido otro reinicio durante la noche • Necesitábamos ya una solución urgente
  13. 13. #PAM2016 @psluaces @plasticscm 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…
  14. 14. #PAM2016 @psluaces @plasticscm EL CICLO DE RAMA PORTAREA Ahora comenzaba el ciclo “normal” para llegar tener una release
  15. 15. #PAM2016 @psluaces @plasticscm 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. Builds 2. Runs nunit 3. Runs CLI tests 4. 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 of automated testing run in parallel VMWare New tests Taskdoc Wiki
  16. 16. #PAM2016 @psluaces @plasticscm Nuestro ciclo de trabajo
  17. 17. #PAM2016 @psluaces @plasticscm Nuestro ciclo de trabajo… explicado
  18. 18. #PAM2016 @psluaces @plasticscm • ¿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
  19. 19. #PAM2016 @psluaces @plasticscm 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
  20. 20. #PAM2016 @psluaces @plasticscm ¿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
  21. 21. #PAM2016 @psluaces @plasticscm ¿Cómo gestionamos las tareas? • Issue tracker – nosotros tenemos el nuestro propioTTS, 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
  22. 22. #PAM2016 @psluaces @plasticscm ¿Qué pinta tiene una tarea en nuestroTTS?
  23. 23. #PAM2016 @psluaces @plasticscm TTS
  24. 24. #PAM2016 @psluaces @plasticscm 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:
  25. 25. #PAM2016 @psluaces @plasticscm User pain controlado = proyecto manejable Evolución del “user pain” total – a nosotros no nos ha funcionado usar el “tts” como “descarga conciencias”
  26. 26. #PAM2016 @psluaces @plasticscm Foco en bugs detectados por clientes
  27. 27. #PAM2016 @psluaces @plasticscm 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, queTODO 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í!!!
  28. 28. #PAM2016 @psluaces @plasticscm Code Review • RevisamosTODAS 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).
  29. 29. #PAM2016 @psluaces @plasticscm ¿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
  30. 30. #PAM2016 @psluaces @plasticscm Code Review
  31. 31. #PAM2016 @psluaces @plasticscm 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
  32. 32. #PAM2016 @psluaces @plasticscm Exploratory testing
  33. 33. #PAM2016 @psluaces @plasticscm 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
  34. 34. #PAM2016 @psluaces @plasticscm 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í ;-)
  35. 35. #PAM2016 @psluaces @plasticscm Branch per task • De ese modo, tu desarrollo en vez de ser así:
  36. 36. #PAM2016 @psluaces @plasticscm Branch per task • Será así: con líneas paralelas
  37. 37. #PAM2016 @psluaces @plasticscm 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.
  38. 38. #PAM2016 @psluaces @plasticscm 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!!
  39. 39. #PAM2016 @psluaces @plasticscm 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.
  40. 40. #PAM2016 @psluaces @plasticscm 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.
  41. 41. #PAM2016 @psluaces @plasticscm Nuestro ciclo ideal = branch per task + CI (o delivery)
  42. 42. #PAM2016 @psluaces @plasticscm Nuestro ciclo ideal = branch per task + CI (o delivery)
  43. 43. #PAM2016 @psluaces @plasticscm 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
  44. 44. #PAM2016 @psluaces @plasticscm 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 :-)
  45. 45. #PAM2016 @psluaces @plasticscm Preguntas @psluaces

×