Convenções de nomenclatura para objetos de rastreamento de Item de trabalho
Todos os objetos de rastreamento de item de trabalho estão associados um ou mais nomes. A maioria tem nomes para exibição amigável e todos, mas os tipos de item de trabalho e listas globais estão associadas a nomes de referência. Um nome amigável é um identificador exclusivo, visível ao usuário para um campo que você usa para garantir a consistência em todos os projetos de equipe e tipos de item de trabalho em uma coleção de projeto. O nome de referência é usado internamente pelo Team Foundation Server e não pode ser alterado depois que ela está definida.
A tabela a seguir resume os requisitos de nomeação que devem ser atendidos para cada objeto de rastreamento de item de trabalho.
Objeto de rastreamento de item de trabalho |
Nome de referência |
Nome amigável |
|---|---|---|
Tipo de item de trabalho |
Não aplicável. |
O nome de cada tipo de item de trabalho pode ter até 255 caracteres Unicode e deve ser exclusivo dentro de um projeto de equipe. |
Campo de item de trabalho |
Obrigatório. Consulte requisitos de nome de referência. |
Os nomes de campo podem ser de até 128 caracteres Unicode e devem ser exclusivos dentro de uma coleção de projeto de equipe. |
Tipo de link |
Obrigatório. Consulte requisitos de nome de referência. |
Você define dois nomes amigáveis para cada tipo de link: Nome direta e inversa. Esses nomes podem ser de até 128 caracteres Unicode e devem ser exclusivos para todos os tipos de link definidos para uma coleção de projeto de equipe. |
<strong>Categoria</strong> |
Obrigatório. Consulte requisitos de nome de referência. |
Nomes amigáveis de categoria podem ser de até 128 caracteres Unicode e devem ser exclusivos dentro de um projeto de equipe. |
Lista global |
Não aplicável. |
O nome de cada lista global pode ter até 254 caracteres do Unicode e deve ser exclusivo dentro de uma coleção de projeto de equipe. |
Conteúdo do Tópico
Requisitos de nome amigável
Requisitos de nome de referência
Nomes de referência de campo e os requisitos de portabilidade
Exemplos de nomes de referência de campo
Requisitos de nome amigável
Além de para os requisitos resumidos na tabela listada anteriormente neste tópico, os nomes amigáveis que você definir devem atender aos seguintes requisitos:
Nomes não devem estar vazios.
Nomes não podem ter os espaços em branco à direita ou à esquerda.
Nomes não podem conter caracteres de barra invertida (\).
Os nomes de campo não podem conter os seguintes caracteres: barra invertida (\), ponto (.) e abrindo e fechando os colchetes ([]).
Nomes não podem conter dois ou mais espaços em branco consecutivos.
Requisitos de nome de referência
Sempre que você adicionar ou cria um campo de item de trabalho, o tipo de link ou a categoria, você deve definir um nome de referência. Todos os nomes de referência podem ser de até 70 caracteres Unicode.
Você pode definir um nome de referência usando caracteres alfanuméricos, caracteres sublinhados e hífens. Cada nome de referência deve conter pelo menos um período (.), mas nenhum período pode aparecer no início ou final de um nome. Um nome de referência não pode começar com um número ou um sublinhado e não pode ter vários hifens consecutivos, tais como (-).
Portabilidade e nomes de referência de campo
A linguagem de definição de tipo de item de trabalho inclui o conceito de um nome de referência do campo. Nomes de referência de campo podem ajudá-lo a definições de porta entre Team Foundation coleções de projeto e também permitir integrações de terceiros localizar e consulte campos específicos. Esses nomes são globalmente exclusivos, assim como um namespace em de.Aplicativo do NET Framework é globalmente exclusivo.
Nomes de referência de campo não podem ser renomeados. Se, por exemplo, você alterou o nome do campo "Título" para o "Cabeçalho", o nome de referência de campo desse campo permanecerá o mesmo. Integrações e representações internas dos campos devem usar o nome de referência de campo em vez de acordo com o nome do campo.
O namespace System é usado somente para definir todos os principais campos de sistema que são obrigatórios para Team Foundation funções de sistema. Team Foundation Serverimpede que você crie seu próprio campo System.X porque ele pode impedir Team Foundation Server funcionalidade.
O namespace Microsoft é usado para definir os campos que são definidos em uma definição de tipo de item de trabalho de um modelo de processo de Microsoft Solutions Framework (MSF). Team Foundation Servernão impede que você criar seu próprio campo Microsoft.X. No entanto, essa prática não é recomendável porque ele pode impedir Team Foundation Server funcionalidade
Clientes e parceiros podem criar seus próprios espaços para nome do campo para tipos de item de trabalho personalizados.
Para obter descrições dos campos de sistema e os campos definidos pelo MSF for Agile Software Development - v 5.0, consulte Usando os campos de sistema e definidas pelos modelos de processo do MSF.
Exemplos de nomes de referência de campo
Os exemplos a seguir mostram os nomes de referência de campo válido, em vários espaços para nome.
Exemplos de Namespace do sistema
System.ID
System.title
System.CreatedBy
System.CreationDate
System.ChangedBy
System.ChangedDate
System.State
System. Reason
Exemplos de Namespace de Microsoft
Microsoft.Common.status
Microsoft.Common.Priority
Microsoft.Scheduling.Duration
Microsoft.Scheduling.PercentComplete
Microsoft.Testing.TestCaseName
Exemplos em outros espaços
Clientes e parceiros também podem definir seus próprios namespaces para dar suporte a seus tipos de item de trabalho personalizados. Por exemplo, a empresa fictícia, a Trey Research pode definir os seguintes tipos de item de trabalho personalizados:
TreyResearch.Common.Severity
TreyResearch.Common.Phase
TreyResearch.RiskManagement.RiskType
TreyResearch.RiskManagement.Resolution
A empresa fictícia de software a. Datum Corporation pode definir os seguintes tipos de item de trabalho:
A_Datum.Common.BusinessPriority
A_Datum.bug.FoundInPhase
A_Datum.bug.FixInPhase
Consulte também
Referência
Conceitos
Personalizando o controle de dados, formulários, fluxo de trabalho e outros objetos do projeto