Процесс разработки Visual Studio 2012. Инструменты. Часть 1.
- modified:
- reading: 4 minutes
Как многие из вас уже знают – новая версия Microsoft Visual Studio 2012 уже доступна для скачивания всем желающим (если я правильно понял, я вижу ссылку). Для вас это значит, что вам можно наконец-то использовать новую версию для ваших проектов, а для разработчиков Microsoft это значит, что наконец-то можно говорить о нашем продукте. Сегодня я бы хотел вкратце поведать о процессе разработки внутри Microsoft, а так же самой Visual Studio. Напомню, что в Microsoft я работаю всего лишь чуть больше года (начал я работать 06/06/2011), поэтому, на самом деле, весь процесс я не знаю. Начал я разработку в самый уже не очень интересный момент, когда новые возможности добавлялись уже не так активно, а в основном допиливали то, что написали и чинили баги, поэтому весь процесс я точно не знаю. Попробую описать то, о чем можно говорить, а так же о чем знаю. Что-то может быть отдаленно от реальности, так как мои задачи достаточно ограничены, я разработчик, я мало знаю о том, как у нас гоняются тесты, как происходит процесс построения всей Visual Studio, как мы производим слияния бранчей, и т.п.
Мы используем TFS. Догфудим полным ходом. На MSDN помнится был пост, где расписывалась вся инфраструктура наших TFS серверов, но найти, к сожалению, не смог. Ветки в TFS у нас просто огромные, каждая весит больше 100 гигабайт точно (сколько точно – не знаю, так как у меня нет необходимости тащить все). Почему такие большие? А вы представьте, сколько разных команд сидит в нашем репозитории. Мне даже сложно представить, сколько времени займет скомпилировать всю Visual Studio на рабочей машине, думаю, что время будет близко к нескольким часам. Внутри команд есть зависимости в библиотеках, так, например, наш профилировщик (Microsoft Visual Studio Profiler) и анализатор кода (Code Analysis / FxCop) зависят от библиотек .NET Framework 4.5, а так же от Visual Studio Shell библиотек (и еще от кучи всего), разработка которых идет полным ходом вместе с тем, что разрабатываем и мы. Каким-то образом мне нужно всегда успешно компилировать мои библиотеки, чтобы мне не было необходимости перекомпилировать проекты, на которые мой код имеет зависимости, если мне вдруг потребуется новый функционал из этих библиотек. Поэтому, внутри репозитория у нас есть список библиотек, которые мы публикуем для других команд. Каждая команда сама решает, какие библиотеки им публиковать, а какие нет, чтобы точно знать какие зависимости от других команд у них имеются. И чтобы знать, что им можно менять без спроса, а что им нужно менять очень осторожно, чтобы не сломать билд другой команде. Для managed библиотек не обязательно публиковать полные версии библиотек, можно просто публиковать версии библиотек с метаданными, но без кода, чтобы уменьшить репозиторий хоть немного, ну а для native библиотек необходимы только файлы заголовки (header). Совместно с разработкой Visual Studio, так же идет разработка и новой версии Windows, компиляторов, да даже хотя бы msbuild утилиты вместе с tfs клиентами, поэтому нам просто приходится все складывать в репозиторий, чтобы не было таких проблем, что приходится обновлять наши билд машины с каждым breaking change внутри Windows (сами понимаете, что они тоже бывают часто). У нас нет зависимостей из нашего репозитория наружу, даже все тулы, которые используются для построения библиотек, инсталлятора и всего остального лежат внутри (насколько я знаю).
Вообще, не смотря на огромные бранчи, работает у нас все так же, как если бы я поставил дома TFS сервер для маленького проекта, все с такой же скоростью, нет никаких отличий. Конечно, народ говорит, что, когда только TFS внедряли в разработку Visual Studio, было все по-другому, было огромное количество проблем, TFS работал ужасно медленно. Когда это было точно, честно не знаю, может при разработке 2008 или 2010 версии.
Бранчи у нас распределяются и по командам, а так же и по версиям. Все это обговаривается на уровне менеджеров, кто с кем будет работать, в каком бранче и т.п.
Наши билд сервера строят с каждого живого бранча новую версию Visual Studio каждую ночь, совместно прогоняя интеграционные тесты, а так же тесты производительности. Представляете, что значит поломать билд Visual Studio? Честно, я такого не помню, чтобы кто-то ломал что-то. В основном, поломки идут, когда происходят слияния бранчей, тогда билд немного откладывается, но часто все фиксят с утра, и после обеда или ближе к вечеру билд все-таки приходит. Строятся все активные SKU (Ultimate, Express и что там еще у нас есть, не знаю). Если вы посмотрите в окно About в Visual Studio 2012, то вы обнаружите версию 11.0.50727.1 RTMREL, что означает: построили мы ее с бранча RTMREL, а так же можно догадаться, что из версии можно выдрать число, когда мы ее построили (07.27, а что значит 5 перед ними – я понятия не имею). Иногда я вижу, что мы строим так же разные языковые версии, иногда все языки, иногда только некоторые, каким образом происходит выбор, какие языковые пакеты нужно строить сегодня – я не знаю. Знаю только, что строят все, когда мы выпускаем RTM, что логично. J