Exploramos o ecossistema de modelos de repositório em nossa série anterior de artigos. Alinhamos sua definição, mitos e práticas em outros atores, mas ainda não é suficiente para selecionar um modelo de repo.
Podemos querer avançar demasiado rapidamente para as soluções, sendo perigoso sem que haja clareza sobre o problema a ser resolvido. Um problema que não é apenas técnico e começa no negócio.
Este artigo tem como objetivo de orientar sua decisão de modelo de repositório usando uma perspectiva e um processo holístico de Quality Engineering.
Comece com o porquê e, a seguir, para quem
Vale a pena investir tempo para esclarecer o “porquê” da sua iniciativa. Por que está considerando a questão do seu repositório de código? Por que isso seria necessário para sua empresa? O que não está fazendo enquanto trabalha na questão do repo?
O primeiro caso trivial é para uma start-up. As primeiras linhas de código precisam de armazenamento e, idealmente, de uma estrutura adequada desde o início. Ao começar do zero, um monorepo geralmente é o caminho a percorrer. Algumas exceções podem existir começando com uma equipa maior ou número de componentes de TI.
Avaliar o custo de oportunidade de uma mudança de repo para uma empresa existentente é mais desafiador. O valor capturado ocorre principalmente no médio prazo e, ao fazer as alterações, pode atrasar as entregas de features. Isso significa que sua iniciativa impactará seus stakeholders, daí a importância de considerá-los.
Mono ou multirepo: Comece com o “Por quê”, depois com “Para quem”.
Antoine Craske
“Para quem” é a segunda pergunta valiosa depois do “Por quê.” A identificação das partes interessadas é o primeiro passo para trabalhar a empatia. Precisa esclarecer “O que eu ganho com isso?” para cada um deles. Sua percepção de valor está na raiz de sua potencial aceitação. Pode estar a ameaçá-los se sua iniciativa for vista apenas como uma redução da velocidade do produto.
A citação “Qualidade é valor para alguém” assume todo o seu significado nesse contexto. O assunto do repo é arriscado quando abordado apenas no prismo da tecnologia; a percepção de valor de seus stakeholders é vital. Precisamos de uma abordagem mais holística para nossa empresa e seu ecossistema para avaliar o modelo de repositório.
Alinhar uma perspectiva holística de Quality Engineering
Temos que combinar várias perspectivas para obter uma visão mais ampla. A ordem em que analisamos nosso ecossistema está estruturando nosso raciocínio. Podemos aplicar o modelo de Quality Engineering iterando na arquitetura empresarial (incluindo a do negócio), produto, sistema organizacional e engenharia.
Temos que lidar com nossos repos enquanto a empresa existir. As organizações estão vivendo em ciclos de nascimento, crescimento, maturidade e declínio. Esses ciclos se aplicam ao setor em que sua empresa atua e à própria empresa. Um ciclo típico de uma empresa dura de 3 a 5 anos. Sua empresa pode estar em qualquer fase e até na transição de uma para outra. O estágio em que nos encontramos dá pistas de como a empresa vai se comportar e quais produtos e serviços vai oferecer.
Chegamos ao gerenciamento de produtos orientado por valor, traduzindo as prioridades de negócios em produtos valiosos. Por que devemos nos preocupar com o gerenciamento de produtos para nossos repos? Os produtos se traduzem em requisitos de software que nossas organizações terão de atender e, mais precisamente, iterar. O nosso modelo de repositório deve permitir iterações mais rápidas de criação de valor, sejam quais forem os produtos que tivermos que construir. A organização é a chave.
O nosso modelo de repositório deve permitir iterações mais rápidas de criação de valor.
Antoine Craske
O nosso sistema organizacional apoiará os objetivos de nossa empresa usando suas capabilities. Temos que entender o nosso estado atual, futuro e possíveis transições em vários elementos. Estrutura organizacional, interações e cultura são elementos cruciais para esclarecer. Algumas perguntas típicas surgem em torno do número de equipas, seus objetivos esperados e resultados. O modelo precisa estar alinhado com sua organização; não há uma única resposta correta. A Google é, por exemplo, uma organização centralizada em rede, enquanto a Netflix optou por um modelo mais descentralizado. Lembre-se de que o organigrama não é tudo, as interações são estruturantes.
Podemos passar para a engenharia assim que soubermos o que fazer, para quem e por quem. O nosso sistema de engenharia deve esclarecer seu estilo de arquitectura, organização da base de código, escolhas tecnológicas, etc. Sua decisão pode ser específica para cada contexto, por exemplo, ter um ecossistema diferente entre front e back-office. Pode até descobrir que o modelo de repos não é o tópico principal a ser tratado, permitindo que trabalhe na prioridade certa.
Deve ter uma imagem muito clara do estado atual, sendo a base para traçar possíveis alvos e transições. Provavelmente precisará de iterações entre arquitetura, produto, organização e engenharia. Temos decisões a tomar, qualquer que seja o nosso modelo de repo.
Decida e esclareça o que interage com o repo
O seu repo não é tudo, mesmo que seja estruturante. Pode consultar este artigo para obter mais detalhes sobre os mitos do repo. Os elementos inter-relacionados precisam de esclarecimento para melhorar nossa decisão de modelo de repositório.
O seu repo é estruturante, mas não é tudo.
Antoine Craske
As opções são obrigatórias. Como veremos mais tarde, qualquer opção está sujeita a compensações; Não há solução perfeita. O nosso “Por quê” guiará nossas decisões, evitando uma tabela de comparação interminável de prós e contras. Temos que focar nos principais diferenciadores que articulam nosso sistema.
Os elementos significativos de nossos repositórios estão em nossos fluxos de comunicação, gerenciamento de dependências e estilo de arquitectura. Temos de balancear as interações entre centralização e descentralização. Seu cursor precisa de ajuste dependendo do seu sistema organizacional. Dependências existem em qualquer caso; temos de escolher como gerenciá-los. Da mesma forma, podemos contar com um modelo centralizado (por exemplo, bibliotecas compartilhadas) ou descentralizado (por exemplo, duplicação de código que precisa de gerir).
O nosso estilo de arquitetura é o último elemento a ser integrado. Ele precisa estar alinhado com a nossa perspectiva de Quality Engineering, bem como com suas interações e dependências. Eu sugiro ser bastante claro sobre os anti-patterns e os pitfalls do estilo de arquitetura antes de decidir aqui. Podemos acabar com uma arquitetura diferente.
O valor do processo é nos concentrar no “right product” antes de tentar ter o “product right”. A partir desta etapa, estamos prontos para ponderar as possíveis opções para o nosso modelo de repositório.
Seja claro sobre os trade-offs de cada opção de repo
Os trade-offs também se aplicam às decisões de engenharia e, portanto, aos nossos repos. O nosso objetivo não é realizar a matriz de comparação mais exaustiva, mas sim selecionar a opção mais adequada para o nosso contexto, tendo consciência dos prós e contras, e mantendo flexibilidade para a evolução.
Normalmente precisamos de três bons motivos para decidir um modelo de repo em detrimento de outro. Do meu ponto de vista, os principais pontos de inflexão vêm da etapa anterior: qual empresa queremos (arquitetura), para entregar o que (produto), organizado duma forma (sistema organizacional), iterando sobre incrementos de software (engenharia).
Três bons motivos influenciam o modelo de repo.
Antoine Craske
Bons motivos para um monorepo são comunicação centralizada, governança, gerenciamento de dependências, integração o mais cedo, e uma stack mais homogênea. O que ganhamos com o monorepo tem um custo. Temos que gerir ferramentas centrais complexas para o build e o deployment.
Podemos tentar acomodar alguns trade-offs implementando um modelo de split-repo, mas estamos novamente lidando com o trade-off. Com uma base de código crescente, uma visão central suporta o refactoring a escala, se investirmos no armazenamento, pesquisa, controle de versão, revisões e mecanismos de refactoring necessários. Caso contrário, podemos estar procurando um modelo em multirepo.
Multirepos fazem sentido para uma organização que tende a descentralização da comunicação, integração e deployments. As equipas procurando iterações mais rápidas beneficiarão de repositórios separados. Uma pizza team terá mais autonomia no processo de construção, deploy e de release. Mas os trade-offs também estão presentes, especialmente no médio prazo.
Equipas isoladas tendem a otimizar seu contexto; isso é natural em sistemas. O problema é quando afeta nossos objetivos iniciais da empresa. Imagine um multirepos crescendo até 100 repositórios, cada um com sua própria stack tecnológica, mecanismos de registro, formato de APIs, linguagem, etc. Isso pode acontecer com um monorepo, mas muito mais provavelmente com um monorepo. O equilíbrio é vital para obter valor deste modelo. Temos que acelerar a velocidade da equipe garantindo a replicabilidade do processo e contenção de dívidas técnicas.
A nossa escolha de repositório é fundamental, pois iremos conectar outros aplicativos a este sistema. Flexibilidade, evolutividade e facilidade de manutenção são, portanto, requisitos estruturantes. Se não encontrar evidências claras para uma opção, é mais fácil começar com um monorepo e dividi-lo mais tarde, em vez tentar reagrupar repos construídos independentemente.
A nossa decisão sobre o modelo de repo ainda tem pouco valor até que seja compreendida por nossos stakeholders.
Compartilhe, alinhe opções e obtenha comprometimento
O envolvimento com nossos stakeholders é a chave para alcançar nossa iniciativa de repo. Temos que trabalhar multifuncionalmente e transversalmente dentro da organização para obter um patrocínio, orçamento e apoio à implementação. Desde o início, podemos capitalizar com as nossas respostas ao “Para quem”.
Temos recursos limitados para interagir com as partes envolvidas. Podemos construir um plano usando uma matriz de stakeholders para equilibrar nosso esforço. Dessa forma, esclarecemos o nível de investimento necessário desde o monitoramento mínimo até o estabelecimento de um relacionamento próximo.
Para nossa iniciativa de repositório, impactamos toda a cadeia de valor da engenharia, então como priorizar os atores? Nem todos os indivíduos e equipes são iguais. O poder não vem apenas de um cargo; conhecer a sua organização é vital para identificar os verdadeiros influenciadores, além dos cargos de VP, Sênior e C-level envolvidos. Para as equipas, a melhor candidata é aquela para qual sua proposta resolverá um verdadeiro desafio que está enfrentando agora.
A combinação desses indivíduos e equipas é a base de sua guiding coalition. Esta unidade é necessária para conduzir sua iniciativa até a conclusão, apoiando suas capacidades organizacionais. A implementação não acontecerá da noite para o dia. Isso levará tempo, iterações e perseverança.
Iterar horizontalmente, depois verticalmente
Sua iniciativa de mudança de repositório iniciará um novo ciclo em sua organização. Mesmo que vejamos esse ciclo como uma curva única, a implementação subjacente consiste em iterações. Cada etapa incremental deve validar ou invalidar as suposições de criação de valor e escala.
Qualquer que seja o modelo repo, temos que testar rapidamente nossas suposições do que chamo de “perspectiva horizontal”, com foco em uma integração de ponta a ponta. A nossa equipa candidata deve ser usada nessa etapa, focalizando a hipótese de valor ao invés de uma medição de atividade interna. Depois de validar o valor, podemos ver como expandir nosso modelo.
O nosso repo é como uma startup, deve encontrar seus primeiros utilizadores e depois crescer.
Antoine Craske
A nossa perspectiva horizontal deve mudar para uma vertical, olhando para o repositório geral. Um forte motivador para a evolução de um repo geralmente é o suporte ao crescimento da base de código. O escalonamento é, portanto, essencial, assim como a automação adequada. Um processo manual mal projetado é ineficiente e ainda mais quando automatizado. É aqui que precisa alavancar sua coalizão administrativa para expandir seu modelo.
O resto do gerenciamento de projeto tradicional está fora do escopo deste artigo. Lembre-se de que está dentro de um ciclo que evolui e, em algum momento, pode mudar.
Seu repo é um ativo de negócios, de hoje e de amanhã
O nosso repositório contém um ativo vital da organização, sua base de código, no centro da criação dos seus produtos digitais. O seu alinhamento com os objetivos de negócios, arquitetura, produtos, organização e sistema de engenharia é fundamental. Pelo menos durante os ciclos em que está.
Em um determinado momento, podemos estar sujeitos a avaliar o nosso modelo novamente. Podemos decidir segui-lo, melhorá-lo ou alterá-lo novamente. Numa perspectiva de repositório de código, isso significa que pode evoluir entre monorepo, multirepo e suas possíveis variações. Não podemos alterá-lo todos os anos devido aos seus impactos, daí o valor deste processo para um alinhamento de médio prazo.
Uma aprendizagem é que nosso repositório é estruturante, mas não é tudo. Seja claro sobre os trade-offs para evitar a frustração ao usar sua guiding coalition para liderar a iniciativa até a conclusão.
Uma iniciativa que só vai trazer valor, se for por alguém.
Referências
The Lean Startup, Eric Ries. https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898