Badoo presentation-2012-rit-ageev
1 like294 views
Документ описывает изменения в процессе релиз-менеджмента в компании Badoo, включая переход от Subversion к Git и внедрение новых этапов деплоя. В ходе изменений были устранены прежние недостатки, такие как медленная выкладка и сложности с отслеживанием состояния задач. Новая схема позволяет ускорить выкладку кода и улучшить управление задачами, что значительно повысило эффективность работы.
Badoo presentation-2012-rit-ageev
- 1. Релиз-менеджмент в Badoo Илья Агеев
- 2. Badoo ● 140 миллионов пользователей; ● 180 стран мира; ● 160 тысяч ежедневных регистраций; ● 3 миллиона фото и видео ежедневно; ● Более 200 сотрудников, говорящих на 39 языках.
- 3. План доклада ● 1. Старая схема релизов ● Subversion; ● Issues tracking; ● Работа с системой перевода; ● Deployment. ● 2. Новый деплой, I этап ● Разделение задач по веткам, переход на git; ● Issues tracking, привязка задач; ● Недостатки и преимущества.
- 4. План доклада ● 3. Новый деплой, II этап ● “Шоты” и “Билды”; ● Раскладка по кластерам; ● Изменения в схеме работы с JIRA; ● Deployment; ● Недостатки и преимущества. ● Новый деплой, III этап ● Ускорение выкладки ● Синхронное переключение лупов; ● Централизованное управление конфигами.
- 5. 1. Старая схема релизов subversion trunk commits Feature 1 Feature 3 bugfix 1 Feature 2 bugfix 2 release release
- 6. 1. Старая схема релизов JIRA svn revision field Open In progress Resolved Reopened Passed on DEV Passed on Stage Closed Passed on Prod
- 7. 1. Старая схема релизов Переводы Translators devel Parse *.tpl templates Translate database Generate templates English Español עברית *.tpl Русский Italiano العربية Deutsch 中文 िहिंदी Français Ελληνικά Türkçe
- 8. 1. Старая схема релизов Выкладка кода HEAD main svn translate loop mscp mscp 20 threads stage production
- 9. 2. Новый деплой – этап I git SRV-1027_rebuild_reg_stat stable branch (master) BFG-1020_new_profile BD-502_spp_in_Spain CS-89_improve_blog_comments release release
- 10. 1. Старая схема релизов Недостатки ● В выкладку попадают незавершенные задачи; ● Неудобно отслеживать состояние кода; ● Невозможно откатить задачу; ● Невозможно добавить что-то в прошлый релиз; ● Работа отделов волнообразно зависит от выкладки; ● Выкладка готовых задач тормозится из-за недопереведенных или неработающих задач; ● Код выкладывается медленно и несинхронно; ● ...
- 11. 2. Новый деплой – этап I Open In progress Resolved QA on Devel Reopen To merge auto To Deploy auto On Staging QA on Staging To Production auto On Production To Verify Closed Verified
- 12. 2. Новый деплой – этап I Преимущества ● В выкладку попадают завершенные задачи; ● Всегда четко видно в каком состоянии задача, где находится код; ● Гибкое управление кодом. Недостатки ● После выкладки на мэйн присутствуют недостатки предыдущей схемы
- 13. 3. Новый деплой – этап II Шоты и билды ● Shot (шот) – стэйджинг для каждой отдельно взятой задачи (ветки git). Физически – папка на сервере, куда чекаутится ветка git + настройка nginx. Имеет свой домен первого уровня - .shot; ● Build (билд) – аггрегация задач для раскладки по продакшену. Это отдельная ветка в git, в которую мержатся все выкладываемые задачи.
- 14. 3. Новый деплой – этап II build production master Feature 1 Feature 2 Feature 3 shot shot shot
- 15. 3. Новый деплой – этап II Кластеры www build1 scripts build2 billing build3 back-office etc
- 16. 3. Новый деплой – этап II JIRA ... Resolved Reopen In DEV - ok In Shot In Shot - ok In Build In Build - ok ... On Production
- 17. 3. Новый деплой – этап II Переводы HEAD Translates parse shot Git branch Translates generate build
- 18. 3. Новый деплой – этап II Передача файлов uftp
- 19. 3. Новый деплой – этап II Преимущества ● Любую задачу можно откатить в любой момент; ● Можно добавлять задачи в прошлые релизы; ● Работа идет плавно, не волнообразно; ● Ничто не тормозит выкладку задачи, если она завершена; ● Выкладка ускорилась с 40 до 3 минут вместе с генерацией. Непосредственно раскладка лупа через uftp ~ 30 секунд на все машины платформы.
- 20. 4. Новый деплой – этап III Планы ● Ускорение выкладки – фоновая загрузка; ● Синхронизация выкладки – включение лупов конечными серверами самостоятельно, по получению команды от центрального сервера, в определенный момент времени; ● Управление конфигами через БД. Выгрузка и применение конфигов конечными серверами самостоятельно.