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.

Cómo trabajamos en Plastic SCM

553 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

×