Explorar a promoção do inner source

O fluxo de trabalho de pull requests baseado em fork é popular entre projetos de código aberto porque permite que qualquer pessoa contribua para um projeto. Você não precisa ser um colaborador existente ou ter permissão de escrita em 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.

Fluxo de trabalho de equipe tradicional

Antes dos forks, você podia contribuir para um projeto usando pull requests. O fluxo de trabalho é simples:

1. Envie um novo branch por push para o seu repositório.
2. Abra uma solicitação de pull para obter uma revisão de código de sua equipe.
3. Faça com que o Azure Repos verifique suas políticas de branch.
4. Clique em um botão para mesclar sua solicitação de pull na 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ê quiser adicionar um recurso a um projeto que você usa, mas outra equipe desenvolve?

É aqui que entram os forks; eles estão no centro das práticas de inner source.

O que é a origem interna?

Inner source – às vezes chamado de "open source interno" – traz todos os benefícios do desenvolvimento de software open source dentro do firewall da sua empresa.

"Inner source abre seus processos de desenvolvimento de software para que seus desenvolvedores possam facilmente colaborar em projetos em toda a sua empresa." Ele usa os mesmos processos que são populares em todas as comunidades de software livre, mas mantém seu código seguro e protegido dentro de sua organização.

Benefícios da fonte interna

• Colaboração entre equipes: As equipes podem trabalhar juntas em projetos, mesmo que normalmente não colaborem.
• Compartilhamento de conhecimento: os desenvolvedores podem aprender com o código escrito por outras equipes e aplicar essas lições ao seu próprio trabalho.
• Reutilização de código: em vez de criar a mesma funcionalidade várias vezes, as equipes podem se basear no trabalho existente.
• Melhoria de Qualidade: mais pessoas que revisam e contribuem para o código normalmente levam a um software de melhor qualidade.
• Inovação mais rápida: as equipes podem se mover mais rápido construindo com base em soluções existentes, em vez de começar do zero.

O percurso de origem interna da Microsoft

A Microsoft usa muito a abordagem de inner source. Como parte dos esforços para criar um sistema de engenharia em toda a empresa , apoiado pelo Azure Repos, a Microsoft abriu o código-fonte de todos os projetos para todos dentro da empresa.

Antes do inner source

Antes de migrar para a fonte interna, a Microsoft funcionava de maneira isolada.

• Somente engenheiros que trabalham no Windows podem ler o código-fonte do Windows.
• Somente os desenvolvedores que trabalhavam no Office podiam ver o código-fonte do Office.
• Se você era um engenheiro trabalhando no Visual Studio e encontrou um bug no Windows ou no Office – ou queria adicionar um novo recurso – você estava sem sorte.

Após o inner source

Ao migrar toda empresa para o inner source, com o suporte do Azure Repos, fica fácil fazer fork de um repositório para contribuir de volta. Como um indivíduo que está fazendo a alteração, você não precisa de acesso para gravação no repositório original, apenas a capacidade de lê-lo e criar um fork.

Essa abordagem habilitou:

• Melhor colaboração entre as equipes.
• Correções de erro mais rápidas e desenvolvimento de funcionalidades.
• Melhoria na qualidade do código por meio de uma revisão mais ampla.
• Redução da duplicação de esforço entre projetos.