Release engineering и вообще разработка в Badoo

Добрейшего!

Не далее как вчера на Хабре увидел интервью, прям напросившееся в почти заброшенный бложик.

Процесс разработки и выкатка релизов в Badoo. Автоматическое тестирование. Девелоперское окружение.

Инетервью с двумя инженерами, которые занимаются configuration management, release management и все, что с этим связано. Прям ностальгия накрыла - именно этим я и занимался немало времени, именно из этих занятий пошёл данный бложик.

В общем, интервью крайне познавательное, всё по делу, много интересного. Комментировать здесь смысла нет - в интервью всё рассказано с избытком. Ну, для тех, кто понимает, о чём речь, конечно.

Release engineering в Facebook

Добрейшего!

RSS лента в очередной раз принесла интересную подборку материалов от OpenQuality.ru, где взгляд немедленно зацепился на некоторые ссылки из раздела "Архитектура систем". Особенно за последнюю ссылку :)

Однако самое вкусное там для меня - это Exclusive: a behind-the-scenes look at Facebook release engineering - эксклюзивный материал про управление релизами в Facebook. Кому лень читать или кто думает, читать ли вообще, - несколько основных моментов.

Код пишется на PHP, затем транслируется в оптимизированный код на C++, который затем отстраивается в единый бинарник размером 1.5 Гб. Да, полтора гигабайта.

Далее код выкладывается во внутренний доступ и посредством BitTorrent скачивается на все сервера которые участвуют в работе. Итог по времени - 30 минут, из которых 15 минут делается сам бинарник, а ещё 15 - этот бинарник распространяется по серверам.

При этом то, что касается статического контента - яваскрипты, стили и т.п. - распросраняется через свои же CDNы, т.е. распределённые сети доставки контента.

Оставим за скобками странную цепочку PHP -> C++ -> Большой-Бинарник-На-Полтора-Гига, однако доставка релиза через торрент - это остроумно. Ну и распространение статики через CDN - вообще отлично.

P.S. Кстати, на всё том же OpenQuality лежит моё сочинение на тему "Управление изменениями, или Кессонная болезнь проектов". Ушёл в отрыв, сделал безумную, но на мой взгляд интересную аналогию.

Пример описания процесса создания релизов

Добрейшего!

Не так давно (ну хорошо, почти год назад) я решил сформулировать для себя задачи по улучшению инфраструктуры разработки. Проще говоря - надо было уже начать что-то менять в SCM-процессе, и не только в нём.

Упоминавшаяся там команда Ф - достаточно обособленная, но самая крупная, и задачи решает самые разнообразные. Так вот, один из разработчиков нашел время и описал процесс построения билдов и всего, что с этим связано. Фактически, описан процесс выпуска релизов от  получения исходников до начала развёртывания. Применяется много практик из continuous integration, но ими не ограничивается, а сам процесс описывается для Java.

Рекомендую ознакомиться для общего развития. Даже если ваш процесс отличается или вы только собираетесь что-то внедрять, заметка и названия тулов дадут направление, куда смотреть.

Кто такой релиз-инженер

Добрейшего.

В продолжение вопроса о том, кто такой СМ-инженер.

Анатоликс не так давно вывесил вакансию релиз-инженера для поиска Яндекса . Собственно, по ссылке - пример того, кто такой настоящий release engineer. Практически тем же самым (ну, с поправкой на количество серверов), мы занимались во времена работы с интеграционной команде Моторолы.


Стало быть, Яндекс решил выделить релиз-инженера в отдельную роль. Офигеть, что же у них раньше творилось и какой был геморой у тех людей, которым надо было совмещать основные обязанности техлидов и того, кто выпускал релизы. При интенсивной разработке большой командой это немалый труд. Ну, если найдут нужного человека - жизнь их станет значительно легче и приятнее :)

Кстати, вот обсуждение на RSDN. Для сравнения - обсуждение на sql.ru, прям небо и земля...