Como conseguir uma transição suave do modelo de organização “o grande repositório VCS para todos os produtos” para o modelo “muitos repositórios VCS pequenos”?

É um cenário comum que a base de código de um produto mantida por um repositório em algum sistema VCS evolua para um ponto em que essa base de código possa ser vista como contendo vários produtos. A divisão da base de código em vários repositórios VCS, cada um dedicado a um único produto, pode aproveitar vários benefícios (consulte Benefícios de ter um produto por repositório VCS sobre o modelo de repositório inchado abaixo). No lado técnico, dividir a base de código é uma etapa bastante fácil, pois a maioria dos VCS suporta esta operação. Entretanto, a divisão pode surgir problemas de engenharia relacionados a testes automatizados, entrega contínua, integração ou monitoramento de serviços (consulte Problemas levantados pela divisão.) As organizações que planejam realizar essa divisão, portanto, precisam saber como realizar essa transição da maneira mais tranquila possível, ou seja, sem interromper seu pipeline de entrega e monitoramento. O primeiro passo disso é provavelmente entender melhor a noção de projeto e como delinear a divisão em uma base de código monolítica.

Nas respostas a estas perguntas, eu gostaria de ver:

1. Uma tentativa de fornecer uma definição prática do que é um produto, que fornece critérios práticos para realmente delinear produtos em uma base de código existente.

2. De acordo com esta definição de trabalho, elabore um plano que efetue a divisão. Podemos assumir a simplificação de que a base de código é processada por um sdlc totalmente automatizado, implementando integração e entrega contínuas . Ou seja, cada ramificação é validada por um conjunto de testes automatizado implementado na base de código atual e cada mesclagem com alguma ramificação "mágica" gera artefatos do produto que são testados e implantados. ( Os artefatos do produto são, por exemplo , tarballs de origem, documentação, pacotes de software binários, imagens do Docker , AMIs, unikernels.)

3. Esse plano é satisfatório se explica como contornar a

Questões levantadas pela divisão

1. Como os procedimentos de teste automatizados se relacionam com o repositório monolítico preexistente e os repositórios divididos?

2. Como os procedimentos de implantação automatizada se relacionam com o repositório monolítico preexistente e os repositórios divididos?

3. Onde está armazenado o código para os procedimentos de implantação automatizados?

4. Onde estão as estratégias de infraestrutura armazenada , monitoramento e alta disponibilidade ?

5. Como garantir que um desenvolvedor precise apenas de uma base de código por vez (mas possível use artefatos de outras bases de código).

6. Como uma ferramenta como o git-bisect

Nota marginal: Benefícios de ter um produto por repositório VCS sobre o modelo de repositório inchado

Ter vários repositórios pequenos mantendo a base de código de um produto específico tem as seguintes vantagens sobre a abordagem do "repositório inchado":

1. Com um repositório inchado, é difícil reverter um release quando um produto é instável, porque o histórico é misturado com outro histórico do produto.

2. Com um repositório inchado, é difícil revisar o histórico do projeto ou puxa, com repositórios pequenos, é mais provável que leiamos essas informações. (Isso pode ser específico para VCS como o git, onde, diferentemente do svn, não podemos fazer checkout de subárvores!)

3. Com um repositório inchado, precisamos fazer muito mais ramificações quando desenvolvemos. Se tivermos N repositórios, podemos trabalhar em paralelo em N ramos, se tivermos apenas 1 repositório, apenas trabalharemos em um ramo ou teremos uma carga de cópias de trabalho que também são um aborrecimento.

4. Com vários repositórios pequenos, os logs fornecem um mapa de calor do projeto. Eles podem até ser usados ​​como proxy da difusão de conhecimento na equipe de desenvolvimento: se eu não cometer no repo X há três meses, seria bom me designar em uma equipe que trabalha no repo X para que eu fique ciente dos desenvolvimentos nesse componente.

5. Com pequenos repositórios, é mais fácil obter uma visão clara de um componente. Se tudo correr em um único grande repositório, não haverá artefato tangível que delineie cada componente, e a base de código pode facilmente se deslocar em direção à grande bola de lama .

6. Pequenos repositórios nos forçam a trabalhar em interfaces entre componentes. Mas como queremos ter uma boa capsulação, este é um trabalho que deveríamos fazer de qualquer maneira, então eu consideraria isso uma vantagem para pequenos repositórios.

7. Com vários repositórios pequenos, é mais fácil ter vários proprietários de produtos.

8. Com vários repositórios pequenos, é mais fácil ter padrões de código simples que são pertinentes a um repositório completo e que podem ser verificados automaticamente.

É uma pergunta fascinante para a qual respostas reais podem não existir; Entendo que, enquanto você tentava manter a pergunta contextualizada no VCS, ela naturalmente se expandia até o design da infraestrutura e o planejamento da implementação.

No entanto, parece que muitos de nós estamos trabalhando nesse tipo de transição, o que pode ser emocionante, mas ao mesmo tempo frustrante e doloroso; e gostaria de compartilhar minhas experiências e pontos de vista, tentando não ser pedante, e só porque posso não ser um bom engenheiro, também para não ser chato.

Projeto

Infraestrutura e arquitetura devem se unir para escrever um software moderno. Bem acoplado, se você quiser. Pode parecer estranho usar essas palavras, mas certamente não estamos falando sobre o próprio código aqui: quero dizer, elas devem fazer parte do mesmo modelo. Quando as nuvens chegaram e as pessoas começaram a escrever um software para elas, quantas pessoas perceberam que, colocando as bolas de lama lá, elas seriam as mesmas bolas de lama em um lugar diferente (?) Talvez algumas pessoas com visão de futuro possam prever isso, e eles provavelmente estão trabalhando em devops hoje. Como devops é apenas uma palavra da moda com tantos significados diferentes para pessoas diferentes, eu vi lugares em que a equipe de devops se sentava em todas as reuniões de arquitetura; outros lugares em que é apenas automação. Para alcançar esse tipo de transformação, temos que lutar para nos sentarmos lá.

Confiança

A transição deve ser mantida isolada, no sentido de que deve existir um corte consistente da história, que forneça a transição em si e somente ela mesma, sem nenhuma outra alteração (após vários meses de preparação). Com que confiança alguém o aprovaria e apertaria o botão vermelho?

Quero dizer que a base de código deve mudar para acomodar a nova estrutura do VCS, e será muito difícil mantê-la mesclada durante o desenvolvimento. (para esta questão, pode haver estratégias facilitadoras, falarei sobre uma comum mais tarde, que pode ajudar a paralelizar um pouco o desenvolvimento).

Bem, eu aposto que a única maneira é com testes comportamentais, e o mesmo conjunto de testes comportamentais deve ser lançado para verificar o antigo com a nova base de código. Não estamos verificando se o aplicativo se comporta conforme o esperado aqui, mas que a transição não altera o comportamento. Ter falhas nos testes pode ser uma coisa boa! Se eles continuarem falhando!

De fato, é muito incomum que as bolas de lama sejam bem testadas; normalmente, o código é muito bem acoplado e, provavelmente, para a maioria dos códigos herdados, ele não foi desenvolvido com uma abordagem orientada a testes, nem mesmo a testes de unidade.

Se esse código de teste estiver ausente, ele deverá ser escrito primeiro.

Estratégia

Sim, a transição deve ser mantida isolada; mas ao mesmo tempo integrado. Sei que posso parecer louco aqui, mas não encontrei outras palavras para descrever como a confiança pode acompanhar os negócios. Pouquíssimas empresas, se não nenhuma, gostariam de interromper o desenvolvimento de uma grande base de código monolítica, para abrir espaço para essa transição, e não estamos fazendo isso acontecer apenas com o lançamento de uma moeda. Talvez centenas de desenvolvedores possam estar contribuindo continuamente para a base de código (eu usaria a palavra adulteração aqui, do nosso POV). Embora nosso trabalho deva abordar um instantâneo específico para fornecer confiança, precisamos nos manter rebasados ​​(não no sentido git aqui), para evitar ficar para sempre.

A estratégia de implementação aqui pode oferecer experiências diferentes. Uma linha comum de desenvolvimento é agrupar / adaptar (expondo terminais com esquemas opcionalmente reorganizados) as ramificações de implementação mais recentes (bem, morando em outros repositórios nesse caso), quando elas precisam interagir com o núcleo. A transição com uma estratégia como essa, juntamente com a refatoração, pode ao mesmo tempo oferecer um cenário de POC para a transição do VCS e, posteriormente, uma abordagem passo a passo. Veja como esculpir a bola de lama. Sim, a vida oferece muitas coisas mais engraçadas.

Dívida Técnica

As esferas de gestão de negócios começaram a entender a dívida técnica e a mantê-la em consideração. Não, risque isso, não é verdade. Embora seja cada vez mais comum coletar medições e dados de qualidade, em termos de análise de código estático, revisão de código, resultados de testes comportamentais e desempenho, além de gerar bons relatórios e tudo mais ... ainda é incrivelmente difícil fazer a empresa aceitar um processo contínuo. abordagem de refatoração. O valor comercial disso. "Estamos seguindo um processo ágil, e isso não trará nenhum aprimoramento para os recursos, não é?" . Basicamente, ao fazer isso, eles estão negando a existência de dívida técnica. Eu vejo isso como a etapa necessária comum que falta para poder iniciar qualquer transição de arquiteturas de monólito para microsserviços.

Reaggregação

Depois de tudo isso, você ainda pode querer fornecer uma única visualização semelhante a um repositório na qual é possível criar mais de um único produto. Por qualquer motivo, por exemplo, curr / next release, multimarca, o cliente cria. Ferramentas como o Google Repo podem ajudar nesse caso. Eu nunca usei um, mas sei que precisarei de um dia.

Teste de integração

Com os microsserviços, o teste de integração assume um contexto diferente, de "teste da própria API". Camadas mais altas de teste, funcionais ou de desempenho, podem e vão existir, mas elas significam muito sem testes de integração adequados? Seria como ter testes de integração sem testes de unidade. Claro que não. É por isso que, se você precisar git bisect, você o executará em uma ramificação do repositório de microsserviços, esqueça de executá-la no repositório do mudball.

PS. isso é um rascunho, meu inglês é ruim e eu vou consertar um dia