Процесс разработки Visual Studio 2012. Инструменты. Часть 2.
- modified:
- reading: 4 minutes
В команде Visual Studio, как в и большинстве других команд внутри Microsoft, все используют виртуальные машины. Представьте, что значит разрабатывать Visual Studio: это огромный продукт, который каждый день приходится обновлять новыми скомпилированными компонентами, чтобы убедиться, что все ваши изменения работают. Так же приходится обновлять компоненты других команд, на которые ваш компонент завязан, так как вам может потребоваться определённая новая фича из этой компоненты. Как быстро эта машина сможет так засориться, что вы уже забудете, что вы обновляли, а что нет, какие компоненты не работают, потому что вы обновили их зависимости, но не их самих? Примерно раз в месяц (даже чаще, около 3х недельного цикла, как раз время спринта) ваша инсталляция (Windows + Visual Studio) становится настолько старой и не стабильной, что придется обновить чуть ли не все компоненты, чтобы все заработало как нужно. И я уже молчу о том, что у вас есть зависимости от свежих сборок Windows, обновить которые совсем не просто. Проще просто завести новую систему, и поставить туда свежий билд Visual Studio, чем стараться разобраться, почему в определенный момент времени все перестало работать. Ну и представьте, сколько времени бы уходило, если бы все это делали вручную, ставили Windows, затем Visual Studio, подключали к домену, настраивали права?
У каждого работника, обычно, есть минимум два компьютер, на одном из которых 100% рабочая система, основная работа которой заключается в возможности читать почту и запускать Remote Desktop к остальным компьютерам. Вторая система, обычно, помощнее, на которую устанавливается стабильный Windows Server и включается роль Hyper-V. На оба компьютера ставится специальное внутреннее программного обеспечение, которое позволяет очень просто создавать виртуальные машины с определенной версией Windows, а так же с определенной версией Visual Studio на борту. То есть, примерно, полминуты тратится на то, чтобы выбрать нужную сборку Windows, а так же сконфигурировать задачи, которые нужно выполнить после инсталляции системы, вроде поставить Visual Studio определенной версии. А затем где-то через 20-30 минут принимать работу. За эти 20-30 минут, понятное дело, можно спокойно работать на старой виртуальной машине. Очень просто и замечательно, да? Это все нам обеспечивают обычные разработчики внутри Microsoft, которые занимаются именно внутренними продуктами, для поддержки всей этой инфраструктуры. Так же у нас где-то есть какое-то там облако, которое можно использовать под такие виртуальные машины, но у меня как-то сложилось, что я его не использовал, потому что не знал как, а когда узнал – меня устраивало и то, что я могу то же самое сделать и локально. Хотя, наверное, в облаке все будет быстрее и ресурсов будет не ограничено. В общем, просто так сложилось.
Самый главный вопрос, а в чем же пишется Visual Studio? На самом деле тут очень сильно зависит от команды и от выполняемых задач. Мы на данный момент стараемся придерживаться схемы Visual Studio 2012 + SDK + Visual Studio 2012 Experimental Instance. Experimental Instance – это одна из возможностей VS SDK разрабатывать расширения для VS. Она позволяет инсталлировать пакеты в некий Sandbox, который совсем не связан с самой Visual Studio, что позволяет не ломать основную инсталляцию Visual Studio. Кто-то используют самые обычные редакторы, даже notepad для некоторых задач. Но есть внутри Visual Studio еще один замечательный продукт, который поставляется вместе с внутренней инфраструктурой – это специальная версия Visual Studio, которая устанавливается просто распаковыванием архива. Эта версия полностью независима от той, что уже установлена в системе, и полностью не зависима от .NET Framework, установленного в системе. Работает она при помощи следующего: перед тем как запустить managed приложение – вы указываете в environment пару значений, которые отвечают за расположение CLR Runtime и базовых библиотек (.NET Framework BCL, а так же всего GAC), после этого ваше managed приложение будет грузить сборки из тех мест, которые вы указали, а не из GAC вашей системы, как это бывает обычно. Более подробно об этом можно почитать в блог посте DEVPATH. У этой portable версии Visual Studio есть свои недостатки. Это не полностью идентичная Visual Studio, а специальная образом собранная, которая часто не очень хорошо отшлифована.
С исходными кодами у нас так же хранятся набор утилит и сриптов, одна из утилит – это всем хорошо известный msbuild. Чтобы msbuild работал без зависимости на установленную среду: версию Visual Studio и .NET Framework на машине, мы используем все тот же подход с DEVPATH. То есть, чтобы запустить этот msbuild, нужно запустить сначала специальную командную строку с определённым набором выставленных environment variables. Очень похоже на Developer Command Prompt, поставляемый с Visual Studio. То есть это обычный bat файл, который выполняет определенные команды перед тем, как передаст вам управление. Если исхитриться и сделать так, чтобы проектная система не зависела от этих определенных environment variables, можно добиться того, чтобы проекты можно было собирать как в этой специальной среде, так и в Visual Studio, установленной на системе, что мы сейчас и делаем.
Продолжение следует…