Privilégios e Permissão de Usuários e Grupos - GitLab x GitHub
Página destinada ao seminário da matéria de Gerência de Configuração de Software em 2016/02 onde o objetivo é apresentar informações sobre os privilégios e permissões que cada usuário pode ter dentro de repositórios do GitLab e GitHub, como também os controles de Grupos ou Times existentes nesses mesmos gestores de versões.
Introdução
[editar | editar código-fonte]A grande expansão dos projetos na área da tecnologia da informação trouxe dificuldades em gerenciar e controlar o desenvolvimento dos diversos softwares, princilmente pelo fato da maioria ser desenvolvida colaborativamente. Os sistemas de versionamento online vieram para resolver problemas desse tipo, eles cresceram e além de trazer funcionalidades que dão controle amplo do projeto, passaram a disponibilizar também, grande interação entre desenvolvedores por meio da criação de grupos dentro do sistema, dentro desse grupos existem diferentes formas de cada usuário colaborar com o projeto e interagir com o respositório.
Logo a seguir serão mostradas e comparadas algumas permissões e privilégios que podem ser atreladas aos usuários dentro de um repositório ou nos times/grupos de colaboração no GitHub e no GitLab.
GitLab x GitHub
[editar | editar código-fonte]Neste tópico será feita uma comparação rápida entre as diferentes funcionalidades proporcionados pelos dois sistemas.
| GitLab | GitHub |
|---|---|
| Cria grupos | Cria organizações |
| Cria projetos privados de graça | Cria times |
| 5 niveis de permissões dentro de projetos | 2 niveis de permissões dentro de repositórios |
| 5 niveis de permissões dentro de grupos | 3 niveis de permissões dentro de organizações |
| 3 tipos de visibilidade na criação de projetos | 2 tipos de visibilidade na criação de repositórios |
| 3 tipos de visibilidade na criação de grupos | 2 tipos de visibilidade na criação de organizações |
| Utilização mais clara da SSH Key | Criação de times traz 4 níveis de permissões de repositórios |
| Pedir permissão diretamente para entrar em grupos | Inserir colaboradores nos repositórios sem alteração de privilégio para cada um |
Usuários no GitLab
[editar | editar código-fonte]Quando um usuário é adicionado a um repositório de um projeto no GitLab, é possível selecionar tipos diferentes de privilégios que o mesmo poderá ter.
Repositórios comuns
[editar | editar código-fonte]São 5 tipos de privilégios existentes:
- Convidado (Guest);
- Relator (Reporter);
- Desenvolvedor (Developer);
- Líder (Master);
- Proprietário (Owner) do repositório.
| Ações | Guest | Reporter | Developer | Master | Owner |
|---|---|---|---|---|---|
| Criar novos notificações de problemas (Issues) | sim
|
sim
|
sim
|
sim
|
sim
|
| Deixar comentários | sim
|
sim
|
sim
|
sim
|
sim
|
| Visualizar a lista de Builds | sim¹
|
sim
|
sim
|
sim
|
sim
|
| Ver os Logs dos Builds | sim¹
|
sim
|
sim
|
sim
|
sim
|
| Procurar e Baixar artefatos de Builds | sim¹
|
sim
|
sim
|
sim
|
sim
|
| Baixar códigos do projeto (Pull) | sim
|
sim
|
sim
|
sim
| |
| Realizar download do projeto | sim
|
sim
|
sim
|
sim
| |
| Criar fragmentos de código (Snippets) | sim
|
sim
|
sim
|
sim
| |
| Gerenciar notificações de problemas (Issues) | sim
|
sim
|
sim
|
sim
| |
| Gerenciar labels | sim
|
sim
|
sim
|
sim
| |
| Visualizar estado de commit | sim
|
sim
|
sim
|
sim
| |
| See a container registry | sim
|
sim
|
sim
|
sim
| |
| See environments | sim
|
sim
|
sim
|
sim
| |
| Gerenciar e aceitar requisições de merge | sim
|
sim
|
sim
| ||
| Criar novas requisições de merge | sim
|
sim
|
sim
| ||
| Criar novas branches | sim
|
sim
|
sim
| ||
| Enviar modificações para branches não protegidas (Push e Force-Push) | sim
|
sim
|
sim
| ||
| Remover branches não protegidas | sim
|
sim
|
sim
| ||
| Adicionar mensagens de monitoramento em commits (Tags) | sim
|
sim
|
sim
| ||
| Escrever na página da WIKI | sim
|
sim
|
sim
| ||
| Cancelar e tentar novamente builds de código | sim
|
sim
|
sim
| ||
| Criar ou atualizar estados de commits | sim
|
sim
|
sim
| ||
| Update a container registry | sim
|
sim
|
sim
| ||
| Remove a contrainer registry image | sim
|
sim
|
sim
| ||
| Create new environmets | sim
|
sim
|
sim
| ||
| Criar novos conjuntos de tarefas (milestones) | sim
|
sim
| |||
| Adicionar novos membros no time | sim
|
sim
| |||
| Enviar modificações para branches protegidas (Push) | sim
|
sim
| |||
| Habilitar ou desabilitar proteção em branches | sim
|
sim
| |||
| Habilitar ou desabilitar envio de modificações de desenvolvedores à branches protegidas | sim
|
sim
| |||
| Editar ou remover notificações de commits (Tags) | sim
|
sim
| |||
| Editar informações do projeto | sim
|
sim
| |||
| Adicionar chaves de deploy no projeto | sim
|
sim
| |||
| Configure project hooks | sim
|
sim
| |||
| Manage runners | sim
|
sim
| |||
| Manage build triggers | sim
|
sim
| |||
| Manage variables | sim
|
sim
| |||
| Gerenciar páginas do projeto | sim
|
sim
| |||
| Gerenciar domínios das páginas e certificados | sim
|
sim
| |||
| Delete environmets | sim
|
sim
| |||
| Alterar visibilidade do projeto | sim
| ||||
| Transferir projeto para outro namespace | sim
| ||||
| Excluir projeto | sim
| ||||
| Excluir página do projeto | sim
| ||||
| Remover branches protegidas | |||||
| Enviar modificações forçadamente para branches protegidas (Force-Push) |
¹ - Só é possível realizar essas ações caso dentro das configurações de CI (Integração contínua) estejam habilitadas.
Repositório com Integração Contínua (GitLab CI)
[editar | editar código-fonte]Além das informações apresentadas na tabela acima, os repositórios que contem integração contínua habilitados podem atribuir outros tipos de funcionalidades a cada tipo de usuário.
São 4 tipos de privilégios:
- Convidado/Relator (Guest/Reporter);
- Desenvolvedor (Developer);
- Líder (Master);
- Administrador (Admin).
| Ações | Guest/Reporter | Developer | Master | Admin |
|---|---|---|---|---|
| Visualizar commits e builds | sim
|
sim
|
sim
|
sim
|
| Tentar novamente ou cancelar builds | sim
|
sim
|
sim
| |
| Excluir o projeto | sim
|
sim
| ||
| Criar novo projeto | sim
|
sim
| ||
| Mudar configurações do projeto | sim
|
sim
| ||
| Add specific runners | sim
|
sim
| ||
| Add shared runners | sim
| |||
| See events in the system | sim
| |||
| Acesso à interface do administrador | sim
|
Usuários no GitHub
[editar | editar código-fonte]O GitHub funciona diferente do GitLab nos controles de usuários dentro de repositórios.
Existem apenas 2 tipos de usuários:
- Proprietário (Owner) do repositório;
- Colaboradores (Collaborator).
| Ações | Collaborator | Owner |
|---|---|---|
| Baixar modificações do repositório (Pull) | sim
|
sim
|
| Enviar modificações para o repositório (Push) | sim
|
sim
|
| Aplicar labels e milestones | sim
|
sim
|
| Controlar notificações de problemas (Issues) | sim
|
sim
|
| Gerenciar commentarios em commits, pull requests e issues | sim
|
sim
|
| Aceitar ou recusar merge de requisições de modificações (Pull request) | sim
|
sim
|
| Enviar requisições de modificações para repositórios originados de fork (Pull Request) | sim
|
sim
|
| Criar e editar páginas de WIKI | sim
|
sim
|
| Criar e editar Releases | sim
|
sim
|
| Desligar-se de um repositório colaborativo | sim
|
sim
|
| Excluir repositório | sim
| |
| Alterar visibilidade do projeto | sim
| |
| Convidar colaboradores | sim
|
Grupos no GitLab
[editar | editar código-fonte]O GitLab possui uma funcionalidade parecida com a criação de organizações do GitHub, a criação de grupos. Abaixo estão as principais características:
- Pode-se realizar tranferência de projetos já existentes para dentro de um grupo;
- Os grupos no GitLab são feitos para juntar diversos projetos;
- Podem ser adicionado pessoas para dentro desses grupos;
- Os usuários podem ser colocados dentro dos grupos por um tempo determinado. Atingiu uma certa data, ele é retirado do grupo automaticamente;
- Capacidade ilimitada para armazenar projetos.
Existem diferentes tipos de visibilidade que podem ser ligadas ao grupo:
- Privado: O grupo e os projetos só podem ser vistos pelos próprios membros.
- Interno: O grupo e os projetos podem ser visto por qualquer usuário conectado.
- Publico: O grupo e os projetos públicos podem ser visto por qualquer usuário sem identificação.
Os níveis de permissões dentro do grupos são:
- Convidado (Guest);
- Relator (Reporter);
- Desenvolvedor (Developer);
- Líder (Master);
- Propriétario (Owner) do repositório.
| Ações | Guest | Reporter | Developer | Master | Owner |
|---|---|---|---|---|---|
| Pesquisar grupos públicos | sim
|
sim
|
sim
|
sim
|
sim
|
| Criar um projeto dentro do grupo | sim
|
sim
| |||
| Editar grupo | sim
| ||||
| Gerenciar os membros do grupo | sim
| ||||
| Excluir o grupo | sim
|
Organizações no GitHub
[editar | editar código-fonte]Organizações são interessantes para a junção de multiplos projetos e colaboradores ou times em um só espaço de colaboração. Algumas características são:
- Vários repositórios privados em contas pagas;
- Permissões baseada em times colaborativos;
- Ilimitado número de proprietários, administradores e colaboradores dentro dos times;
- Receitas de faturamento podem ser enviados a uma segunda conta de email;
- Proprietários de times podem ter acesso à membros da organização.
Os níveis de permissões dentro das organizações são:
- Proprietário (Owner) da organização;
- Gerente de faturamento (Billing Manager);
- Outros Membros (Members).
| Ações | Billing Manager | Members | Owner |
|---|---|---|---|
| Visualizar e editar informações de faturamento | sim
|
sim
| |
| Criar times | sim
|
sim
| |
| Visualizar os membros e os times da organização | sim
|
sim
| |
| Utilizar @mention para qualquer time visível | sim
|
sim
| |
| Pode ser um gerenciador de time | sim
|
sim
| |
| Convidar pessoas para se juntar à organização | sim
| ||
| Editar e cancelar convites de entrada na organização | sim
| ||
| Excluir membros da organização | sim
| ||
| Reintegrar antigos membros à organização | sim
| ||
| Adicionar e remover pessoas em todos os times | sim
| ||
| Promover membros à gerenciadores de times | sim
| ||
| Adicionar colaboradores a todos os repositórios | sim
| ||
| Acessar o log de auditoria da organização | sim
| ||
| Excluir todos times | sim
| ||
| Excluir a organização e seus repositórios | sim
| ||
| Transferir repositórios | sim
|
Times no GitHub
[editar | editar código-fonte]A criação de times no GitHub, é uma funcionalidade extra que trouxe beneficios importantíssimos para o controle de projetos, dividindo as organizações em times menores, é possível otimizar o trabalho e melhorar a organização dos membros.
Uma das funcionalidades mais marcantes dentro de um time é o "Team @metions", algumas características dele:
- Usado na interação entre usuários ou entre times em uma organização.
- Pode ser usado em qualquer comentário, issue ou pull request.
- Pode-se chamar diretamente a atenção de um usuário ou de um time.
- Exemplo de uso:
Ao comentar em uma issue, o usuário pode digitar em qualquer lugar da frase o termo @nome-da-organização/nome-do-time para interagir diretamente com aquele time referenciado.
Permissões
[editar | editar código-fonte]Quando um usuário cria um time dentro da organização, tem-se o direito de adicionar repositórios dentro desse mesmo time, fazendo isso, é ganhado novos niveis de permissões de repositório, que são:
- Permissão de leitura. (read permission)
- Permissão de escrita. (write permission)
- Permissão de administrador. (admin permission)
- Permissão de proprietário. (owner permission)
| Ações | Read Permission | Write Permission | Admin Permission | Owner Permission |
|---|---|---|---|---|
| Criar repositório | sim
|
sim
|
sim
|
sim
|
| Realizar pull apartir do repositório do time | sim
|
sim
|
sim
|
sim
|
| Copiar repositórios da equipe | sim
|
sim
|
sim
|
sim
|
| Enviar pull requests a partir dos forks de repositórios da equipe | sim
|
sim
|
sim
|
sim
|
| Abrir issues | sim
|
sim
|
sim
|
sim
|
| Fechar as próprias issues | sim
|
sim
|
sim
|
sim
|
| Have an issue assigned to them | sim
|
sim
|
sim
|
sim
|
| Vizualizar releases publicadas | sim
|
sim
|
sim
|
sim
|
| Editar e deletar seus próprios comentários em commits, pull requests e issues | sim
|
sim
|
sim
|
sim
|
| Editar wikis | sim
|
sim
|
sim
|
sim
|
| Realizar push para o repositório do time | sim
|
sim
|
sim
| |
| Fundir e fechar pull requests | sim
|
sim
|
sim
| |
| Fechar, reabrir e nomear issues | sim
|
sim
|
sim
| |
| Aplicar labels e milestones | sim
|
sim
|
sim
| |
| Criar e editar releases | sim
|
sim
|
sim
| |
| Visualizar projeto de releases | sim
|
sim
|
sim
| |
| Editar e deletar qualquer comentário em commits, pull requests e issues | sim
|
sim
|
sim
| |
| Criar statuses | sim
|
sim
|
sim
| |
| Deletar repositório | sim
|
sim
| ||
| Mudar as configurações do repositório | sim
|
sim
| ||
| Mudar a visibilidade do repositório | sim
|
sim
| ||
| Tranferir repositório para dentro e para fora da organização | sim
|
sim
| ||
| Adicionar repositório no time | sim
|
sim
| ||
| Adicionar colaborador externo para o repositório | sim
|
sim
| ||
| Remover colaborador externo do repositório | sim
|
sim
| ||
| Pull (read), push (write), e clonar todos os repositórios da organização | sim
| |||
| Promover um membro da organização para team maintainer | sim
| |||
| Converter um membro da organização para colaborador externo | sim
|
Há também outros dois tipos de nívis de permissões que aparece dentro dos times:
- Team Maintainers, pode:
- Mudar o nome do time, descrição, e visibilidade
- Adicionar membros da organização para o time
- Remover membros da organização do time
- Promover um membro do time para team maintainer
- Remove o acesso da equipe para repositórios
- Reintegra um ex-membro da organização
- Outside Collaborators
Um colaborador externo é uma pessoa que tem acesso a um ou mais repositórios da organização, mas não é explicitamente um membro, ele é como um consultor ou empregado temporário.
Tipos de visibilidade
[editar | editar código-fonte]Existem dois tipos de visibilade que o usuário pode escolher na hora de criar o time.
- Time visível
- Poder ser visto e @mencionado por todos os membros da organização.
- Time secreto
- Poder ser visto apenas pelos membros dos times e pelos proprietários.
- Usado para trabalhar com parceiros externos ou clientes.
Conclusão
[editar | editar código-fonte]Com base nesta página e nos links aqui contidos, qualquer usuário poderá ter uma base melhor de uma das funcionalidades dos sistemas de versionamento Git, ajudando a escolher entre o melhor para ser usado com base nas necessidades do projeto x demanda do sistema.
Referências
[editar | editar código-fonte]- Help GitLab - Acessado em 26/08/2016
- GitHub Help - Acessado em 26/08/2016
- What are the different access permissions? - Acessado em 26/08/2016
- What's the difference between user and organization accounts? - Acessado em 26/08/2016
- Permission levels for a user account repository - Acessado em 26/08/2016
- Permission levels for an organization - Acessado em 26/08/2016
- Repository permission levels for an organization - Acessado em 26/08/2016
- Permissions GitLab - Acessado em 26/08/2016
- GitLab Documentation - Acessado em 27/08/2016
- Documentação de grupos do GitLab - Acessado em 27/08/2016
- Manuntenção e Configuração de times - Acessado em 27/08/2016
- Documentação sobre times do GitHub - Acessado em 27/08/2016