Регулярные обновления в проекте с большим количеством команд

Роберт Лукшаodnoklassniki.ru

про Одноклассников

33 000 000 уникальных пользователей в день

2 000 000

000 просмотров страниц в день

«Под капотом»Более 4 500 серверов

JAVA, GWT, Cassandra, MS SQL,

Zabbix ...

Контекст

— Заказчик – мы сами

— 3 офиса

— 14 распределенных команд

— Нужны частые обновления

Необходимость обновлений

— Плановая разработка фич

— Партнеры, промо-акции

— Производственная необходимость

— Экстренная необходимость

Эволюция

Раньше

—Одна команда

—Много срочных задач

—Обновления по мере готовности фич

—Участие всех разработчиков в процессе

обновления

—Апдейт – одна фича и несколько фиксов

—Оффлайн-апдейт

Раньшеплюсы

—готовый код выкладывался сразу же

—высокая скорость работы

—«атмосфера стартапа»

минусы

—остановки портала

—тяжело выдержать ритм

—в процесс обновления вовлечено много

людей

—высокий риск ошибок

Сейчас

Цикл обновления

пн втсрчт

пт сб вс пн вт ср чт пт сб вс пн вт ср чт пт сб вс

   

 UPD-1     

UPD-2             

  UPD-3             

    UPD-4       

Команды

пн втсрчт

пт сб вс пн вт ср чт пт сб вс пн вт ср чт пт сб вс

   

team-1

                                   

   

team-2                                  

   

team-3                                  

   

team-4                                  

Подготовка обновления

1. Разработка функциональности внутри команды

2. Интеграция на тестовой среде

3. Препродакшн

4. Обновление продакшна

Разработка внутри команды

1. Разработка фичи в бранче

2. Функциональное и UI-тестирование на VM разработчика

3. Ревью кода

4. Коммит в мастер

Общая тестовая среда

1. Коммиты в мастер

2. Обновление на тестовой среде

3. Тесты функциональности

4. Интеграционное тестирование

Препродакшн1. Тестирование2. Ввод в ротацию3. Анализ (логи, графики, суппорт)⟳ При необходимости повторить

Процесс обновления

1. Выкладка по модулям2. Тестирование3. Анализ

– если всё плохо – откат– если просто плохо – фикс– если не очень хорошо – регистрация бага

4. Информирование о замечаниях5. Ретроспектива

Запуск функциональности

Проведение «экспериментов» для запуска фич

—ожидаемый результат

—статистика

—нагрузка

—фидбэк от пользователей

Инструменты

—своя система статистики

—Portal Management System

—GIT

—Confluence

—Jira

Роли

Дежурный разработчик

Дежурный тестировщик

Системный администратор

Менеджер апдейта

Команды

—Отвечают за фичу от дизайна до поддержки

—Сами организовывают свою работу

—Общая культура, но индивидуальный подход

Преимущества подхода

— Простые и понятные правила

— Предсказуемость планирования

— Быстрый proof-of-concept

— разработчикам интересно!

Чего добились

—Адаптируемость подхода

—Ответственность и самостоятельность команд

—Программисты программируют

—Тестировщики тестируют

—Менеджеры поддерживают

«Грабли»

—«еще 5 минут и закоммичу»

—полегче с «уплотнением»

—удобный сервис

—зависимость от высококлассных специалистов

Скоро— Самостоятельные апдейты по

необходимости

— Автоматизация

– выкладка

– тестирование

Сейчас

—Онлайн-апдейты

—Разделение по командам

—Апдейты по плану

—Роли

– дежурные

– ответственные

—Ревью кода

—Формализация процесса обновления, но не

разработки

Спасибо

Роберт Лукшаok.ru/robroberts.luksa@odnoklassniki.ru

http://v.ok.ru/публикации