Соглашения об именовании объектов отслеживания рабочих элементов
В Visual Studio Team Foundation Server все объекты отслеживания рабочих элементов связаны с одним или несколькими именами. У большинства из них имеются понятные отображаемые имена, и все они, кроме типов рабочих элементов и глобальных списков, связаны с именами ссылок. Понятное имя — это уникальный, видимый для пользователя идентификатор поля. Использование понятных имен обеспечивает согласованность между всеми командными проектами и типами рабочих элементов в коллекции проектов. TFS использует имя ссылки внутренним образом, и оно не может быть изменено после определения.
В следующей таблице приведена сводка по требованиям к именованию, которым должен соответствовать каждый из объектов отслеживания рабочих элементов.
Объект отслеживания рабочих элементов |
Ссылочное имя |
Понятное имя |
|---|---|---|
Тип рабочего элемента |
Неприменимо |
Имя каждого типа рабочих элементов может содержать до 255 символов Юникода и должно быть уникальным в пределах командного проекта. |
Поле рабочего элемента |
Обязательный. См. раздел Требования к именам ссылок. |
Имена полей могут содержать до 128 символов Юникода и должны быть уникальными в пределах коллекции командных проектов. |
Тип ссылки |
Обязательный. См. раздел Требования к именам ссылок. |
Для каждого типа связи нужно определить два понятных имени: имя прямой связи и имя обратной связи. Эти имена могут содержать до 128 символов Юникода и должны быть уникальными для всех типов связей, определенных в коллекции командных проектов. |
Категория |
Обязательный. См. раздел Требования к именам ссылок. |
Понятные имена категорий могут содержать до 128 символов Юникода и должны быть уникальными в пределах командного проекта. |
Глобальный список |
Неприменимо |
Имя каждого глобального списка может содержать до 254 символов Юникода и должно быть уникальным в пределах коллекции командных проектов. |
Требования к понятным именам
В дополнение к требованиям, перечисленным в вышеприведенной таблице из данного раздела, определяемые понятные имена должны соответствовать следующим требованиям.
Имена не могут быть пустыми.
Имена не могут начинаться или заканчиваться пробелом.
Имена не должны содержать символы обратной косой черты (\).
Имена полей не должны содержать следующие символы: обратная косая черта (\), точка (.), а также открывающая и закрывающая квадратные скобки ([]).
Имена не могут содержать два или несколько последовательных пробелов.
Требования к именам ссылок
Имя ссылки необходимо определять всякий раз при добавлении или создании поля рабочего элемента, типа связи или категории. Все имена ссылок могут содержать до 70 символов Юникода.
Определить имя ссылки можно с использованием алфавитно-цифровых символов, символов подчеркивания и дефиса. Каждое имя ссылки должно содержать как минимум одну точку (.), но точка не может присутствовать в начале или в конце имени. Имя ссылки не может начинаться с цифры или символа подчеркивания, кроме того, в нем не может быть нескольких последовательных дефисов, например (--).
Имена ссылок полей и переносимость
В языке определения типов рабочих элементов существует понятие имени ссылки поля. Имена ссылок полей помогают портировать определения между коллекциями проектов Team Foundation, а также делают возможной стороннюю интеграцию для поиска определенных полей и обращения к ним. Эти имена являются глобально уникальными, подобно пространству имен в приложении .NET Framework.
Имена ссылок полей не подлежат переименованию. Если, например, изменить имя с «Title» на «Header», то имя ссылки этого поля останется тем же. Интеграции и внутренние представления полей должны использовать имя ссылки поля, а не зависеть от самого имени поля.
Пространство имен System используется только для определения всех основных системных полей, обязательных для системных функций Team Foundation. Team Foundation Server не даст вам создать собственное поле System.X, так как это может препятствовать работе Team Foundation Server.
Пространство имен Microsoft служит для определения поля отслеживания рабочих элементов. Эти поля определены в определении типа рабочего элемента шаблонов процессов TFS. TFS не мешает вам создать собственные поля Microsoft.X. Однако такой подход не приветствуется, так как это может помешать работе Team Foundation Server TFS или сделать невозможным обновление командного проекта после обновления TFS с помощью мастера настройки функций.
Заказчики и партнеры могут создавать собственные пространства имен полей для собственных типов рабочих элементов.
Описание системных полей и полей, определенных в шаблонах процессов TFS, см. в разделе Справочник по полям рабочих элементов для Visual Studio ALM.
Примеры имен ссылок полей
В следующих примерах показано несколько допустимых имен ссылок на поля в разных пространствах имен.
Примеры в пространстве имен System
System.Id
System.Title
System.CreatedBy
System.CreationDate
System.ChangedBy
System.ChangedDate
System.State
System.Reason
Примеры в пространстве имен Microsoft
Microsoft.Common.Status
Microsoft.Common.Priority
Microsoft.Scheduling.Duration
Microsoft.Scheduling.PercentComplete
Microsoft.Testing.TestCaseName
Примеры в других пространствах имен
Клиенты и партнеры могут также определять собственные пространства имен для поддержки своих типов рабочих элементов. Например, воображаемая компания Trey Research может определить следующие собственные типы рабочих элементов:
TreyResearch.Common.Severity
TreyResearch.Common.Phase
TreyResearch.RiskManagement.RiskType
TreyResearch.RiskManagement.Resolution
Вымышленная компания по разработке программного обеспечения A. Datum Corporation может определить следующие типы рабочих элементов:
A_Datum.Common.BusinessPriority
A_Datum.Bug.FoundInPhase
A_Datum.Bug.FixInPhase
См. также
Ссылки
Справочник по элементам FIELD (определение)
Основные понятия
Настройка объектов отслеживания работ для поддержки командных процессов