Information

Founded
2006
Location
Россия
Website
badoo.com
Employees
501–1,000 employees
Registered

Habr blog

Pull to refresh
Comments 52
Интересно, а размер самого репозитория при столь большом количестве веток сильно разрастается?
Нет ли проблемы конечному разработчику банально все это выкачать в свое локальное окружение?
Так реп же Гитовый — там хранятся changeset'ы, а не версии файлов целиком.
Вы оба правы и не правы одновременно :). Гит внутри себя предоставляет API, который оперирует объектами целиком, но при этом в .pack-файлах хранит уже с дельта-компрессией.

Размер репозитория в git от количества веток не сильно зависит — важно только количество коммитов. Размер репозитория составляет около 500 Мб.
Можно выкачивать только нужные ветки, при желании.
UFO landed and left these words here
UFO landed and left these words here
Выкачать нужно один раз, поэтому проблем особых нет. Со скоростью работы с таким репозиторием тоже особых проблем не ощущается — тот же git status на моей машине отрабатывает за 150 ms. Основной источник «тормозов» — это переключение между ветками в случае, если ветки «долгоживущие».
У меня git status на непрогретом кеше идёт 2 сек, затем по 200мс, checkout 4000 файлов древней ветки 5 сек, мерж свежего мастера 6 сек, меня это ни сколько не печалит, страшнее процесс git gc при котором можно идти пить чай ;-)

Возможно сравнивается скорость работы с svn, при котором доступ к центральному серверу и его тормознутость способна вогнать в тоску…
«Цена» ветки в git — около 40 байт.
Размер репозитория растёт не очень быстро. У нас за больше чем 5 лет развития проекта исходники занимают всё ещё больше места чем вся папка .git (которая содержит всю историю проекта).

При выкачивании с нуля по сети передаётся примерно 70 Mb — 1-2 минуты, чтобы склонировать центральный репозиторий (включая время на локальную распаковку). Ежедневный инкрементальный pull из центрального репозитория занимает меньше 15-30 секунд.
Данная система, как я понимаю, подходит для небольших задач. Поправить то, добавить это.

А как быть, если нужно сделать новую большую функциональность?
Разработка которой требует пары недель, несколько разных программистов. Т.е. ветки будут передаваться друг другу и из надо периодически тестировать.
Так вот — где их тетсировать до выкладки в build ветку?
UFO landed and left these words here
Спасибо, неправильно осмыслил статью :)
Воспринял, что шоты только после создания билд ветки, хотя в статье, даже с картинками все описано.

Хотфиксы выкладываются вне очереди, или тоже ждут релиз?
UFO landed and left these words here
Хотфиксы выкладываются незамедлительно с помощью отдельного инструмента, который копирует по одному-два файла (mscp)
Так как для нас «master branch — копия продакшена», то да, если это действительно хотфикс — то выкладывается сразу разработчиком и коммитится в мастер релиз-инженером. Но есть и нюансы, связанные с исправлением статики и шаблонов — для них нужен полноценный билд.
UFO landed and left these words here
И даже многомесячные ветки были. Если не забывать регулярно в долгие ветки подтягивать свежий мастер — никаких проблем.

Тестируются до билда все ветки на девеле и (не ИЛИ, а именно И) в боевом окружении, в т.н. шотах. Шоты — тема для отдельной статьи, не буду отбирать у авторов этого великого творения право высказаться :)
Помимо шотов и одного стейджинга, для больших задач у нас есть ещё «запасной» стейджинг, на котором могут тестироваться большие и длинные задачи, которые не мержатся в общий build. Тем не менее, такое требуется весьма редко, обычно хватает описанной выше схемы (обратите внимание на функциональность шотов).
На HPC в прошлом году с удовольствием прослушал ваш доклад про быстрый деплой на 1000 серверов. Даже немного помучал вас вопросами.
Там вы, в том числе, рассказывали про схему разработки.
Я ещё немного помучаю про шоты:
— Зачем шот тестировать на боевом окружении? Есть ведь staging. Почему не оттестировать шот на разработческих серверах?
Каждая ветка-фича должна пройти шот?
— Как получить доступ к своему шоту? Как я понимаю, что-то типа 112233.badoo.shot?
— процесс выкладки шота полностью автоматический? Включая настройки nginx? Выкладывается сразу на все сервера? База в шотах боевая?
Зачем шот тестировать на боевом окружении? Есть ведь staging. Почему не оттестировать шот на разработческих сервера?

У нас шоты — это отдельный staging для каждой задачи. Поэтому не имеет смысла говорить о «шотах на разработческих серверах», потому что само понятие шота означает работу в production-окружении. Как было сказано ранее, сначала задачи тестируются на девел-серверах, потом в «шотах» и только потом на staging-сервере. Первый шаг исполняется на девел-сервере, последние два — в production-окружении.

Каждая ветка-фича должна пройти шот?

В целом — да, но есть исключения (например, ветка затрагивает работу над системой деплоя).

Как получить доступ к своему шоту? Как я понимаю, что-то типа 112233.badoo.shot?

Да

процесс выкладки шота полностью автоматический? Включая настройки nginx? Выкладывается сразу на все сервера? База в шотах боевая?

Процесс выкладки шота полностью автоматический, но он выкладывается только на один сервер. Nginx настроен таким образом, что достаточно просто создать новую папку ".../shot/<shot-name>", и он становится доступен по адресу "<shot-name>.badoo.shot".
Т.е. шот тестируется уже с боевыми базами. Как тогда проверить какой-либо функционал, который использует записи в базе?
Например, если написать blablabla в статусе то это увидят 100500 человек, хотя для них это не доступно (функционал ещё не введен).

P.S. Спасибо за подробные ответы :)
Как тогда проверить какой-либо функционал, который использует записи в базе?

Ну так ведь
Как было сказано ранее, сначала задачи тестируются на девел-серверах


А если какая-то фича ещё не введена, то обычно её сначала включают для разработчиков, потом для всех сотрудников, потом для фокус-группы. Ничего лишнего простой пользователь увидеть не должен. Это, в том числе, позволяет не делать очень долгоживущие ветки — можно релизить частями.
И ещё вопрос. Может невнимательно посмотрел, не увидел в статье.
На каком моменте удаляются ветки? Они удаляются вручную или автоматически?
Сколько у вас сейчас веток git branch --all?
Около 2500 веток, возможно более интересно сколько смержено с мастером и сколько нет: 2000 и 500 соответственно. Смерженные повисят некоторое время и удалятся автоматически.
UFO landed and left these words here
Ужас какой. Зачем вам столько веток? Почему бы не удалять смёрдженные сразу? Если нужна какая-то пометка, то целесообразнее использовать теги.
Чем плохо такое кол-во веток? Ну например, выполните git branch --contains <hash>
Зачем удалять если можно не удалять :) Технически ветки ничем не отличаются от тегов, лишние телодвижения по созданию тега, удалению ветки только усложнят и без того не простой процесс.
А баш-гит-комплитеру всё равно: он ищет и в ветках и в тегах.

$ time b --contains de88e382df3041d43f2aabca9e68a3aee8d1a2d3 PLATFORM-4227_pause_in_edit real 0m1.996s
Очевидно что эта команда роется только в локальных ветках, которых вовсе не 2000 штук, а не более 10. Возможно имелось ввиду git branch -a…
Мы весьма быстро удаляем смержденные ветки ;). У нас просто очень много тикетов в трекере, которые открыты одновременно и в которых ведется разработка.
А можете рассказать про миграцию БД? Она как-то привязана к этой схеме или используются другие механизмы для миграции и отката?
UFO landed and left these words here
У нас миграции DB в большинстве случаев безопасные. Либо мы добавляем новое поле — и оно ничего не ломает, потому что еще нигде не используется. Либо удаляем поле — это делается уже после вычистки кода от использования этого поля. Вобщем миграции к выкладке почти не привязаны, ничего нетривиального в них нет и особых проблем с ними тоже нет.
На основном сайте миграцию БД (с остановкой сайта на время миграции) мы не используем. Во внутренних сервисах миграция БД производится «руками». Если требуется существенное изменение схемы, мы временно останавливаем работу соответствующего компонента.
На HTC вы рассказывали, что релиз у вас собирает релиз-мастер. Вы его уволили? AIDA вы настроили недавно получается?
UFO landed and left these words here
Как разработчик использует этот тул? Т.е. это демон, gui утилита или маленький гномик вылезающий ночью из норки?
JIRA — веб-интерфейс
AIDA работает в виде демонов на разных серверах
Создание шота и выкладка на production производится с помощью консольных утилит
С другой стороны, вариант с гномиком тоже хороший.
Какую часть этой автоматизации пришлось писать руками? Сколько это примерно заняло времени, если это создавалось разом. Или за какой период вы от нету автоматизации смогли прийти к вашему решению?
Происходят ли сбои?
Большвя часть уже была написана, она была просто внедрена в teamcity в процесс автоматической сборки. Продумывание и реализация системы билдов, шотов, переходов между задачами было начато примерно год назад и продолжается по сей день, система всё ещё развивается. Автоматизация большинства вещей была сделана за пару месяцев.

Сбои происходят, но исключительно редко: после того, как всё настроено, оно работает как часы.
Спасибо за статью, прочел с удовольствием. Есть над чем задуматься, но вот меня всегда мучает вопрос, как проходит деплой базы, при столь больших объемах
UFO landed and left these words here
Как происходит контроль версии БД, слияние, Перенос изменений БД stage -> production
UFO landed and left these words here
Сколько времени ушло на проектировку и настройку AIDA в вашей компании? + Сколько людей было задействовано в этом процессе?
Работы над системой сборки и деплоя начались где-то год назад и продолжаются до сих пор.
AIDA спроектировали и сделали за пару месяцев, но она постоянно дорабатывается.
Если оценивать проектирование, разработку и инфраструктуру под ней то 5-6 человек
Интересно, какие ещё пасхалки кроме 1pm и 7pm я проглядел?
Only those users with full accounts are able to leave comments. Log in, please.