Release Process

Diego MuñozSenior Frontend Engineerdiego@tuenti.com

Agenda

Agenda

Equipos Tech. de Tuenti• Frontend: 

o Ca$hMoney, Community, Core, Gaming/Apps, Interactive, Local, Video

o Mobile Core, Client Apps o Tu (MVNO) 

• Framework/Architecture • Backend, Scalability, Stats• Testing Framework• Dev-Tools • IT• Systems• QA • Design & UX 

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

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

Checkout

Checkout• Herramienta SCM: Mercurial• Como siempre lo pregunta la gente... 

¿Por qué Mercurial y no Git?o Interfaz y API muy limpios en Python o 100% Cross-platform (Linux/Mac/Windows)o Más user-friendly y parecido al viejo SVN

Checkout• Un repositorio por equipo• Core, Backend, ClientApps...

o Branch por proyecto + default• stable

o default • hotfix

o default • integration

o default • release

o default 

Coding

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

Testing

Testing• Unit tests, Integration tests

o PHPUnitGrandes modificaciones y extensiones

o Mock objects Extendido de PHPUnit

• Acceptance testso Selenium + PHPUnito Normalmente desde VMs 

Testing• Hudson para Continuous Integration

o Diferentes prioridades de build por brancho +30 branches de media 

Merge

Merge• Calendario: 2 releases a la semana (martes y jueves)• 8+ branches por release de media

o  A veces modificamos +2000 archivos!• Merges permitidos desde 2 dias laborables antes• Merges hasta 1 PM del dia anterior

o CTO approval para saltarse la norma 

Merge• Push-Pull Party

o Procedimiento normal de Mercurial: Pull - Update - Merge - Commit - Push

o Mergeando branches: Pull - Update - Merge - Commit - Push abortado - Pull de nuevo - Update - ... etc.

Has de ser rápido mergeando :)• Merge conflicts

o Mercurial != magia (pero mejor que SVN)o A veces deja buenos estropicios mal mergeados "para revisión humana"

Merge• Release meeting el dia anterior a la release• Ingenieros: 

o Pull de repositorio de equipo o Mergeando en repositorio de integration

• Release Manager:o Pull de repositorio de integrationo Mergeando en repositorio de release

• Errors spreadsheeto QA + ingenieros añaden bugso Ingenieros responsables del código arreglan en el repositorio de release 

Release

Release• Subida usualmente a primera hora de la mañana• Asistentes: 

o Todos los ingenieros que han subido códigomínimo 1 por equipo

o Responsable(s) de QAo Release Manager

usualmente parte del equipo de Dev-Toolso 1+ ingenieros de Testing FWo Otros implicados si es necesarioo Responsable de sistemas 

Release• Build process

o Tuenti es PHP pero no se sube tal cual

Release• Build process

o Aplicar traduccioneso Minimizar código o Agrupar archivoso Y otros tweaks...

• Full build: 10 minutos aprox.o Delta builds (cambios solamente)

• Envio de archivos a todos los servidores: Segundos

Stabilize

Stabilize• "Live bugfixing" hasta ~11:30 AM• Canal de chat con todos los implicados• Errors spreadsheet (el mismo creado el dia anterior)

o Bugs conocidos que ya estén en el bugs backlog: ignorar o priorizar

o Nuevos bugs de prioridad baja: bugs backlog• Es importante aprender a priorizar

o No siempre da tiempo a arreglar durante la release

Stabilize• Cierre de la release• Release Manager: 

o Merge a repositorios stable y hotfix• Ingenieros (1 por equipo):

o Pull del repositorio de stableMerge en default de repositorio del equipo 

o Merge del default de repositorio de equipo En cada rama en que se esté trabajando

The End

Gracias por vuestro tiempo!