Serviço vs. Biblioteca
Equipes em um ambiente DevOps podem relutar em trabalhar além dos limites de suas equipes em bases de código comuns, devido à ambiguidade sobre quem será responsável por responder a interrupções de serviço. A solução é perceber que muitas vezes é possÃvel implantar o mesmo serviço em ambientes independentes com cadeias de escalonamento separadas no caso de interrupções de serviço, ou separar grande parte do código compartilhado em uma biblioteca única e colaborar nela.
Quando as equipes estão trabalhando em um ambiente DevOps, os desenvolvedores são responsáveis por um recurso do inÃcio ao fim: desde o cliente até a implantação, manutenção e suporte. Isso representa um desafio ao trabalhar além dos limites da equipe: as cadeias de escalonamento podem não ser as mesmas para erros que ocorrem em qualquer equipe. O acoplamento entre código-fonte e implantação deixa as equipes com a dúvida de quem é responsável pelo suporte de plantão em caso de erros. Como resultado, as equipes relutam em unir forças, mesmo que haja uma sobreposição significativa nos requisitos.
As equipes estão trabalhando em um ambiente de micro-serviços.
Elas estão organizadas em equipes de DevOps totalmente funcionais: Cada equipe é responsável por suas contribuições do inÃcio ao fim, incluindo manutenção, suporte de plantão e suporte ao cliente.
Uma equipe tem a tarefa de fornecer um serviço aos seus clientes downstream que é bastante semelhante a um serviço existente construÃdo por outra equipe.
Os caminhos de escalonamento organizacional podem ser diferentes para cada uma das equipes.
Os membros de cada equipe podem estar relutantes em fornecer suporte de plantão para erros que não afetam seus próprios clientes downstream.
Os nÃveis de gravidade para os mesmos tipos de erros podem ser diferentes entre as fronteiras das equipes devido a diferentes definições de SLA por equipe/relacionamento com o cliente.
As equipes podem ter diferentes restrições de segurança ou regulamentações que regem suas implantações.
Separar a responsabilidade pelo código-fonte da implantação: Ambas as equipes trabalham para identificar exatamente onde existem sobreposições e sinergias.
Apenas o código-fonte partilhado é mantido como parte do projeto InnerSource com responsabilidade partilhada. O código-fonte partilhado deve ser coerente, na medida em que inclui todo o código de teste (incluindo testes de integração, se disponÃveis) e o máximo possÃvel do pipeline de CI para facilitar a validação da contribuição.
Separe os pipelines de configuração e implantação da lógica comercial real. Estabelecer uma segunda implantação do serviço para a segunda equipe.
Tratar a base comum como uma biblioteca que é utilizada por ambas as equipes com código partilhado propriedade partilhada.
As configurações de implementação podem ser incluÃdas como projectos separados no seu portfólio InnerSource para permitir que as equipes discutam/colabore ou que uma nova equipe as copie.
As equipes estão dispostas a colaborar, se beneficiando ao compartilhar o trabalho de implementação da lógica de negócios.
Um serviço que originalmente foi construÃdo especificamente para funcionar em um ambiente é convertido em uma solução mais geral com base em um requisito de negócio especÃfico.
Ambas as equipes conhecem sua respectiva polÃtica de escalonamento e configuração de implantação, identificando potencialmente melhorias para sua própria configuração.
A probabilidade de que mudanças sejam necessárias e feitas no código-fonte compartilhado aumenta, levando a oportunidades mais frequentes de refinar, melhorar e otimizar a implementação.
Estimula a padronização operacional incremental no empacotamento de lançamento, telemetria, endpoints de saúde/preparação e assim por diante, à medida que as equipes percebem que podem manter isso de maneira mais eficiente no código compartilhado se concordarem com convenções padrão.
Relacionado a este padrão está o Garantia de 30 dias, que adota uma abordagem diferente para lidar com as forças descritas acima.
Europace AG
Flutter Entertainment: Flutter InnerSource application possui um repositório de código compartilhado "service" com contribuições entre equipes e uma pipeline de CI para construir e publicar um artefato de release compartilhado. Cada equipe adotante possui um repositório de "configuração de implantação" que define sua própria implantação. Isso é conduzido por diferentes requisitos regulatórios, práticas de gerenciamento de serviço e incidentes e conjuntos de habilidades de infraestrutura em diferentes áreas do negócio.
Structured
Isabel Drost-Fromm
Rob Tuley
Obrigado, Tobias Gesellchen, pela revisão interna na Europace AG.
Serviço vs. Biblioteca: É Inner Source, Não implantação interna
2023-08-20 - Tradução Eneri Junior
2023-08-20 - Tradução Humberto Zilio