tl;dr: Se você é administrador de um pequeno time e restringir acessos não é algo importante para você, adicione os desenvolvedores conforme imagens abaixo, … para todos os outros cenários, continue lendo este post! 🙂

A administração de usuários no TFS, mas tudo aqui também vale para o VSTS, se não explicito o contrário; é a tarefa que o administrador pode perder muito tempo no dia-a-dia ou não! Planejando corretamente sua árvoreve de permissões você vai ter menos trabalho ou até mesmo poderá deixar tudo praticamente automático; já quando não se planeja… dor de cabeça! Saber dosar a granularidade de controle sobre os usuários e suas permissões é o que fará ter sucesso.

• Mas vamos por partes, quando falamos sobre administração de usuários do TFS existem 3 áreas que devem ser compreendidas para o correto acesso ou permissionamento de funcionalidades:
• Access level management
• Membership management
• Permission management

Administração do nível de acesso (Access level management)

Controla o acesso as features baseado na licença do usuário, são três níveis:

• Basic
• Advanced
• Stakeholder

Anteriormente eram Standard, Full e Limited. Em Janeiro de 2015, foi criado o acesso de Stakeholder dando permissões para papeis do tipo Gerente, PO, Scrum master, sem que fosse preciso comprar licença de Visual Studio ou mesmo uma CAL; permitindo que seja acessado os boards Agile, View Work Items e funcionalidades Standard. Onde é possível fazer a alteração está na figura abaixo, como também as permissões do nível Basic:

É importante cadastrar corretamente os usuários com os níveis de acesso corretamente para não configurar pirataria!

Administração de autenticação de usuários (Membership management)

Este é simples são as contas de usuários que podem ser usuários locais, bem incomum em uma empresa, até o mais comum usuários de um AD. Tanto usuários como grupos do Windows podem ser cadastrados, o que permite a estratégia de delegar a classificação de grupos para o Administrador do AD, por exemplo: na empresa Fabrikam Fiber existem dois Team Projects, cada um com uma equipe de desenvolvedores, então é criado no AD um FabrikamFiberTPDev01 e FabrikamFiberTPDev02, esses grupos são colocados como Contributors de seus respectivos TP’s, se um desenvolvedor sai da empresa o AD retira ele do grupo correspondente e ele automaticamente perde os acesso no TP! Empresas médias e grandes costumam ter scripts integrados com o módulo de RH, o que facilita bastante.

Já se tiver mudanças constantes na estrutura de desenvolvimento e que vão se refletir na árvore ou mesmo na organização do TFS, talvez seja melhor criar esses grupos que usei no exemplo acima no TFS , daí a administração de usuários passa a ser do admin do TFS.

Um ponto interessante é que o TFS é uma plataforma bem completa de desenvolvimento e ALM, ele contempla controle de código fonte, build, deploy, etc… tudo integrado! Quando uma empresa decide utilizar ferramentas de diversos fabricantes fica bem mais complexo administrar a segurança. No TFS/VSTS está tudo em um só local.

Lembrando que se você é admin, seja de TFS, banco de dados, rede, Windows, … o console e scripts estão aí para facilitar sua vida. Deixe a interface gráfica de lado um pouco e experimente. Conhecer console é bom e hoje em dia Powershell… é mandatório!

Administração de permissões (Permission management)

E aqui vem a área mais interessante, que irá te permitir controlar tarefas específicas, em diferentes níveis de acesso. Os estados disponíveis são: Allow, Deny, Inherited allow, Inherited deny e Not set.

• Allow e Deny, não precisam de maiores explicações, são Permitir e Negar, e são permissões explícitas.
• Inherited allow e Inherited deny, são Herdar permitir e Herdar negar, por exemplo, no TFVC você tem uma hierarquia de pastas, ao invés de controlar cada uma o padrão é que elas venham herdando a permissão, então é só colocar na mais alta a permissão que os resto irá herdar a configuração.
• Not set, aqui fica interessante, caso uma permissão esteja com esse estado irá acontecer o seguinte, implicitamente é uma negação para os usuários, ou seja funciona como Deny, mas se ele estiver em um grupo que esteja configurado Allow, será permitido. Com isso é possível fazer estratégias como o usuário participar de um grupo onde alguma permissão esteja Not Set, porém ele também pode estar em outro grupo com poderes maiores, e daí terá que estar explicitamente Allow.
• Muito importante, o TFS sempre irá pela permissão mais restritiva, ou seja, se o usuário participa de dois grupos, em um está Allow e no outro Deny, a permissão estará como Deny! Por isso é bom ficar atento para não travar o usuário em algum ponto, para isso é importante ter uma matriz de permissões bem definidas.
• Antes de mudar uma permissão tenha certeza de que a mudança é necessário e esteja atento ao impacto que isso pode causar. Você pode impedir desenvolvedores de trabalharem, impedindo-os de desenvolverem tirando a permissão de um repositório por exemplo ou de solicitar um build!

Uma ferramenta bastante útil para entender a hierarquia de uma herança é o Why

Ele abre uma detalhamento de onde aquela permissão está sendo herdada, no exemplo o grupo Contributors está herdando de Project Valid Users:

Resumo

Um resumo visual do que foi dito está na figura abaixo:

Perceba que em Permission Management temos quatro níveis, na base o Server-level até o Object-level, permitindo fazer compatibilidades como :

Vale lembrar que é preciso planejar bem e tomar cuidado para não cair em uma granularidade alta, para não deixar o controle muito maior que o necessário, tornando-o burocrático e inflexível.

Vimos todas as alterações na interface gráfica… e ferramente de console? Próximo post vamos falar dela! 😉