Serviço vs. Biblioteca

Title

Serviço vs. Biblioteca

Patlet

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.

Problema

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.

Contexto

• 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.

Forças

• 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.

Solução

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.

Contexto Resultante

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.

Veja também

Relacionado a este padrão está o Garantia de 30 dias, que adota uma abordagem diferente para lidar com as forças descritas acima.

Instâncias Conhecidas

• 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.

Estado

• Structured

Autores

• Isabel Drost-Fromm

• Rob Tuley

Reconhecimento

Obrigado, Tobias Gesellchen, pela revisão interna na Europace AG.

Alias

Serviço vs. Biblioteca: É Inner Source, Não implantação interna

Histórico de Tradução

• 2023-08-20 - Tradução Eneri Junior

• 2023-08-20 - Tradução Humberto Zilio