Как релизится GitHub

Yac 2013 ^[1] посетил Jason Rudolph из GitHub. Я считаю его доклад про API ^[2] был одним из самых интересных на конференции. Яндекс обещал выложить в сеть записи, так что советую на досуге посмотреть его всем, кто не видел.

Но речь пойдет не о докладе. На картинке график релизов GitHub на продакшн.

Когда я услышал цифру, я не поверил своим ушам. У GitHub'а сотни обновлений в неделю. В команде около сорока разработчиков и ни одного QA.

К счастью Джейсон после доклада еще какое-то время находился рядом со сценой и я смог расспросить его с пристрастием о том как они это делают.

В GitHub'е живет Hubot ^[3]. Сначала это был just4fun чат-бот. Со временем он научился открывать двери в офисе и… запускать выкладку на продакшн. В GitHub выкладку может запустить любой разработчик из любого фича-бренча простым сообщением в чат. Я часто и много занимаюсь релиз-менеджментом. Когда я услышал о таком порядке деплоя волосы на руках непроизвольно зашевелились На самом деле, выложить «битый» релиз вам все-равно не дадут. Выкладка происходит следующем образом:

• Если бренч не был смержен с мастером — смержить его
• Запустить тесты
• Запустить миграции
• Выложить изменения в staff-only режиме
• Если все хорошо, включить «публичный режим»
• Проверить логи и твиттер на наличие ошибок/WTF-твитов
• Если все ок смержить фичу в мастер

Миграции БД

База данных GitHub достаточно велика и миграции могут занимать длительное время. Поэтому они выполняются отдельно, перед тем, как выложить обновление. За все время работы Джейсон не припомнит, чтобы пришлось откатываться. Не смотря на это разработчики всегда пишут обратные миграции.

Тесты

Когда Джейсон пришел в GitHub, тестов было много и они выполнялись около двух минут. Сейчас их «очень много», но они выполняются за 50 секунд. В GitHub смогли добиться этого за счет параллелизации. Все тесты выполняются на 64 ядрах. После каждого выполнения среда анализирует какие сюиты выполнялись дольше других и в автоматическом режиме изменяет тестовые сюиты так, чтобы все выполнялись примерно за одинаковое время. GitHub не использует Selenium, но у них есть юнит-тесты, интеграционные и системные end-to-end тесты. Вообще за автоматизацию всей этой кухни отвечает отдельный отдел DevOps, так что разработчики могут сосредоточиться на фичах.

Staff-only

Все новые фичи попадают сначала в, так называемый, staff-only режим. Сотрудники GitHub смогут их потрогать, для других фича будет «притворяться», что ее нет. Staff-only реализован в коде самого GitHub. Такой же идеей пользуются в IOS отделе Facebook. У них все фичи имеют тумблер «вкл/выкл». Это помогает выпустить релиз даже в случае если нужно экстренно «вернуть какое-то изменение обратно».

Твиттер

Джейсон шутит, что у GitHub самая лучшая команда тестировщиков — их клиенты. Если «что-то пошло не так» в твиттере сразу появляется аномальная активность. Этот Yac заставил меня по другому взглянуть на твиттер: кажется этот сервис все-таки можно использовать для чего-то более полезного, чем «мама, я покакала».

Профессиональная этика

Попасть на работу в GitHub — не самая простая задача. Каждый кандидат, даже если его порекомендовал кто-то из команды, изучается с пристрастием. Преимущество GitHub в том, что если у кандидата есть аккаунт, они получают достаточно много информации о претенденте. Внимание уделяется не только качеству кода, но и тому поддерживает ли человек свой проект, как быстро отвечает на баг-репорты, сотрудничает ли с сообществом. Критериев много, но если коротко, то в GitHub работают люди, основная цель которых — выпустить классный продукт. Не самый классный код, дизайн, ui, алгоритм, а именно «продукт». Человеку должно быть важно «доставить» (to deliver) новую функциональность в срок и качественно. Это, пожалуй, то, что отличает больше всего «забугорных» разработчиков от наших соотечественников. Я глубоко убежден, что ориентация на продукт — это классно и нам нужно учиться этому у западных коллег.

Автор: marshinov

Источник ^[4]