Explorar a promoção do inner source
O fluxo de trabalho de solicitação de pull baseado em fork é popular em projetos de código aberto porque permite que qualquer pessoa contribua com o projeto.
Você não precisa ser um colaborador nem ter acesso de gravação a um projeto para oferecer suas alterações.
Esse fluxo de trabalho não é apenas para código aberto: os forks também ajudam a dar suporte a fluxos de trabalho de inner source em sua empresa.
Antes dos forks, você pode contribuir com um projeto usando solicitações de pull.
O fluxo de trabalho é bastante simples: efetue push de um novo branch para seu repositório, abra uma solicitação de pull para que a sua equipe faça a revisão de código e faça com que o Azure Repos avalie suas políticas de branch.
Você pode clicar em um botão para mesclar sua solicitação de pull no branch principal e implantar quando o código for aprovado.
Esse fluxo de trabalho é ótimo para trabalhar em projetos com sua equipe. Mas e se você observar um bug simples em um projeto diferente em sua empresa e quiser corrigi-lo por conta própria?
E se você for adicionar um recurso a um projeto que você usa, mas que outra equipe desenvolve?
É para essa situação que os forks servem; forks estão no centro das práticas de inner source.
Inner source
O inner source, às vezes chamado de "código aberto interno", traz todos os benefícios do desenvolvimento de software de código aberto pra dentro do seu firewall.
Ele abre seus processos de desenvolvimento de software para que os desenvolvedores possam colaborar com facilidade em projetos da sua empresa.
Ele usa os mesmos processos que são populares em todas as comunidades de software de código aberto.
Mas ele mantém o código seguro e protegido em sua organização.
A Microsoft usa muito a abordagem de inner source.
Como parte dos esforços para padronizar um sistema único de engenharia em toda a empresa – com suporte do Azure Repos – a Microsoft também abriu o código-fonte de todos os nossos projetos para todos na empresa.
Antes da mudança para o inner source, a Microsoft era "isolada": somente engenheiros que trabalhavam no Windows podiam ler o código-fonte do Windows.
Somente os desenvolvedores que trabalhavam no Office podiam ver o código-fonte do Office.
Portanto, se você é um engenheiro que trabalha no Visual Studio e acha que encontrou um bug no Windows ou no Office ou se quiser adicionar um novo recurso, é o seu dia de azar.
Porém, ao mudar para oferecer inner sources em toda a empresa, com apoio da plataforma do Azure Repos, ficou fácil criar fork em um repositório para contribuir.
Como um indivíduo que está fazendo a alteração, você não precisa de acesso de gravação no repositório original, apenas a capacidade de lê-lo e criar um fork.