пятница, 17 декабря 2010 г.

Хаки TFS: переконфигурирование TFS 2010 на другую базу данных

Я решил начать писать серию коротких статей под общим названием Хаки TFS.

Чтобы переконфигурировать TFS

1. Сделайте бэкап базы проектов из имеющегося экземпляра SQL Server.

2. Отключите имеющуюся Project Collection.

3. Запустите CMD с правами администратора, перейдите по адресу %SystemDrive%\Program Files\Microsoft Team Foundation Server 2010\Tools.

4. Выполните команду tfsconfig setup /uninstall:all

Она сбросит настройки TFS.

5. Теперь восстановите базу проектов на новый экземпляр SQL Server и заново сконфигурируйте его.

Удачи!

вторник, 14 декабря 2010 г.

Набор отложенных изменений (Shelvesets), ветвление (Branching) и объединение (Merging) в Team Foundation Server 2010

 

Shelving (откладывание)

Бывают ситуации, когда вы не готовы коммитить ваш исходный код в репозиторий. Например, вы работаете над исправлением проблемы и вы хотите поделиться изменениями с вашими коллегами для совместной работы над исправлением проблемы. Откладывание изменений (shelving) позволяет вам хранить файлы и исходный код отдельно во временном хранилище. Набор отложенных изменений, которые еще не были закомиченны на сервер, называются shelvesets.

Процесс создания shelveset быстрый и простой. Для начала перейдите в окно Pending Changes (View->Other Windows->Pending Changes). В этом окне выберите элемент, который вы хотите отложить (shelve) и нажмите кнопку Shelve (рис.1).

image

Рис.1

В диалоговом окне Shelve появятся выбранные вами файлы. Теперь вы можете изменять элементы и сохранять изменения с помощью Shelve. Вы также можете проверять настроенные политики и заметки Check-in до выполнения Shelve.

Набор отложенных изменений имеет  такой же уровень описательной информации, как и набор изменений, включая ассоциированные задачи, комментарии и check-in заметки. Запомните, что в отличие от набора изменений (changesets), изменения в shelving не поддерживают версионирования. Также вы можете удалить набор отложенных изменений навсегда, чего нельзя сделать с набором изменений. Вы не можете сослаться напрямую на набор отложенных изменений из задачи и политики не могут быть обязательными в отложенных изменениях.

Так когда же нужно использовать эту функцию? Существует несколько сценариев. Скажем, менеджер проекта попросил вас приостановить свою работу и проправить баг. Код, который вы уже написали не достаточно хорош для выполнения check-in, но нужен другим членам команды. Вы можете отложить изменения (shelve) позволив таким образом другим членам команды работать с ним. Отложенные изменения так же полезны как инструмент бекапа и может быть использован для передачи незаконченного кода другому члену команды.

Возврат исходных файлов (Unshelving) так же прост, как их откладывание (Shelving). В окне Pending Changes нужно кликнуть на кнопку Unshelve. Появится окно, в котором нужно выбрать владельца отложенных изменений и набор. Из этого окна можно как вернуть их в проект, так и удалить.

А теперь хак или фича TFS. Не знаю, должно ли быть так, но оно так: если вы попробуете сделать Unshelve после Shelve, вас ждет разочарование (рис. 2).

image

Рис.2

Я не знаю, ошибка это, баг или фича, но чтобы можно было сделать unshelve – нужно сначала вновь вернуть файлы из репозитория, а потом сделать unshelve. Простой способ – в окне Pending Changes выбрать нужные файлы и в контекстном меню нажать Undo.

 

Branching (ветвление) и Merging (объединение)

Ветвление и объединение – две важных функции в любой системе контроля версий. В процессе разработки программного обеспечения вы всегда сможете найти необходимую версию например для бета-тестирования или вы хотите параллельно исправлять ошибки без остановки основного процесса разработки. Для лучшего управления процессом разработки вы можете создать много версий одной и той же кодовой базы (ветвление) и потои снова интегрировать ветки в друг в друга (совмещение).

Возможно вы слышали о таких понятиях, как прямая интеграция и обратная интеграция. В контексте ветвления и совмещения прямая интеграция – это процесс выделения изменений из основной кодовой базы разработки в ветку. Обратная интеграция – это прямо противоположное: вы возвращаете изменения, сделанные в ветке в основную кодовую базу. На рис.3 показаны несколько сценариев, где используется ветвление и объединение.

image

Рис.3

На данном рисунке ветка создается из версии 1.0 для создания релиза для пользователей или бета-тестеров. В версии 1.1 найдены критические ошибки. Отдельная ветка создается для исправления этих ошибок. Исправления завершаются к версии 1.1.2 и интегрируются в версию 1.4 основной ветки.

 

Branching (ветвление)

Ветвление позволяет вам не только создавать копии файлов исходных текстов, но и управлять историей изменений в том случае, если вы захотите сделать объединение в будущем. Вы можете использовать Source Control Explorer для навигации между различными ветками. Для создания ветки просто кликните правой кнопкой мыши на папке или ветке, содержащей ваше решение в Source Control Explorer. Выберите Branch and Merging и затем Branch из контекстного меню. Вы увидите диалоговое окно, показанное на рис.4.

image

Рис.4

Диалоговое окно Branch содержит несколько опций. Поле Target позволяет вам выбрать имя вашей ветки. Опция “Branch from version” позволяет вам выбрать, какую версию для ветки вы хотите использовать (например последнюю или более раннюю). Вы можете опционально создать локальную копию ветки выбрав “Download the target item to your workspace”. Она загрузит только что созданные вами файлы ветки в вашу рабочую область.

На этом этапе, ветка только ожидает внесения изменений в систему контроля версий TFS. Для завершения процесса ветвления откройте окно Pending Changes и выполните Check-In.

Замечу, что наиболее быстрый способ создания ветки – правый клик на папке и пометка как Branch (для этого есть отдельная Branch-иконка в Source Control Explorer). При этом отобразится диалоговое окно, показанное на рис.5

image

Рис.5

Когда вы нажмете кнопку Branch, произойдет процесс ветвления и выполнится Check-In за одну операцию. Не нужно дополнительно делать Check-In. К тому же такой способ гораздо быстрее, в особенности, когда вы создаете ветку проекта, содержащего много тысяч файлов.

Одна из  новых функций в ветвлении в Visual Studio 2010 – визуализация веток. В ранних версиях Visual Studio, не было удобного способа просмотра информации о ветвлении. Эта проблема была решена в Visual Studio 2010. Для того, чтобы воспользоваться этой функцией кликните правой кнопкой по ветке, выберите Branching and Merging и затем нажмите View Hierarchy. Откроется новое окно, показанное на рис.6.

image

Рис.6

Используя выпадающее меню вы можете изменять режим отображения элементов во вкладке. Вы также можете выбрать ветку для визуализации, открыть ее и сравнить с другой веткой, создать новую ветку или обьединить ветку с ее родительским элементом.

 

Merging (объединение)

Объединение означает комбинацию изменений из двух и более веток. Эта функциональность очень полезна для параллельно работающих команд. В процессе объединения большое количество изменений интегрируются, включая операции добавления, редактирования, удаления. Если процесс объединения вызывает конфликт между ветками, вы можете решить проблему несколькими способами, например использование инструмента diff-merge.

Есть два способа объединить файлы: использовать Source Control Explorer или командную строчку. Вы также можете указать, хотите ли вы возвращать все изменения, или изменения конкретной версии.

Когда вы производите объединение, система контроля версий TFS использует историю для того, чтобы находить файлы или папки, изменившиеся в другой ветке. Изменения, которые не существуют в текущей ветке будут интегрированы. Если файлы или папки менялись в текущей ветке – возникнет конфликт объединения.

Вы можете воспользоваться мастером объединения (Merge Wizard) в Source Control Explorer, кликнув правой кнопкой мыши по папке, которую хотите объединить. Как вариант, можно воспользоваться кнопкой Branching and Merging, и в выпадающем меню выбрать пункт Merge. Вы увидите окно Source Control Merge Wizard (рис.7).

image

Рис.7

Source Control Merge Wizard покажет вам список веток, с которыми вы можете совместить выбранную ветку, а так же предложит выбрать набор изменений для совмещения (или все, или какой-то выбранный). Кликнув на кнопку Next вам будет представлена возможность выбора набора изменений для совмещения (рис.8).

image 

Рис.8

Все готово, можно нажимать кнопку Finish и произойдет совмещение.

Visual Studio 2010 также представляет вам графический способ совмещения с возможностью перетаскивания наборов изменений по ветке. Когда мы смотрим на историю объекта в системе контроля версий, одна из опций – Track Changeset. Для этого нужно кликнуть правой кнопкой мыши по набору изменений, выбрать Track Changeset. Будет открыта вкладка Changeset Tracking. Изначально откроется иерархическое представление. Нажмите Timeline Tracking в этой вкладке для просмотра различных веток системы контроля версий и посмотрите как наборы изменений перемещаются между ветками (рис.9).

image

Рис.9

Эта визуализация достаточно удобна, потому что вы можете просто определить, где наборы изменений полностью или частично объединялись в ветки. Вы можете также выполнять объединение просто перетаскивая набор изменений из одной ветки в другую. Выполнение этого действия открывает окно Merge,  рассмотренное ранее.

Начав выполнять ветвление и объединение вы встретитесь с конфликтами, которые должны быть решены. Visual Studio 2010 предоставляет механизм решения конфликтов для упрощения этой задачи. Конфликты будут отображены в разделе Conflicts окна Pending Changes (рис.10) и будут предложены варианты их разрешения.

image

Рис.10

Удачи в работе!

Об этом и гораздо больше можно почитать в книге Professional Application Lifecycle Management with Visual Studio 2010

воскресенье, 12 декабря 2010 г.

Подкаст ПолДевятого. Выпуск 13. О Microsoft Exchange Server из первых рук

Сегодня у нас в гостях Никита Кожекин - разработчик из команды Microsoft Exchange Server.

В выпуске слушайте:
  • Чем занимается Никита
  • Что внутри Exchange Server?
  • Как происходит разработка и тестирование
  • Будущее Exchange Server
  • Облака - это то, что ждет нас всех уже завтра?
  • Особенности работы в Microsoft
  • Windows Phone 7 для всех сотрудников Microsoft - блеф и инсинуации?
  • Слушать>>

    пятница, 10 декабря 2010 г.

    Создание и администрирование политик Check-In в Team Foundation Server 2010

    Политики Check-In позволяют командам и индивидуальным разработчикам повысить качество кода и рабочего процесса управления исходным кодом, используемого в команде.

    Для настройки этих политик кликните по вашему проекту Team Foundation Project в Team Explorer и выберите Team Project Settings => Source Control (рис. 1).

    image

    Рис.1 

    Перейдите в раздел Check-In Policy, там вы найдете набор опций для настройки политик check-in. Нажмите Add (рис.2).

     image

    Рис.2 

    Давайте запретим делать коммиты без комментариев. Добавим Changeset Comments Policy. Так же потребуем, чтобы перед Check-In нужно было проверить код анализатором кода CodeAnalysis. (если очень нужно сохранить кусок неготового кода, в TFS 2010 есть режим Shelving). Если добавление Comment Policy прошло без вопросов, то политика анализа кода решила уточнить, чего же мы от нее хотим (рис.3). Список правил содержит подробные комментарии.

    image

    Рис.3

    Теперь при попытке сделать CheckIn TFS заставит вас сделать серию телодвижений, чтобы защитить репозиторий от непротестированных, нехороших или просто некоментированных коммитов.

    четверг, 9 декабря 2010 г.

    Основы непрерывной интеграции с помощью Team Foundation Server 2010

    Team Foundation Server – это гораздо больше, чем просто сервер непрерывной интеграции. Он включает в себя систему контроля версий, управление задачами, интегрируется с SQL Server для предоставления отчетов. Это комплексное решение для организации коллективной разработки ПО.

    В этой статье мы коснемся непрерывной интеграции в Team Foundation Server 2010.

    Конфигурирование TFS Build

    Пользователи TFS 2010 используют билд-контроллеры для управления задачами построения сборок ПО. Вы можете установить его на один сервер или распределить процесс сборки между несколькими серверами. Пул агентов сборки – набор из одного или нескольких агентов сборки. Агенты сборки – это сервисы, которые могут быть установлены на той же или отдельной машине для распределения задач сборки.

    TFS предоставляет билд для сборки билд-контроллеру. Билды выстраиваются в очередь и выбираются один за другим по приоритетности и передаются билд-агенту. Билд-контроллер проверяет пул билд-агентов и выбирает подходящего для выполнения сборки. После того, как сборка завершена, билд-агент сохраняет результат и уведомляет о завершении сборки.

    До того, как вы добавите билд для сборки в очередь билдов, вы должны определить ее (рис.1).

    image

    Рис.1

    В случае если вы еще не добавили билд-сервис, билд-контроллеры и агенты – это нужно сделать в разделе Build Configuration в TFS Administration Console (подробная информация по настройке есть в MSDN, например тут http://msdn.microsoft.com/ru-ru/library/dd793166.aspx).

    Вы можете создавать сборки непрерывной интеграции (при CheckIn в репозиторий), запланированные сборки и т.д.

    После того, как вы дали имя вашему новому определению сборки, выбираем ее тип (рис. 2):

    image

    Рис.2

    Возможные типы:

    • Manual (ручная) – фактически это не триггер. Он говорит TFS ничего не делать до того, пока мы не поставим билд в очередь вручную.
    • Continuous Integration (непрерывная интеграция) – триггер следует строгим принципам непрерывной интеграции, и делает билд после каждого Check-In.
    • Rolling builds (повторяющийся билд) – эффективен, если разработчики в вашей команде делают check-in быстрее, чем процесс сборки. Таким образом Check-in будут накапливаться и строиться не чаще, чем через определенное время.
    • Gated Check-in (гейт) – защищает репозиторий от попадания в него плохого кода. Компилирует код и запускает модульные тесты до check-in. Если обраруживаются проблемы – check-in не происходит.
    • Sсhedule (график) – самый простой триггер, который организует ваши билды по расписанию, например ночные или билды по выходным.

    На этом этапе давайте выберем режим ежедневной сборки в обеденный перерыв (Schedule) по будням. На вкладке Workspace мы можем выбрать рабочую папку, которую будет использовать билд-агент и папку расположения исходных текстов.

    На вкладке Build Defaults выберите билд-контроллер, который будет использоваться для построения и выходную папку, куда билд-агент будет копировать результаты сборки и лог-файл (рис.3). Это может быть например сетевое хранилище, конечно при условии, что у вас достаточно прав на использование его.

    image

    Рис.3

    Давайте теперь посмотрим на вкладку Process (рис.4). Определения процесса сборки (Build Definition) в TFS 2010 хранятся в файлах XAML и Windows Workflow Foundation.

    image

    Рис.4

    Если вы используете шаблон по умолчанию (Default Template), вы должны выбрать элементы, для которых будет происходить построение из репозитория системы контроля версий. Это например может быть файл решения. Так же это может быть скрипт MSBuild.

    Выберем файл решения для построения. Переходим на последнюю вкладку сохранения информации о билде (Build Retention). Тут мы можем определить, сколько времени хранить информацию о билдах (рис. 5).

    image

    Рис.5 

    Все готово. Теперь каждый день в 13:20 будет выполняться билд (обеденное время), и прийдя с обеда можно исправить ошибки сборки. Для моего проекта билд при каждом Check-In кажется избыточным, тестерам нужно еще протестировать результат сборки.

    Проверить как все работает можно, сделав сборку вручную. Для этого можно в Team Explorer попросить собрать новый билд в контекстном меню вашей конфигурации сборки (рис 6, рис.7).

    image

    Рис.6

    image

    Рис.7

    В этой статье я не рассмотрел процесс конфигурирования MSBuild и множество других тонкостей. Мне хотелось бы, чтобы она послужила стартом к работе с TFS 2010 в плане обеспечения непрерывной интеграции.

    Более подробно можно будет почитать в книжке: Continuous Integration in .NET