Projeto Ledger Live Monorepo: Parte 1 – Problemática (Make it Pain) | Razão

Nesta série de postagens no blog, Valentin De Almeida, desenvolvedor do Ledger Live, nos fala sobre a evolução da base de código do Ledger Live ao longo dos anos. Nesta postagem do blog, você aprenderá que inicialmente ele era baseado em vários repositórios, os problemas que encontramos ao longo do caminho e por que ele precisou evoluir para uma arquitetura de mono-repositório. Nas próximas postagens do blog, explicaremos como foi conduzido esse grande projeto de migração. 

Um pouco de história 

O crescimento da Ledger em 2020 e 2021 foi significativo. Recrutamos agressivamente novos talentos, expandindo nossa equipe de apenas alguns para mais de 20 desenvolvedores. Isso significa que muitos novos engenheiros foram integrados em projetos existentes. À medida que nossa equipe crescia rapidamente, encontramos novos desafios que precisávamos enfrentar rapidamente. Apesar dessas novas dificuldades, continuamos focados em nosso objetivo e continuamos a entregar um trabalho excepcional.

Demos um passo para trás e analisamos as novas problemáticas que surgem quando mais e mais pessoas participam do projeto. Entre esses novos desafios, podemos elencar as seguintes necessidades:

• Fluxos mais simples.
• Melhores diretrizes para colaboradores entrantes e externos.
• Um conjunto unificado de ferramentas.
• Melhor gerenciamento de dependências.
• Contribuições centralizadas de código aberto.

Estado da Arte: antes da migração

Inicialmente, e até ao ano passado, o Ledger Live baseava-se numa arquitetura de poli-repositórios, tanto para front-ends móveis como desktop, bem como em toda a lógica por detrás dela. Não foi uma decisão consciente trabalhar desta forma, mas foi apenas o resultado de um projeto em expansão sem nenhuma liderança arquitetônica real. Ledger Live é um projeto que reúne vários componentes em um para entregar o melhor e mais seguro aplicativo aos nossos usuários Nano, e isso se refletiu na base de código.

Os fluxos que tínhamos em vigor eram, na melhor das hipóteses, instáveis, principalmente devido ao fato de termos 6 ou 7 desenvolvedores há alguns anos. Como havia menos partes envolvidas, a comunicação ficou muito mais fácil e saímos impunes. Ainda assim, houve alguns pontos problemáticos na forma como trabalhávamos, especialmente em relação à experiência do desenvolvedor e ao processo de lançamento.

Gargalos na experiência do desenvolvedor

Dependências

Devido à natureza dos nossos projetos, trabalhamos em vários repositórios ao mesmo tempo, com dependências entre eles. Aqui está uma visão geral rápida:

As bibliotecas de código aberto Ledger são usadas pela lógica de negócios, que é então usada pelos aplicativos desktop e móveis. Mas esses aplicativos também usam bibliotecas de código aberto e usam duas versões diferentes da mesma biblioteca (como @ledgerhq/errors por exemplo) quebraria o aplicativo.

Precisávamos colocar a versão de um lado, depois publicar as bibliotecas (sim, para npm!!!) e tentar novamente se não funcionasse. Começamos a confiar yalc para vincular projetos simbolicamente, o que era aceitável desde que não tivéssemos várias camadas de dependências (por exemplo, das bibliotecas de código aberto à lógica de negócios e, em seguida, da lógica de negócios aos aplicativos). Tentamos provisoriamente trabalhar com yarn link também, mas parece que estava condenado com o React Native.

ensaio

Era quase impossível fazer testes de integração com todos os códigos mais recentes dos diferentes projetos. Como precisávamos publicar as bibliotecas no registro, testar todos os componentes com o código mais recente e atualizado foi um pesadelo

Também tivemos que manter vários CI com lógica duplicada.

Mudança de contexto

Sempre movimentar vários editores/projetos/diretórios de código fazia com que a experiência de desenvolvimento parecesse muito fraca.

Gargalos do processo de liberação

Versão

Lidar com o versionamento de diferentes projetos é difícil, especialmente quando há diversas camadas de dependências.

Liberando

O acompanhamento de lançamentos era complicado porque os projetos eram divididos e tínhamos que gerenciar os lançamentos dos diferentes projetos

Foi impossível automatizar o processo de lançamento, novamente devido ao fato dos projetos serem divididos em repositórios diferentes.

E, claro, a Entrega Contínua era impensável neste momento.

Solução possível ?

Procurando inspiração, parece que uma arquitetura de repositório mono é a peça central que faltava. Isso permitiria um processo de desenvolvimento muito melhor. Existem ferramentas construídas em torno desta arquitetura que nos ajudariam a alcançar as partes que faltam (liberação, automação, versionamento…).

Mas, o que é um repositório mono?

Em sua essência, um repositório mono é um projeto que encapsula todos os outros projetos relacionados (aplicativos, bibliotecas, ferramentas) em uma pasta/projeto git. Permite melhor gerenciamento de dependências, uniformização de ferramentas (como estilos de código e configurações typescript), integração contínua centralizada, testes de integração, versão uniforme de pacotes usados ​​(react por exemplo)…

Por ser um sistema bastante agnóstico, algumas funcionalidades foram deixadas para descobrirmos e implementarmos. Esperançosamente, existem algumas ótimas ferramentas da comunidade que poderiam nos ajudar a adicionar orquestração às compilações (compilações sequenciais, úteis para CI), controle de versão, geração de changelog... o que completaria o que estava faltando em nosso processo de lançamento.

Desvantagens

Repositórios mono fazem sentido em um contexto onde vários desenvolvedores, ou uma equipe de desenvolvedores trabalham em vários projetos ao mesmo tempo, com dependências entre eles. No entanto, acrescenta alguma camada de complexidade durante a fase de configuração (especialmente com projetos já em funcionamento e com 4 anos de história e desenvolvimento ativo). Vale ressaltar que o projeto fica muito maior (bem maior) em termos de espaço em disco. Todos os projetos estão agora na mesma pasta e em todas as dependências. Quais testes são obrigatórios? Quando ativá-los?

Prós

Depois de avaliar o tempo, o custo e a viabilidade das nossas ambições, aqui estão alguns dos benefícios esperados desta transição:

• Gerenciamento aprimorado de dependências: com um monorepo, é mais fácil gerenciar dependências entre diferentes projetos, pois todos são armazenados no mesmo repositório. Isso pode reduzir a necessidade de soluções alternativas, como fio de ligação ou yalce torna mais fácil garantir que todos os projetos estejam usando as versões corretas de dependências.
• Melhor organização do código: Um monorepo pode facilitar a organização do código, pois todos os projetos e suas dependências são armazenados em um único repositório. É mais fácil entender como diferentes projetos se encaixam e como dependem uns dos outros.
• Experiência aprimorada do desenvolvedor: um monorepo pode facilitar o trabalho dos desenvolvedores em vários projetos, já que eles não precisam alternar entre diferentes bases de código ou repositórios. Também pode facilitar a execução de testes de integração, pois todo o código é armazenado no mesmo repositório.
• Automação aprimorada e entrega contínua: com um monorepo, é mais fácil automatizar tarefas como construção, teste e liberação de código. Isso pode ajudar a agilizar o processo de liberação e facilitar a implementação da entrega contínua.
• Maior velocidade de desenvolvimento. Como diferentes equipes trabalham no mesmo repositório, não precisam esperar até o lançamento para verificar o resultado, acelerando a integração.

Conclusão

No geral, a implementação de uma estrutura monorepo pode ajudar a melhorar o processo de desenvolvimento, agilizar o processo de lançamento e aprimorar a experiência do desenvolvedor.

Nas próximas postagens desta série, mostraremos como esse grande projeto de migração foi conduzido, as ferramentas que usamos, as escolhas que fizemos, o resultado e muito mais. Fique ligado na Parte 2: As ferramentas!

---

Valentín DE ALMEIDA
Experiência do desenvolvedor e tecnologia central – Ledger Live

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain