Se você é administrador do TFS ou do VSTS, já deve ter adicionado novos usuários no TFS, dado permissão, teve que controlar o que grupos podem acessar, etc…

É uma tarefa bem tediosa, dependendo da cultura da organização que está trabalhando. Se ela for mais liberal, o controle será menos rígido, mas, se ela for menos permissiva, ou até mesmo se tiver que seguir regras rígidas, por exemplo, de Governança para empresas listadas na bolsa de valores; daí o processo vai ser mais complexo…

É aí que entra o TSC! E como isso pode acontecer, é o que vou explicar abaixo!

Ah! Apesar do nome, vale para VSTS também. 😀

Gerenciamento de segurança

Até o atual momento , o TFS e o VSTS tem um sistema que pode atingir níveis granulares bem interessantes. É possível negar a permissão a uma branch ou a visualização de builds, por exemplo. O que é excelente para uma organização com uma política de Governança forte que procura atender a SOX, ou Novo Mercado, (BM&F BOVESPA).

Se pensarmos em termos de Separation of duties, podemos dividir várias tarefas, para não deixar na mão de somente uma pessoa, por exemplo: pode-se ter um papel de criador de definições de release, para a automação de deploy, e outro que só informará os grupos ou pessoas responsáveis por aprovações em cada ambiente do pipeline! Assim, garantimos que uma tarefa seja executada “a quatro mãos”, e ninguém fica com todas as chaves ou possibilidades de configuração.

Gerenciamento de segurança no TFS

Se você ainda não leu nada sobre o assunto, recomendo ler esses posts antes de continuar: Administração de usuários e grupos no TFS/VSTS e Administrando usuários, grupos e permissões no console com TFSSecurity, o primeiro post dará uma ideia básica de como funciona o sistema de permissionamento do TFS; o segundo mostra alguns exemplos de como fazer isso via console

Muitas vezes eu faço a criação de um grupo para o papel de Release Manager. As pessoas nesse grupo ficam responsáveis por cuidar do Build, agora do Release, e talvez até de outros assuntos; existe também a figura do Scrum Master, ou Gerente de Projetos, que fazem o controle das Iterações. Do Product Owner, que aprova deploys no ambiente de homologação, por exemplo, enquanto que o time de QA aprova no ambiente de teste e Operações em produção…

Vamos analisar o cenário: Release Manager, em um time ágil, é responsável pela criação da definição de build, de release, das iterações, por causa do lançamento de release após algumas iterações… Ah! Essa pessoa também faz Code Review , e esse processo acontece na integração do código da feature branch com a master, por exemplo; portanto os desenvolvedores não devem ter permissão para mandar código na master.

Vamos configurar tudo isso agora.

Build e Release Definition Administrator

Fácil, no Team Project, nas configurações de segurança (1), criamos o grupo Release Manager (2), selecionamos (3) e colocamos como membro (4) dos grupos Build Administrators e Release Administrators.

Iterations Administer

Aqui já começa a complicar, pois não será na mesma aba que será feita a configuração! A aba Security só é possível configurar algumas permissões. Portanto clique na aba Iterations (1), no backlog clique no menu de contexto (aquela preta na extrema esquerda) (2), clique Add e adicione o grupo Release Manager (3), selecione (4), configure as permissões para administrar as iterações.

Branch master Administrator

Primeiro vamos na aba Version Control (1), mais um lugar diferente, e vamos na branch master (2) do repositório, e no grupo Contributors (3) vamos negar as permissões (4) Contribute, ou seja o desenvolvedor não vai poder fazer push para esta branch, e vamos aproveitar e negar a permissão Rewrite and destroy history (force push), assim previne-se a possibilidade da branch ser apagada.

Agora que temos os desenvolvedores bloqueados vamos resolver os Release Managers. Na mesma aba (1), na branch master (2), adiciono o grupo Release Manaer (3), seleciono-o (4), e a permissão de Contribute já está OK, pois está sendo herdada, esse conceito foi explicado no post já indicado acima; ela irá permitir que o Release Manager integre o código de uma feature branch na branch master, via Pull Request! A outra permissão eu neguei como segurança, daí quando precisar fazer alguma re-escrita de histórico é só perdir a liberação no grupo e negar novamente.

Nada disso é difícil, certo? E o processo de configuração é feito uma única vez e não se mexe mais! Mas, se você tem muitos Team Projects ou se você tem muita movimentação estrutural na empresa, começa a ficar um processo chato de ficar alterando…

Mas, e se você fez uma vez e não mexeu mais, como ter certeza que não foi alterado ao longo do tempo? Ainda não temos um processo de auditoria no TFS. Isso significa que você não tem histórico dessas alterações. E é aí que entra o Team Foundation Server Security as a Code

TSC

Esse post é um kick-off do projeto. Você pode encontrá-lo aqui https://github.com/egomesbrandao/tsc, mas calma! Eu disse KICK-OFF, ou seja, ainda não tem código lá. Eu tive a ideia do TSC já tem algum tempo, mas não havia me dedicado a ele, a ideia de escrever sobre ele é me comprometer em desenvolvê-lo e também pedir ajuda da comunidade, seja para mandar PR, ou escrever Issue’s, ou só testar!

O que é TSC

A ideia do TSC é escrever a configuração de código do TFS como código, em uma estrutura Yaml, por exemplo:

 name: "FabrikamFiberCollection"
     url: "http://vsalm:8080/tfs/FabrikamFiberCollection"
     ProjectCollectionAdministrator:
     Members:
      Member:
          user: VSALM\janed
          Permissions:
              Administer build resource permissions: Allow
     Projects:
         Project:
             name: "FabrikamFiber"
                 Groups:
                     Group:
                        Name: "Release Administrators"
                        Members:
                            Member:
                                user: lambda3\andre

Depois de escrito toda a estrutura de configuração, é só “commitar”, e um processo de build vai gerar a estrutura necessária de configuração, para isso será desenvolvido uma task, para ser executada por um deploy em um ambiente, ou seja, na máquina do TFS, pois será utilizado o utilitário de configuração TFSSecurity.exe, por isso a sugestão de leitura do segundo post!

Com isso se ganha rapidez, confiabilidade e um histórico!

Quero comunicar o progresso semanalmente, então toda sexta-feira, durante algum tempo, irei postar sobre o que foi feito durante a semana neste projeto, ou explicando algo.

Espero que mais pessoas se engajem no projeto.

Mande seu PR!