Руководства

Применяйте политики возврата для проверки качества кода

Сочетание политик анализа и тестирования кода позволяет осуществлять контроль его качества. Например, при помощи стандартной политики тестирования можно указать, что код будет допущен к возврату в систему управления исходным кодом TFS только после проведения заданных тестов. Вы также вольны настроить политику анализа кода, чтобы гарантировать соответствие кода заданным стандартам качества, то есть, соблюдение правил безопасности, производительности, переносимости, удобства сопровождения и надежности.

Чтобы применить политику анализа кода при возврате в систему управления исходным кодом, выполните следующие действия:

1. В окне Team Explorer щелкните правой кнопкой нужный командный проект, раскройте подменю Team Project Settings и выберите команду Source Control.
2. Перейдите на вкладку Check-in Policy, щелкните кнопку Add, а затем выберите и настройте определенную политику.

Дополнительные ресурсы

• Дополнительную информацию о создании пользовательской политики возврата вы найдете в разделе "Как создать собственную политику возврата TFS " этой книги.
• О настройке политики возврата читайте в статье "Walkthrough: Customizing Check-in Policies and Notes" по адресу http://msdn2.microsoft.com/ en-us/library/ms181281(VS.80).aspx.
• Пример кода с запретом на возврат определенных фрагментов вы найдете в статье "Checkin Policy to Disallow Certain Patterns" по адресу http:// blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx.
• Пример запрета на возврат кода без комментариев вы найдете в статье "Sample Checkin Policy: Make Sure the Comment Isn't Empty" по адресу http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx.
• О том, как зарегистрировать созданную вами политику, читайте в статье "I've Made a New Check-In Policy! How Do I Add It?" по адресу http:// blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx.

Следите за перекрытием политики

Система Team Foundation Version Control не предотвратит перекрытие политики. Однако, выполнив следующие действия, вы сможете установить факт перекрытия политики:

• Используйте службу Team Foundation Eventing Service из Team Foundation Core Services API, чтобы внедриться в события возврата.
• Напишите метод Notify, который анализирует параметры набора изменений и реагирует на перекрытие, если оно случится.

Другой способ заключается в просмотре истории набора изменений с целью обнаружения перекрытий политики.

Дополнительные ресурсы

• Дополнительную информацию о перекрытии политики возврата вы найдете в статье "How to: Override a Check-in Policy" по адресу http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx.
• Дополнительную информацию о службе Team Foundation Eventing Service вы найдете в статье "Eventing Service" по адресу http://msdn2. microsoft.com/en-us/library/bb130154(vs.80).aspx.
• Чтобы узнать, как настроить отправку уведомлений по электронной почте при нарушении политики, читайте запись в блоге по адресу http://blogs. infosupport.com/marcelv/archive/2005/10/18/1635.aspx.

Избегайте конфликтов при помощи планирования

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

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

Чтобы выяснить, извлек ли кто-то файл или нет, выполните следующие действия:

1. В окне Team Explorer в Visual Studio щелкните дважды Source Control.
2. Перейдите в папку, содержащую файл, который вы хотите проверить. Для всех незавершенных изменений указано имя пользователя, владеющего этими изменениями.

Чтобы узнать, для каких файлов в данный момент имеются незавершенные изменения, в командной строке Visual Studio 2005 введите следующую команду:

Tf status /format:detailed /user:*

Начиная работу с файлом исходного кода, который будет задействован кем-то еще, сообщите другим членам команды, что работаете над файлом и поясните, что конкретно будете обновлять.

Дополнительные ресурсы

• Дополнительную информацию о просмотре отложенных изменений в рабочей области вы найдете в статье "How to: View and Manage All PendingChanges in Your Workspace" по адресу http://msdn2.microsoft.com/en-us/library/ms181400(VS.80).aspx.
• Дополнительная информация о просмотре отложенных изменений в других рабочих областях находится в статье "How to: View Pending Changesin Other Workspaces" по адресу http://msdn2.microsoft.com/en-us/library/ms181401(VS.80).aspx.

Получение и блокировка кода

• Перед внесением изменений извлеките последнюю версию исходного кода.
• Осмотрительно пользуйтесь командой lock.
• Предупредите коллег о блокировке файла.

Перед внесением изменений извлеките последнюю версию исходного кода

Перед извлечением кода для редактирования убедитесь, что имеете дело с последними версиями всех файлов исходного кода проекта. Чтобы получить их, запустите команду get latest. Если этого не сделать, есть опасность того, что вы будете писать код в устаревших версиях файлов, а последующий возврат вашего кода на сервер приведет к проблемам со сборкой.

Чтобы получить последние копии файлов, относящихся к тому или иному проекту, щелкните правой кнопкой командный проект в окне обозревателя Source Control и выберите команду Get Latest Version. Если в данный момент в вашей рабочей области имеются записываемые файлы с незавершенными правками, эти файлы не будут перезаписаны. Эту команду можно запустить и из командной строки, введя Tf get /all в папке, сопоставленной с текущей рабочей областью.

Дополнительные ресурсы

• Дополнительные сведения о команде Get вы найдете в статье "GetCommand" на сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/fx7sdeyf(VS.80).aspx.

Осмотрительно пользуйтесь командой lock

Не стоит слишком увлекаться использованием команды lock. Блокирование файла во время работы над ним может отрицательно сказаться на производительности всего процесса разработки, поскольку другие пользователи не смогут одновременно работать над этим же файлом. Блокировка файла на время редактирования нужна только в случае, если вы опасаетесь возникновения конфликтов, которые могут вынудить вас выполнять сложное ручное слияние. По возможности разрешайте совместную работу, во время извлечения файла устанавливая тип блокировки None.

Ниже приведены сценарии, при которых использование команды lock оправдано:

• Вы корректируете файл в двоичном формате, например, изображение или документ, слияние которого затруднено.
• Вносимые вами поправки настолько распространены, что другой разработчик, работая над тем же файлом, скорее всего, изменит те же самые строки, что и вы.

Чтобы избежать любой возможности возникновения конфликта, блокируйте файл, извлекая его для редактирования. Это не даст другим пользователям извлекать этот же файл для редактирования и возвращать его. Обязательно известите своих коллег о причинах блокировки и примерном времени, которое потребуется вам для редактирования. Также сообщите им, что сняли блокировку и вернули файл с изменениями.

Можно назначить тип блокировки в процессе извлечения файла для редактирования или заблокировать файл явным образом.

Чтобы заблокировать файл в процессе извлечения, выполните следующие действия:

1. В окне обозревателя Source Control щелкните файл правой кнопкой и выберите команду Check Out for Edit.
2. Укажите тип блокировки - None, Check Out или Check In.
3. Чтобы заблокировать файл явно, щелкните его правой кнопкой мыши и выберите команду Lock. Затем укажите тип блокировки - Check Out или Check In.

В отличие Microsoft Visual Source Safe® (VSS) , при извлечении файла в TFS вам не предлагается по умолчанию последняя версия. Прежде чем заблокировать файл, поместите в рабочую область его последнюю версию, выполнив команду Get Latest Version.

Дополнительные ресурсы

• Подробнее о блокировках читайте в статье "How to: Lock and Unlock Folders or Files" по адресу http://msdn2.microsoft.com/en-us/library/ms 181420(VS.80).aspx.
• Дополнительную информацию о типах блокировок вы найдете по адресу http://msdn2.microsoft.com/en-us/library/ms181419(VS.80).aspx.

Предупредите коллег о блокировке файла

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

Блокировка файла на время редактирования нужна только в случае, если вы опасаетесь возникновения конфликтов, которые могут вынудить вас выполнять сложное ручное слияние. По возможности разрешайте совместную работу, во время извлечения файла устанавливая тип блокировки None.

Чтобы заблокировать файл в окне обозревателя Source Control, щелкните файл правой кнопкой мыши и выберите команду Lock. Затем укажите тип блокировки - Check Out или Check In.

Дополнительные ресурсы

• Дополнительную информацию о типах блокировок вы найдете по адресу http://msdn2.microsoft.com/en-us/library/ms181419(VS.80).aspx.

Зависимости

• Старайтесь использовать ссылки на проект.
• Без необходимости не используйте файловые ссылки.
• В ссылках на веб-службы используйте динамические URL.

Старайтесь использовать ссылки на проект

По возможности используйте ссылки на проект, потому что они обладают следующими преимуществами:

• Работают на всех рабочих станциях, где загружено решение и набор проектов. Это происходит из-за того, что глобально уникальный идентификатор ( GUID ) проекта расположен в файле проекта, что однозначно идентифицирует проект, на который имеется ссылка, в контексте текущего решения.
• Позволяют системе сборки Visual Studio отслеживать зависимости проекта и устанавливать порядок выполнения сборок проекта.
• Позволяют избежать возможной потери ссылок на файлы сборок на конкретном компьютере.
• Автоматически отслеживают изменения конфигурации проекта. В частности, при сборке в конфигурации Debug любые ссылки проекта указывают на сборки Debug, сгенерированные проектами, на которые ссылается сборка. При сборке в конфигурации Release эти же ссылки указывают на сборки Release. Это означает, что вы можете автоматически переходить от отладочных сборок к сборкам выпуска без перенастройки ссылок.
• Позволяют Visual Studio обнаруживать и предотвращать циклические зависимости.

Вы можете использовать ссылки на проект, если файл сборки находится в наборе проектов решения. Если файл сборки находится за пределами набора проектов решения, а вам нужна ссылка на проект, вы можете выполнить ветвление из исходного проекта в ваш проект. Когда потребуется обновить версию зависимости, произведите слияние из исходного проекта в вашу ветвь.

Дополнительные ресурсы

• Дополнительную информацию о ссылках на проект и файловых ссылках вы найдете в статье "Project References" по адресу http://msdn2.microsoft. com/en-us/library/ez524kew(VS.80).aspx.
• Подробнее о добавлении ссылок читайте в статье "How to: Add or Remove References in Visual Studio" по адресу http://msdn2.microsoft.com/en-us/li-brary/wkze6zky(VS.80).aspx.

Без необходимости не используйте файловые ссылки

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

Дополнительные ресурсы

• Дополнительную информацию о ссылках на проект и файловых ссылках вы найдете в статье "Project References" по адресу http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx.

Для ссылок на проект и файл используйте параметр copy local = true

С каждой ссылкой сопоставлен атрибут copy local. В Visual Studio значение этого атрибута ( TRUE или FALSE ) задается при первом добавлении ссылки. Значение FALSE присваивается, если сборка находится в глобальном кеше сборок ( GAC ). В противном случае, присваивается значение TRUE. Значение, заданное по умолчанию, изменять не следует.

Если атрибут copy local имеет значение true, система сборки Visual Studio копирует любую сборку, на которую имеется ссылка, а также все зависимые нисходящие сборки, в клиентскую выходную папку. Например, если клиентский проект ссылается на сборку Lib1, а Lib1 зависит от Lib2 и Lib3, то во время сборки Visual Studio автоматически копирует Lib1, Lib2 и Lib3 в локальную выходную папку вашего проекта.

Дополнительные ресурсы

• Дополнительную информацию о ссылках на проект и файловых ссылках вы найдете в статье "Project References" по адресу http://msdn2.microsoft. om/en-us/library/ez524kew(VS.80).aspx.

В ссылках на веб-службы используйте динамические URL

Чтобы вызвать веб-службу, следует добавить в проект веб-ссылку Так генерируется прокси-класс, посредством которого вы взаимодействуйте с веб-службой. Код прокси изначально содержит URL веб-службы, например, http://localhost или http://SomeWebServer.

Важно! Для веб-служб, выполняющихся на вашем компьютере, всегда используйте адрес http://localhost а не http://ИмяМоегоКомпьютера, чтобы сохранить работоспособность ссылки на любом компьютере.

Статический URL, внедренный в прокси, как правило, не совпадает с URL, который будет использоваться в испытательной и рабочей среде. Обычно URL меняется, по мере того как ваше приложение проходит путь от разработки к тестированию и производству. Есть три способа решения этого вопроса:

• Программно задавать URL веб-службы во время создания экземпляра прокси-класса.
• Присвоить свойству URL Behavior ссылки на веб-службу значение Dynamic. Это предпочтительный вариант. При этом в прокси-класс добавляется код, извлекающий URL веб-службы из пользовательского раздела файла конфигурации приложения - Web.config для веб-приложения или SomeApp.exe.config для приложений Windows.
• Сгенерировать прокси с помощью инструмента командной строки WSDL.exe, задав параметр /urlkey. При этом происходит примерно то же самое, что и при установке свойства URL Behavior, но в этом случае URL хранится в разделе <applicationSettings> файла конфигурации приложения. Использование динамического URL позволяет создавать пользовательский файл конфигурации, который способен перекрывать параметры основного файла конфигурации приложения. Это позволяет разработчикам и членам группы тестирования временно перенаправить ссылку веб-службы в другое положение.

Дополнительные ресурсы

• Дополнительную информацию об управлении зависимостями вы найдете в лекции 6 этой книги.