Este documento resume el proceso de lanzamiento de código de Tuenti, una compañía tecnológica española. Explica que usan Mercurial como sistema de control de versiones y tienen un calendario de lanzamientos semanales los martes y jueves. Detalla las etapas del proceso como el merge de código, pruebas automatizadas, reuniones para revisar errores, y el lanzamiento del código actualizado a producción con un proceso de construcción y despliegue automatizado.

1. Release Process Diego Muñoz Senior Frontend Engineer [email_address]

2. Agenda

3. Agenda

4. Equipos Tech. de Tuenti Frontend: Ca$hMoney, Community, Core, Gaming/Apps, Interactive, Local, Video Mobile Core, Client Apps Tu (MVNO) Framework/Architecture Backend, Scalability, Stats Testing Framework Dev-Tools IT Systems QA Design & UX

5. ¿Cómo de grande es Tuenti? +10.000.000 usuarios +76 minutos de media de uso diario +175.000.000 mensajes de chat / dia +4.000.000 fotos subidas al dia en picos +30.000.000.000 page views / mes +35.000 peticiones web / seg. en picos +1.000 servidores +180 empleados (de 18 nacionalidades) +60% de los empleados de la parte de tech.

6. Pero...¿Y el código? +14.000 archivos +2.000 folders Web Web móvil Aplicaciones móviles nativas APIs Jobs Tools Flash components Tests ...

7. Checkout

8. Checkout Herramienta SCM: Mercurial Como siempre lo pregunta la gente... ¿Por qué Mercurial y no Git? Interfaz y API muy limpios en Python 100% Cross-platform (Linux/Mac/Windows) Más user-friendly y parecido al viejo SVN

9. Checkout Un repositorio por equipo Core, Backend, ClientApps... Branch por proyecto + default stable default hotfix default integration default release default

10. Coding

11. Coding Una vez hecho el checkout... crear o actualizar al branch deseado... y a programar! (la parte divertida)

12. Testing

13. Testing Unit tests, Integration tests PHPUnit Grandes modificaciones y extensiones Mock objects Extendido de PHPUnit Acceptance tests Selenium + PHPUnit Normalmente desde VMs

14. Testing Hudson para Continuous Integration Diferentes prioridades de build por branch +30 branches de media

15. Merge

16. Merge Calendario: 2 releases a la semana (martes y jueves) 8+ branches por release de media A veces modificamos +2000 archivos! Merges permitidos desde 2 dias laborables antes Merges hasta 1 PM del dia anterior CTO approval para saltarse la norma

17. Merge Push-Pull Party Procedimiento normal de Mercurial: Pull - Update - Merge - Commit - Push Mergeando branches: Pull - Update - Merge - Commit - Push abortado - Pull de nuevo - Update - ... etc. Has de ser rápido mergeando :) Merge conflicts Mercurial != magia (pero mejor que SVN) A veces deja buenos estropicios mal mergeados "para revisión humana"

18. Merge Release meeting el dia anterior a la release Ingenieros: Pull de repositorio de equipo Mergeando en repositorio de integration Release Manager: Pull de repositorio de integration Mergeando en repositorio de release Errors spreadsheet QA + ingenieros añaden bugs Ingenieros responsables del código arreglan en el repositorio de release

19. Release

20. Release Subida usualmente a primera hora de la mañana Asistentes: Todos los ingenieros que han subido código mínimo 1 por equipo Responsable(s) de QA Release Manager usualmente parte del equipo de Dev-Tools 1+ ingenieros de Testing FW Otros implicados si es necesario Responsable de sistemas

21. Release Build process Tuenti es PHP pero no se sube tal cual

22. Release Build process Aplicar traducciones Minimizar código Agrupar archivos Y otros tweaks... Full build: 10 minutos aprox. Delta builds (cambios solamente) Envio de archivos a todos los servidores: Segundos

23. Stabilize

24. Stabilize "Live bugfixing" hasta ~11:30 AM Canal de chat con todos los implicados Errors spreadsheet (el mismo creado el dia anterior) Bugs conocidos que ya estén en el bugs backlog: ignorar o priorizar Nuevos bugs de prioridad baja: bugs backlog Es importante aprender a priorizar No siempre da tiempo a arreglar durante la release

25. Stabilize Cierre de la release Release Manager: Merge a repositorios stable y hotfix Ingenieros (1 por equipo): Pull del repositorio de stable Merge en default de repositorio del equipo Merge del default de repositorio de equipo En cada rama en que se esté trabajando

26. The End Gracias por vuestro tiempo!