Descargado 13 veces
Subido por233 Grados de TI
Cómo trabajamos en Plastic SCM
El documento describe cómo la compañía Plastic SCM resolvió una incidencia en su sistema de control de versiones que estaba afectando a 300 desarrolladores de Telltale Games. Tras varios días de análisis y pruebas, identificaron un problema en el conector MySQL que estaba causando el fallo. Rápidamente desarrollaron una corrección, la probaron y lanzaron una nueva versión antes de la fecha límite, resolviendo así satisfactoriamente el problema.
Más contenido relacionado
Similar a Cómo trabajamos en Plastic SCM
Cómo trabajamos en Plastic SCM
- 1. #PAM2016 @psluaces @plasticscm Cómodesarrollamos Plastic SCM PAM 2016 #PAM2016 Pablo Santos Luaces @psluaces
- 2. #PAM2016 @psluaces @plasticscm VOYA CONTAR UNA HISTORIA
- 3. #PAM2016 @psluaces @plasticscm Unproblema en producción • Miércoles de hace unas semanas… • Recibimos un email deTelltaleGames • Indicando que su servidor había tenido una incidencia
- 4.
- 5. #PAM2016 @psluaces @plasticscm Sucontrol de versiones es
- 6. #PAM2016 @psluaces @plasticscm DesarrollamosPlastic 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. #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. #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. #PAM2016 @psluaces @plasticscm Estudiamosen 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. #PAM2016 @psluaces @plasticscm Probamosen carga regularmente https://www.plasticscm.com/under-heavy-load • Amazon • 1 server • 100s de clientes • Simulamos operaciones de usuarios
- 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. #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. #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. #PAM2016 @psluaces @plasticscm ELCICLO DE RAMA PORTAREA Ahora comenzaba el ciclo “normal” para llegar tener una release
- 15. #PAM2016 @psluaces @plasticscm Issuetracker (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. #PAM2016 @psluaces @plasticscm Nuestrociclo de trabajo
- 17. #PAM2016 @psluaces @plasticscm Nuestrociclo de trabajo… explicado
- 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. #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. #PAM2016 @psluaces @plasticscm ¿Cómoestimamos? • 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. #PAM2016 @psluaces @plasticscm ¿Cómogestionamos 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. #PAM2016 @psluaces @plasticscm ¿Quépinta tiene una tarea en nuestroTTS?
- 23.
- 24. #PAM2016 @psluaces @plasticscm UserPain = 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. #PAM2016 @psluaces @plasticscm Userpain controlado = proyecto manejable Evolución del “user pain” total – a nosotros no nos ha funcionado usar el “tts” como “descarga conciencias”
- 26. #PAM2016 @psluaces @plasticscm Focoen bugs detectados por clientes
- 27. #PAM2016 @psluaces @plasticscm Sino 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. #PAM2016 @psluaces @plasticscm CodeReview • 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. #PAM2016 @psluaces @plasticscm ¿Cómoera 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.
- 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.
- 33. #PAM2016 @psluaces @plasticscm Perola 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. #PAM2016 @psluaces @plasticscm Branchper 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. #PAM2016 @psluaces @plasticscm Branchper task • De ese modo, tu desarrollo en vez de ser así:
- 36. #PAM2016 @psluaces @plasticscm Branchper task • Será así: con líneas paralelas
- 37. #PAM2016 @psluaces @plasticscm Branchper 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. #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. #PAM2016 @psluaces @plasticscm Estilosde 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. #PAM2016 @psluaces @plasticscm 3pilares - 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. #PAM2016 @psluaces @plasticscm Nuestrociclo ideal = branch per task + CI (o delivery)
- 42. #PAM2016 @psluaces @plasticscm Nuestrociclo ideal = branch per task + CI (o delivery)
- 43. #PAM2016 @psluaces @plasticscm Informacióninteresante • ¿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. #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.
Notas del editor
- #7 Codice Software es una empresa (startup) que comenzó en 2005, este año hemos celebramos los 10 años como empresa. Hacemos un producto que se llama plastic-scm que es un control de versiones para empresas. Todos sabeis que es un sistema de control de versiones? Estos sistemas facilitan la administración de las distintas versiones de un producto. Gestión de los diversos cambios que se realizan sobre los elementos de un producto. Para controlar las distintas versiones del código fuente Ejemplos de este tipo de herramientas son entre otros: CVS, Subversion, SourceSafe, ClearCase, Darcs, Bazaar, Plastic SCM, Git, Mercurial, Perforce, Fossil SCM, Team Foundation Server. Estos sistemas son clave en el desarrollo de una empresa. Elemento crítico, como no funcione puedes dejar a todo un equipo bloqueado.
- #8 Nos informaron de que el servidor se había parado durante el día anterior pero que lo habían reiniciado y seguía dando servicio. Uno de nuestros ingenieros de soporte se puso a estudiar los logs para determinar qué podía haber sido. El servidor llevaba semanas levantado sirviendo a más de 300 usuarios concurrentes 24h al día, porque tienen también un estudio en Asia. Me preocupaba, pero quería saber si había sido algo puntual, debido a otro motivo. Al final, siempre deseas que sea algo ajeno a tu software, no sé, que la máquina se ha quedado sin RAM porque ejecutan un gestor de proyectos que ocupa 240 GB él solito, como nos pasó unos días después en Delphi, una multinacional del sector del automóvil con más de 800 usuarios que también usa Plastic.
- #9 El problema fue que al día siguiente recibimos otro email. Se había producido otro fallo. Esto ya era más preocupante. De hecho, tuve que hacer lo que más odio, parar el ciclo de trabajo y poner a alguien de desarrollo a mirar el problema. Era muy posible que no fuera ya algo de soporte, sino de desarrollo. Ese jueves era el segundo del sprint. Trabajamos en sprints de dos semanas, y en aquél momento estábamos en el sprint 243. Así que uno de nuestros ingenieros con más experiencia paralizó la tarea en la que estaba trabajando, y se puso a estudiar el problema.
- #15 == 5 minutes until here == Vamos a ello!
- #17 Lo primero, muy brevemente, en que consiste nuestro ciclo de trabajo. Voy a dar una pincelada de las etapas que vemos en la ilustración porque luego veremos cada una más en detalle asi que no os preocupeis.
- #18 Lo que hacemos son iteracciones qué podríamos dividir en 3 fases: La fase de planificación Donde se maneja un backlog que no es otra cosa que una lista de todo lo que hay por hacer: requisitos, ideas, peticiones de clientes,… ordenado por prioridad. Cada 2 semanas, seleccionamos que hacer de esa lista y de la lista de bugs que hay pendientes. Ese es el plan del Sprint! Podríamos decir que la fase de planificación concluye aqui, ya tenemos el plan del sprint, que no es más que una lista de tareas. Empezaría la fase de desarrollo Ya tenemos la lista de tareas, veremos como se usan herramientas para gestionar estas tareas, los conocidos sistemas de control de tareas o issue trackers. Todo lo que vamos a hacer en el proyecto tiene primero una tarea. A toda tarea se le acocia una rama de trabajo en el sistema de control de versiones. Este es nuestro patrón de trabajo, el que se denomina “branch per task o rama por tarea”. Nosotros por supuesto que usamos Plastic para crear las ramas. De manera que, una vez creada tu rama de trabajo, ya puedes ponerte manos a la obra. Los tests. Los tests son importantisimos y siempre tiene que formar parte del desarrollo de la tarea, sean del tipo que sean: unitarios, graficos… Hablaré también del TDD, que es el desarrollo dirigido por tests. A continuacion, lo que sigue en nuestro ciclo de trabajo es la revisión de la tarea. Es algo que hemos introducido hace unos años, pero que ahora consideramos imprescindible. Toda tarea lleva su “code review” que es realizada por otro miembro del equipo. Luego la tarea se valida, se prueba a mano. Lo que se hace es un breve exploratory testing que veremos lo que es también. Esta validación es realizada por otro miembro del equipo. Todas las personas que estamos en desarrollo hacemos revisiones y validaciones. Asi que como veis, toda tarea pasa por 3 manos, la del desarrollador, la del revisor y la del validador. ¿Que intentamos conseguir o que pretendemos con esto? Que salgán los menos errores posibles al exterior. Aqui podriamos decir que concluye la fase de desarrollo, buen no, todas las tareas pasan por el sistema de testing. Aqui es donde entran en juego los sistemas de integración continua. Y solo cuando la tarea ha pasado todos los tests es cuando se puede decir que está resuelta y lista para ser integrada. Ahora ya si entraríamos en la última fase, la fase de integración o construcción de la release. Cuando hay unas cuantas tareas terminadas, es decir en estado resolved, han completado todas las etapas de lo que podemos decir que es la fase de desarrollo, se crea una nueva release. La release es lo más importante, es el sofware funcionando! Es lo que entregas a tus clientes. Por lo tanto, es importantisimo tener releases muy frecuentes, con mucha frecuencia. Es lo que marca el ritmo del proyecto! Nosotros nos pusimos como objetivo tener cada día una release pero no siempre lo logramos.
- #19 Esta slide la metió Míryam, creo que está muy bien. Lo de “servicio vs producto” es nada más contar que no es lo mismo una empresa que hace proyectos para otras (servicio) y que por tanto el backlog viene 99% del cliente, que en nuestro caso, dónde muchas cosas vienen de nosotros mismos
- #21 OJO: ahora está muy de moda el tema de NoEstimates y de que la estimación no sirve para nada, así que podríamos comentar algo de eso, de si sirve, o no sirve… Podemos decir que no nos obsesionamos con ello, pero que sí que intentamos tener al menos una idea de cuándo vamos a tener algo, sobre todo por compromisos con clientes, pero que sabemos que como siempre estamos haciendo cosas nuevas… pues la podemos liar y equivocarnos, y que de hecho nos equivocamos. SCRUM no te dice como tienes que estimar. Cada uno puede elegir su metodo de estimación. Nosotros usamos PERT para estimar. En que consiste? A cada tarea se le dan 3 estimaciones, en horas. Mejor caso (estimación optimista) Peor caso (estimación pesimista) Caso más probable Con eso se calcula la estimación. Es una cuenta. Se suma la estimacion optimista + la estimación pesimista + 4 veces la estimación probable y se divide entre 6. Ejemplo: tarea… El objetivo es controlar tanto el optimismo como el pesimismo exagerado. Para saber más sobre el tema de estimaciones, os dejo estos dos libros que son muy recomendables.
- #22 Es imprescindible, y digo imprescindible tener un sistema de control de tareas para gestionar las tareas. Sistemas de control de tareas hay miles, algunos muy conocidos como jira, bugzilla, mantis… Imagino que a muchos os sonaran. Nosotros tenemos nuestro propio sistema de control de tareas. Os lo enseñaré a continuación para que es hagais una idea para aquellos que nunca hayais visto uno de que es y de que pinta tiene. Es básicamente un sistema web que te permite añadir y gestionar tareas. Ojo una cosa, el sistema de control de tareas no puede ser un cajón desastre. Que quiero decir con esto, que si quieres que sea de ayuda no puede tener millones de entradas porque se convierte en inmanejable. Es decir, en función de lo grande que sea tu equipo, pues podeis abarcar mas o menos trabajo. De modo que es bobada meter miles de tareas que no se van a hacer nunca. Lo tipico que decimos a veces de estaria bien que el sistema hiciera esto y aquello, y lo de mas alla… Preguntate antes, tienes gente suficiente para hacerlo? Tienes recursos suficientes? O tienes antes nose cuantos bugs por corrigir u otras tantas funcionalidades pedidas por clientes esperando. TTS – meter solo las tareas que se van a hacer. Resto: backlog.
- #23 == CONECTADOS a nuestro tts == ->>>>>>>>>>>>>>>>>> CREO QUE EFECTIVAMENTE, estaría MUY BIEN conectarnos y enseñarlo. Veamos ya que es una tarea en detalle y que pinta tiene. Cada tarea tiene un titulo, una descripcion un desarrollador encargado de la tarea, revisor y validador, y su estimación (PERT). Horas trabajadas. Estimación de la revision y horas trabajadas. Estimación de la validación y horas trabajadas. Porque lo hacemos? Necesitamos un control (rapido) No se deberia hacer y bueno nosotros no hacemos ni un solo cambio de código sin que tenga una tarea asociada. Esto puede parecer la primera vez que lo oyes como muy exagerado. Con eso garantizamos trazabilidad. De esta manera todo cambio tiene un motivo, un porque, una descripcion, en definitiva, una tarea asocida. Ejemplos de tareas: Nueva funcionalidad, la creación de un formulario / Bug, corregir un bug en linux en el SSL en el sistema de certificados. Un refactor de un codigo viejo.
- #24 La imagen ilustra la lista de tareas, revisiones y validaciones de una persona del equipo (sprint backlog que deciamos antes). El trabajo que tiene que hacer en un sprint. Asi se tiene una gestión tanto de las cosas que se hacen, las tareas, como una gestión del equipo. Quien hace que cosa. Super visual. Lo tienes todo bajo control! (Explicar por encima)
- #25 http://codicesoftware.blogspot.com/2008/06/user-pain.html http://www.lostgarden.com/2008/05/improving-bug-triage-with-user-pain.html
- #26 Aquí lo que quiero contar es que meter y meter cosas, lo primero que se nos pasa por la cabeza, hace que el issue tracker sea inmanejable. No ayuda, metes duplicados, deprime tener tantas cosas abiertas. Lo que hemos hecho, además de mejorar la calidad y por eso tenemos menor user pain, es controlar mucho más lo que entra como bug… de modo que todo comienza a ser más útil. Los bajones de golpe son muchas veces simples “limpiezas” en las que descartamos bugs que ya no son ni aplicables.
- #27 Nada, aquí simplemente insistir en lo mismo de antes, y recalcar que hemos bajado de 50 bugs pendientes de clientes, a menos de 10, y de casi 500 bugs internos, a menos de 200
- #28 ¿Qué es TDD? Son las siglas de desarrollo dirigido por tests. En que consiste? En primero escribir los tests unitarios y luego el código necesario para que esos tests pasen. Nosotros no usamos TDD estrictamente, pero SI que los escribimos los tests antes de terminar la tarea. Y he dicho, escribimos los test, no es probar a mano, es tener tests automáticos. Toda tarea lleva sus tests!!! Teneis que tener siempre muy presente que todo aquello que pueda ser automático, mejor que lo sea, por vuestra propia tranquilidad. Pruebas manuales son de juguete, teneis que pensarlo asi. Si esta escrito es garantia!
- #29 Las revisiones de código se han convertido en una etapa más de nuestro ciclo de trabajo. Llevamos haciendolo 3 o 4 años. Al principio no se hacia. Bueno creo que se hacían de vez en cuando. Ahora revisamos todas las tareas que hacemos. Ninguna tarea va sin code review. No es una revisión formal. Hay un libro, el Code complete, que habla de 3 tipos de revisiones: inspecciones de código, code review y walkthoughts. Nosotros diriamos que lo que hacemos es un walkthrought. Que es ir recorriendo el código viendo que pinta tiene. Quien la hace? La hace una persona del equipo. Que se busca? Por supuesto que lo más importante es la deteccion de posibles fallos. Pero, porque decidimos meterlo en nuestro ciclo de trabajo? Por 2 motivos más a parte de la detección de posibles fallos: Porque ayuda a mantener la calidad del código que es super importante. 2. Tiene una parte didáctica para la gente nueva en el equipo. Ves como escriben el codigo. Ves el estilo, la estructuración que ha hecho del código, ves como nombra las cosas. Las cosas tienen que estar bien nombrados. Todas estas pueden ser causas de reapertura de una tarea. Le damos mucha importancia a las revisiones. Una tarea se puede reabrir en el proceso de revision. Que se necesita para hacer una revisión de código? Un buen sistema de diferencias.
- #31 Plastic tiene un sistema básico de code review integrado. Hay también bastantes sistemas de code review en el mercado: Crucible de Atlassian, Github tambien tiene reviews integradas,… Al final la review es como un diálogo entre el revisor y el desarrollador de la tarea. Te permite añadir comentarios por línea. ** la estimación de una revisión puede variar mucho en función de si hay puntos que discutir o muchos comentarios de revisión. Hay que tender a que sean ninguno o los menos posibles. Y siempre aprender de las revisiones! No tropezar varias veces con la misma piedra Porque además eso lo que provoca es perdida de confianza en la persona. Lo cual es clave en un equipo.
- #32 Las validaciones de código se han convertido en una etapa más de nuestro ciclo de trabajo también. Todas las tareas las validamos. ¿En que consiste la validación? Una validación es una prueba manual realizada por otra persona del equipo. No es un test. No prueba todo el sistema. Sólo se prueba la tarea. Ver que el fix está corregido. Muy importante, NO es testing como tal, va más allá, se valida que el resultado tenga sentido tambien! Es como un test exploratorio pero corto. Que es un test exploratorio? Se deja un tiempo concreto a un probador humano para que experimente, sin seguir un patrón definido, dejando que saque partido de sus ideas en el momento. Pero no es una prueba a lo tonto. Se marcan unos objetivos y se guardan unos resultados concretos. Muchas empresas hacen testing manual con guiones de testing, de modo que los testers repiten eso una y otra vez. Nosotros no hacemos eso, eso lo automatizamos!! Los exploratory son otra cosa.
- #33 Organización, no es una prueba sin orden y a lo loco. Tampoco es un guión de testing, originalidad (para eso podemos pensar, no somos máquinas). A cada uno se le pueden ocurrir cosas diferentes que probar! http://juno.codicefactory.com/wiki/index.php/Unity:_Check_plastic_plugin_with_v4.5.3
- #35 Aqui entraríamos ya a hablar de nuestro patrón de trabajo, Rama por tarea. En función de lo que sepais de control de versiones pues podemos profundizar más o no… ¿?
- #36 LINEAL
- #39 Y por último, el proceso de construcción de la release. La release es lo más importante, es el sofware funcionando! Es lo que entregas a tus clientes, es donde demuestras todo tu trabajo. Como ya hemos dicho, cuando hay unas cuantas tareas terminadas, se crea una nueva release. En nuestro caso tenemos un ingeniero que se encarga 100% de hacer las releases, bueno no solo de hacerlas sino tambien de mejorar todo lo relacionado con el proceso de construcción de la release. Antes decia que tenemos nuestro propio sistema de integración continúa, eso ha sido trabajo de nuestro build master. Este es el nombre con el que se suele conocer a la persona encargada de las releases. Cada release tiene que pasar todos los juegos de tests, OJO, no son los mismos que pasamos en la fase de testing. Aqui hay más. En la fase de testing se pasa un subconjunto de estos. Si queremos garantizar la funcionalidad del producto en todos los sistemas operativos hay que pasar la suite de tests en todos ellos. Windows 10, windows 8, window 7, todas las distros de linux, mac,… Tenemos que probar todos los backends que soportamos. Al final no es que tengamos millones de tests, pero si que tenemos muchas combinaciones que probar. Para que os hagais una idea, nuestros tests tardaran en pasarse 40 horas si no fuera porque los tenemos paralelizados para que se pasan en menos de 3 horas! Si quieres poder tener releases con mucha frecuencia, que al final es el objetivo de todo esto, el proceso de release no puede ser el cuello de botella. No puede tardar! De ahi que siempre estemos intentando mejorarlo.