Tc open-doors-day-speech

Editor's Notes

1. Мы тестируем наши продукты несколькими способами....Чтобы понять с какими именно цифрами мы имеем дело – обратимся к статистике внутреннего билдсервера.
2. Начнем с TeamCity.Мы с коллегами разрабатываем CI сервер, ключевой компонент которого – интеграция с различными VCS. В данный момент это все популярные VCS существующие на рынке.Следуя принципу поедания собачей еды мы храним исходный код различных компонент нашей системы в 5 VCS.Как результат – мы не используем FB. Создавать бранчи одновременно в нескольких VCS – плохая идея. Мы считаем, что плюсы приносимые dogfooding-ом продукту перевешивают неудобства, ощущаемые разработчиками.Еще одной особенностью работы в команде TeamCity является то, что внесенные изменения попадают на внутренний билдсервер уже на следующий день. В такой ситуации плохой код, попавший в релиз, может привезти к невозможности собрать билд (релиз, EAP) любого из (всех) продуктов.Как же тогда мы вообще делаем какие либо изменения, развиваем наш продукт? Ответ - Мы все же используем бранчи, но другого рода.
3. А именно – к опыту .NET команды. Конкретнее – к ситуации, которая сложилась пару лет назад.В то время коллеги из .NET команды хранили свой код в Subversion, ни о каких FB речь так же не шла. Так же активно использовался Remote Run.При этом у них в проекте было более 33000 тестов, на их исполнение TeamCity требовалось более 3-ех часов.Почему эти цифры важны?Дело в том, что TeamCity имеет ограниченное количество build агентов, на которых он может запускать билды. При условии, что билды стартуют часто и длятся долго, возникает ситуация когда в один билд могут попасть изменения, сделанные разными разработчиками. У команды ReSharper – в билде часто было несколько десятков (до сотни) изменений. Если в таком билде упали тесты (сотни тестов в случае R#), задача исследовать причину падения становится сложной, а иногда и почти невыполнимой.Как результат – в билде R# практически всегда падали те или иные тесты.Для того чтобы хотя бы иногда получать зеленый билд была сделана настройка – 42 любых теста падает - ok.Еще хуже обстояла ситуация с Remote Run (персональными) билдами.Когда вы запускаете персональный билд – единственное что вас интересует, проходят ли тесты с учетом именно ваших изменений. На деле же в проекте размера R# с момента когда вы инициировали билд до момента, когда билд запустился проходит длительное время. Действительно – ведь все билд агенты всегда заняты выполнением других тяжеловесных билдов, а ваш билд все это время ожидает в очереди. Ваши коллеги все это время так же не дремлют, с удовольствием комитят в единственный доступный бранч свои ченжи. В итоге билд в который вошел ваш персональный ченж часто падал уже на этапе компиляции, не говоря о тестах. Все приходилось повторять снова и снова. Вместо того, чтобы сосредоточиться на свой функциональности, разработчик был постоянно озабочен статусом своего персонального билда. О высокой продуктивности конечно речи и быть не может.Действительно, Remote Run не дает полной изоляции вашим изменениям, они попадают в билд вместе с другими возможно конфликтующими измененениями.
4. В это время у нас появлялись фичи, которые в том числе можно было использовать, как workaround-ы проблемы.Описание фич.Общая идея все этих фич – уменьшение времени персонального билда и как следствие уменьшение вероятности, что кроме персонального патча в билд попадут чужие изменения.Появление описаной функциональности конечно не могло полностью решить проблему.
5. Одновременнно – все большее распространение стали получать DVCS. Создание и работа с ветками в которых были сильно упрощены. .NET командой было принято решение мигрировать с Subversion на Hg.Аргументами за выбор именно этого VCS были:Похожий на Subversion синтаксис командЛучшая по сравнению с Gitпроизводительность в Windows.После миграции стало возможно использовать FB, это действительно помогло стабилизировать состояние главного бранча. Зеленые билды стали собираться гораздо чаще.
6. В связи с растущей популярностью DVCS, а так же в связи с тем что наши коллеги начали использовать FB, мы добавили их поддержку в TeamCity.В частности, появилась возможность отслеживать статус (запускать билды) FB.Для этого нужно сказать TeamCity бранчи с какими именами нужно отслеживать и запушить свой FB в основной репо (тот, на который смотрит TeamCity).Так же появилась возможность иметь отдельную историю запусков тестов для каждого бранча. То же самое – для статистики, собираемой в процессе билда.В свежей версии 8.0 появилась поддержка hg сабрепов. Очевидно, что заказчиками этой функциональности являются коллеги из .NET команды.Описанная функциональность в полной мере работает для Gitи Hg. Но в связи с постоянными просьбами пользователей не DVCS поддержать такой же воркфлоу, некоторые вещи работают и для других VCS.Например можно помечать билд как запущенный на том или ином бранче.Вообщем то с появлением поддержки FB в TC у .NET команды должно было бы быть все хорошо. Так оно в принципе и было. Пока не случился HUGE merge.Проблемма вобщем то известная, часто упоминается противниками FB, как недостаток подхода.Чтобы понять, как именно эта ситуация случилась в .NET команде, нужно немного больше узнать о том как разрабатываются наши .NET продукты.
7. Конкретно нас интересует то, что существуют так называемые “саб-платформы”. Это набор сервисов, совместно используемых несколькими продуктами.��апример, используя .NET Platform продукт получает интеграцию с VS, компонентную модель, проектную модель и так далее. Так же в отдельный модуль выделены сервисы предоставляющие модель кода продуктам.Как видно из диаграммы продукт может использовать не все саб-платформы. К примеру TeamCity VS Addin для работынужна интеграция с VS, но не нужна модель кода.Более детально об этой кухне расскажет Сергей Балтийский в своем докалде, кстати очень рекомендую его посетить.Саб-платформы на уровне VCS подключаются как hg сабрепозиторииРазработчики всех .NET продуктов вносят изменения в платформу.
8. Теперь несколько слов о структуре бранчей в самой платформе.Есть бранч stable – это та версия на которую при время от времени мигрируют продукты. Стабильность этого бранча – компетенция коллег из команды, котрая занимается только платформой. У каждого продукта есть свой default бранч, ответвленный от stable. Время от времени в этот бранч мержатся новые комиты из stable. Решение о продвижении ревизии принимает конкретная продуктовая команда. Соответственно они же ответственны за стабильность этого бранча.Это неплохая схема, так как она позволяет конкретному продукту зафиксировать версию платформы в своем релизе и в последствии делать точечные фиксы в платформе, необходимые для bug fix апдейтов именно их продукта. Все эти бранчи живут в центральном репозитории, соответственно TeamCity предоставляет возможность запускать тесты относительно этих бранчей.Опять таки – звучит неплохо, НО!Эта схема так же подразумевает, что изменения, которые делаются разработчиками продукта, оседают именно в продуктовых default-ах. Время от времени специально обученные люди (а по факту один человек из платформенной команды) пытаются смержить все изменение сделанные в продуктовых дефолтах с измненениями сделанными в самой платформе без участия коллег из продуктов.Понятно, что никакой синхронизации между продуктами при такой схеме гарантировать нельзя, нельзя всем ходить на один стендап и рассказывать друг другу о том, какие именно изменения в платформе вы делаете.А значит некоторые из изменений, сделанные разработчиками из разных команд конфликтуют.Именно такая ситуация и произошла с .NET командой, когда они попытались сформировать новый stable бранч платформы. Мерж длился действительно долго. При этом некоторые продукты ожидали измнения, которые должны были появиться в новой стабильной версии платформы.Вот такая грустная история.<Вопрос залу о выходах из ситуации>Мне видятся два возможных решенияМерж в stable – duty of product guysАвтоматический detect таких ситуаций с помощью TeamCityНа этом все. Чуть не забыл, я ведь не ответил на вопрос озвученный в теме доклада.