Estratégias para usar organizações no GitHub Enterprise Cloud
No GitHub Enterprise Cloud (GHEC), as organizações são contas compartilhadas em que os usuários colaboram em vários projetos ao mesmo tempo, com recursos sofisticados de segurança e administrativos. É importante planejar sua estrutura com antecedência para evitar a criação de silos desnecessários e aumentar a sobrecarga administrativa. Uma boa estrutura facilitará a colaboração e a descoberta, ao mesmo tempo que reduz as despesas administrativas.
Saberemos porque a Philips decidiu usar uma única organização (com uma pequena exceção) para sua arquitetura do GitHub Enterprise, e porque a Fidelity escolheu uma arquitetura comum, porém um pouco mais complexa.
Neste guia, você aprenderá:
Por que o GitHub recomenda o uso do menor número possível de organizações para atender às suas necessidades comerciais
Considerações comuns de empresas para usar várias organizações
Por que a indexação excessiva de organizações do GitHub para a estrutura corporativa pode ser problemática
Como escolher a estrutura organizacional que seja melhor para a sua empresa, incluindo exemplos de alguns dos modelos possíveis
Qual é o número recomendado de organizações?
Alguns clientes do GHEC usam uma única organização para colaborar em todo o seu conteúdo. Outros preferem criar várias organizações em sua conta corporativa porque elas exigem a separação total do conteúdo para cumprir requisitos comerciais como:
Distinções legais ou comerciais entre grupos de conteúdos, usuários etc.
Classificação de dados ou requisitos regulamentares
Fusões, aquisições, alienações e outras alterações comerciais
A capacidade de fornecer uma área de transição ou de teste para os usuários experimentarem novos recursos, concluírem exercícios de treinamento etc.
Em geral, recomendamos criar o mínimo possível de organizações na sua empresa para acomodar suas necessidades comerciais. Se possível, use somente uma. Cada organização exige sua própria administração e configuração. Outras organizações criam outras despesas. As organizações são criadas também para manter a separação entre si e, por padrão, elas criam pontos de isolamento e podem impedir a colaboração e uma cultura de innersource (na qual os princípios do código aberto são aplicados internamente). Não use organizações para criar separações onde você pode usar permissões de equipes e repositórios.
Organizações e estrutura corporativa
Recomendamos que você não faça a indexação excessiva em suas organizações do GitHub para a estrutura corporativa.
Ao configurar o GHEC, inicialmente você poderá achar que é melhor criar uma organização separada para cada projeto ou departamento para gerenciar as permissões e minimizar as notificações. Não recomendamos esse procedimento. Ele restringe a flexibilidade da sua estrutura organizacional e pode causar desafios mais complexos a longo prazo.
Um motivo para isso é que as estruturas corporativas podem mudar frequentemente, às vezes com interrupções significativas à situação vigente e pouca visibilidade. A configuração do GHEC deve administrar primorosamente as reorganizações corporativas, sem afetar as organizações do GitHub e criando trabalhos posteriores, como integrações de reaplicações de patches e atualizações de links externos. Além disso, a indexação da estrutura da sua organização para a estrutura corporativa aumenta as conversas com pontos isolados e aumenta o peso do gerenciamento.
Considere usar as equipes do GitHub em uma única organização para atribuir funções e permissões. As equipes e os usuários dentro da mesma organização podem facilmente encontrar o conteúdo uns dos outros, fazer perguntas e mencionar uns aos outros. Isso se torna mais complicado se eles estiverem dispersos em várias organizações. Se uma equipe precisar de acesso a mais de uma organização, ela deverá ser criada em cada organização e mapeada para o grupo de provedores de identidade apropriado. Os administradores se tornam rapidamente sobrecarregados com solicitações para adicionar e gerenciar usuários de várias organizações para visualizar o conteúdo ou fazer uma pergunta, cancelando assim as muitas vantagens de manter as organizações separadas desde o início.
Dessa forma, ter uma organização para cada projeto aumenta o peso do gerenciamento de integrações. Os GitHub Apps são instalados nas organizações para que as empresas com várias organizações possam instalar e gerenciar cada uma de suas integrações em cada uma delas. Há um limite de 100 instalações de GitHub App por organização.
Selecionando a melhor estrutura organizacional para a sua empresa
Abaixo detalharemos três modelos comuns adotados com sucesso pelos clientes do GitHub Enterprise Cloud que utilizaram de forma eficiente o mínimo de organizações possíveis para suas empresas.
Modelo 1: organização única
Neste modelo, uma única organização é usada para todos ou para a grande maioria dos repositórios. Várias organizações de pequeno e médio porte (com menos de 5.000 desenvolvedores) usam esse método para gerenciar seu ambiente do GitHub.
A maioria dos usuários desse modelo define as permissões básicas de suas organizações como nenhuma. Isso exige que todos os usuários sejam explicitamente adicionados a todos os repositórios possibilitando visualizá-los e/ou propor alterações. Esse método sozinho cria pontos de isolamento, limita significativamente a visibilidade e previne ativamente o innersource. Para neutralizar essa tendência, recomendamos que você use as equipes para garantir a visibilidade. Por exemplo, crie uma equipe "todos os membros" e adicione-a aos repositórios que estiverem abertos para colaboração. Você pode até mesmo adicionar esse tipo de equipe automaticamente a todos os repositórios por padrão, e depois estabelecer um processo de exceção para quando os repositórios precisarem ser mantidos com base na necessidade de informação.
Exceções
Existem algumas variações neste modelo para acomodar circunstâncias excepcionais. Por exemplo, você pode manter uma ou duas organizações "secretas" para projetos que devem ser mantidos completamente separados de todos os outros trabalhos, como projetos para clientes altamente confidenciais. Ainda assim, a grande maioria do trabalho é feita em uma única organização.
Da mesma forma, você pode usar uma organização separada para segmentar repositórios gerenciados por equipes em certos locais para resolver problemas relacionados às leis de propriedade intelectual.
Mudamos para o GitHub para podermos unificar nossas equipes em uma única plataforma e incentivar o innersource. Temos equipes distribuídas pelo mundo todo e antigamente cada uma usava seu próprio sistema, o que dificultava incrivelmente o trabalho em conjunto. Tínhamos que lidar com diferentes sistemas, políticas, equipes etc. Agora, temos todos os nossos desenvolvedores e nosso código interno em uma única organização do GitHub, onde configuramos nossos repositórios internos para acesso Read por padrão, o que facilita a descoberta e a reutilização de código.
Ao mesmo tempo, temos organizações adicionais no GitHub para colaboração de código aberto e para testes. Isso nos permite manter limites e permissões distintas, ao mesmo tempo em que aproveitamos a simplicidade e a visibilidade fornecidas por uma única organização para a maior parte do nosso desenvolvimento de software.
Modelo 2: red-green-sandbox-archive
O modelo red-green-sandbox-archive utiliza duas organizações principais e uma área restrita. Explicaremos abaixo como cada parte funciona.
Organização verde
A organização verde atua como o principal espaço de colaboração para os desenvolvedores, com quase 90% dos repositórios residindo aqui. Defina as permissões básicas como "gravar" para promover innersource e empoderar os usuários para propor alterações nos repositórios. Ao mesmo tempo, você usará proteções de branch (abordadas em um guia posterior neste módulo) em repositórios na organização verde para garantir que os usuários possam somente propor alterações e que essas alterações propostas sejam efetivadas por meio da revisão de código e do processo de aprovação definidos, para que sejam aprovadas.
Você então concederá permissões de nível mais alto para os repositórios por meio das equipes, o que pode ser visto na página do repositório de cada equipe. Com a maioria das atividades acontecendo na organização verde, o peso de gerenciar as equipes e as integrações é minimizado.
Organização vermelha
A organização vermelha é voltada para os repositórios que precisam ser mantidos conforme a necessidade de informação. Defina as permissões padrão da organização como nenhuma para exigir que as equipes sejam adicionadas explicitamente aos repositórios para lê-los ou para sugerir alterações.
Tenha um processo definido para criar repositórios e equipes para essa organização, a fim de prevenir restrições desnecessárias e autoimpostas.
Organização com área restrita
Uma organização com área restrita fornece um espaço compartilhado no qual qualquer usuário pode criar e experimentar com um repositório. Esse espaço é mais visível e incentiva a colaboração de forma mais eficiente do que com o uso de repositórios pessoais individuais. Essa organização é importante principalmente se você configura o GHEC para impedir que os desenvolvedores criem repositórios pessoais.
Caso você decida usar uma organização com área restrita, será necessário definir um processo para mover o trabalho da área restrita para as organizações verdes ou vermelhas, garantindo que os experimentos possam ser transferidos para um gerenciamento mais formal.
Organização arquivo (opcional)
A organização arquivo consiste em repositórios que já não são mais mantidos. Apesar de todos os repositórios poderem ser arquivados, tornando-os somente leitura para todos os usuários, esses repositórios arquivados podem ser mantidos em suas organizações existentes. Algumas empresas preferem transferir a propriedade desses repositórios arquivados para uma organização separada, deixando as outras organizações para o trabalho ativo. Observe que isso pode mudar a sintaxe do nome ou do proprietário dos repositórios, e poderá tornar a localização do repositório no GitHub mais difícil, se o usuário tiver a expectativa de estar na organização original.
No início, queríamos espelhar o modelo de produto da Fidelity usando organizações do GitHub, o que resultaria em um grande número de organizações. Rapidamente percebemos que teríamos dificuldades de uma perspectiva de gerenciamento de acesso e controle e desafios de dimensionamento em innersource, habilitação, integração e suporte.
Acabamos usando o red-green-sandbox-archive, que nos forneceu um modelo aberto e visível que promoveria o innersource, a reutilização e a descoberta, além de nos dar os controles de segurança e conformidade necessários para nosso código altamente confidencial e regulamentado.
Para permitir maior colaboração e inovação, e dar suporte a eventos no estilo hackathon, os desenvolvedores podem criar repositórios na organização com área restrita com políticas e restrições mínimas. Eles também podem criar fork de projetos na organização verde em seu próprio espaço de usuário pessoal para colaborar com outros e, então, enviar uma pull request para fazer o merge das alterações de volta ao projeto principal. Isso realmente cria um ecossistema de innersource sem atritos e facilita descobertas e contribuições.
Modelo 3: empresa portfólio
Existem alguns cenários nos quais o modelo red-green pode não ser adequado para as estruturas internas da sua empresa.
Por exemplo, empresas muito grandes, com dezenas de milhares de funcionários, divididas em unidades de negócios relativamente estáticas, como um banco global que consiste em banco de varejo, investimentos pessoais, mercado capital e seguradoras, poderá achar esse modelo insuficiente.
Esse campo inclui também algumas empresas portfólio com unidades operacionais que funcionam independentemente umas das outras, como uma empresa de mídia formada por redes de transmissão, estúdios de gravação, serviços de streaming e empresas de jogos interativos. Essas empresas poderão também sofrer fusões, aquisições e alienações.
Para uma empresa muito grande, recomendamos mapear a estrutura de organização do GHEC para a divisão corporativa de nível mais alto. Essas divisões geralmente estarão um nível abaixo do CEO e terão natureza estática porque as organizações normalmente ocorrem dentro dessas divisões, deixando a estrutura superior como estiver.
Em uma empresa portfólio, as organizações devem ser mapeadas para cada entidade de negócio. As organizações podem ser transferidas de uma empresa para outra, facilitando o peso de gerenciar uma fusão ou alienação.
Se possível, recomendamos manter uma única organização por empresa portfólio ou por uma divisão de negócios importante. Essas são basicamente várias implementações da estratégia de organização única descrita acima. Recomendamos implementar uma estrutura red-green mínima para cada divisão de negócios importante. Se você escolher esse caminho, considere implementar uma única área restrita em todas as unidades e mantenha repositórios de arquivo na organização principal. Isso ajudará a minimizar o número de organizações ativas a serem gerenciadas.
Observação sobre os projetos de código aberto para empresas portfólio: projetos de código aberto devem ser mantidos em uma organização dedicada, separada de organizações corporativas. Caso contrário, você poderá encontrar problemas de limite de segurança, principalmente quando usar colaboradores externos. Se você estiver usando um ambiente Enterprise Managed User (EMU), poderá ser necessário ter contas corporativas separadas devido às restrições.
Criando e gerenciando organizações na conta corporativa
Após determinar a estrutura apropriada para suas organizações, os empresários podem gerenciar as organizações de propriedade da conta corporativa usando algumas opções diferentes: criando uma nova organização, convidando ou transferindo uma organização existente (empresas que não usarem somente EMUS) e gerenciando a associação e propriedade das organizações.
Criar uma nova organização
A criação de uma nova organização na sua empresa fornecerá um novo contêiner separado para repositórios, projetos, documentações e colaborações. Os nomes das organizações devem ser exclusivos em todo o GitHub.com, independentemente da propriedade corporativa. O nome da conta corporativa não está incluído no URL ou no caminho da organização.
Os empresários que criarem uma organização de propriedade de uma conta corporativa se tornarão automaticamente proprietários da organização. Selecione outros proprietários da organização durante o processo de criação.
Convidando ou transferindo de uma organização existente
Observação: essa opção está disponível somente para empresas que não usam EMUs, porque as empresas com EMUs restringem a entrada e saída de conteúdo não corporativo sem o uso de ferramentas de migração.
Se uma organização já existir no GitHub.com e você quer levá-la para sua conta corporativa, transfira ou convide essa empresa para sua conta. Dependendo da propriedade da organização existente, será necessário a propriedade ou a aprovação do proprietário corporativo atual (caso faça parte de uma empresa) ou do proprietário da organização (caso seja uma organização independente). Você, como o proprietário da empresa recebedora, deverá também dar uma aprovação final para a transferência, depois que o proprietário atual aceitar.
Várias considerações importantes se aplicam ao transferir uma empresa externa para a sua empresa, o que pode ser destacado mais profundamente na documentação. O mais importante é lembrar que serão necessárias licenças de usuário suficientes na conta corporativa para acomodar os outros usuários singulares na organização que estiver entrando.
Essa opção é útil para cenários de fusões, aquisições, migrações e atualizações, nos quais parte da empresa estava anteriormente usando um plano GitHub não corporativo. Dependendo da sua estratégia a longo prazo, mantenha a organização transferida separada ou transfira mais repositórios para outras organizações.
Gerenciando afiliações e propriedade de organizações
Como o proprietário de uma empresa, adicione a si mesmo como o proprietário ou membro de uma organização para qualquer organização da sua empresa, contanto que essa organização não seja gerenciada pelo SAML e SCIM no nível da organização para a afiliação. Isso pode ser útil se o proprietário da organização deixar a empresa ou se tornar indisponível, ou caso você precise de acesso como uma dessas funções. Use também essa interface para remover-se dessas funções, caso não precise mais de acesso.
Para as organizações gerenciadas com SAML e SCIM, use o provedor de identidade para o provisionamento, a fim de evitar o desprovisionamento acidental por meio da automação.
Próximo: Defina as configurações e políticas corporativas do GitHub Enterprise Cloud
Agora que você já pode tomar uma decisão informada sobre quando e como usar mais de uma organização na conta corporativa, chegou a hora de analisar as principais definições que você precisa configurar nos níveis corporativo e da organização.
Recursos adicionais:
Melhores práticas para as organizações e equipes que usam o GitHub Enterprise Cloud
Gerenciando sua função em uma organização de propriedade da sua empresa