Quero fazer uma reserva imediatamente: este artigo não fornece uma receita pronta para uso. É a minha história de viajar para o mundo do Typescript e do NodeJS, bem como os resultados das minhas experiências. No entanto, no final do artigo, haverá um link para o repositório GitLab, que você pode ver, e talvez pegue algo que você gosta. Talvez até na minha experiência, crie sua própria solução automatizada.
Por que isso é necessário?
Então, por que você precisa criar bibliotecas ou, em um caso específico, pacotes NPM?
- Reutilizando código entre projetos.
Tudo começou com o fato de eu notar o hábito de criar uma pasta / ferramentas em projetos. Além disso, também levo a maior parte desta pasta quando mudo para um novo projeto. E então me perguntei: por que não fazer um pacote NPM em vez de copiar e colar e apenas conectá-lo a qualquer projeto? - Ciclo de vida diferente. Em um dos aplicativos, havia um grande conjunto corporativo de componentes como uma dependência. Foi possível atualizá-lo apenas por inteiro, mesmo que apenas um componente fosse atualizado. Alterações em outros componentes podem quebrar algo e nem sempre tivemos tempo estimado suficiente para testá-lo novamente. Este modelo é muito inconveniente. Quando cada pacote atende ao seu objetivo ou a um pequeno conjunto de objetivos relacionados, eles já podem ser atualizados quando é realmente necessário. Além disso, as seguintes versões do pacote são lançadas apenas quando há algumas alterações, e não "para a empresa".
- Separe o código secundário da lógica de negócios principal. O DDD possui o princípio de destilação de domínio; envolve a identificação de trechos de código que não pertencem ao domínio principal e o isolamento deles. E como é melhor isolar do que levar esse código para um projeto separado.
A propósito, a destilação de domínio é muito semelhante ao princípio SRP apenas em um nível diferente. - Cobertura de código próprio. Em um dos projetos em que participei, a cobertura do código foi de cerca de 30%. E a biblioteca que tirei dela tem uma cobertura de cerca de 100%. O projeto, embora tenha perdido a porcentagem de cobertura, como estava na zona vermelha antes da remoção, permaneceu. E a biblioteca tem indicadores tão invejáveis até hoje, depois de quase um ano e quatro versões principais.
- Código aberto O código que não contém lógica de negócios é o primeiro candidato à separação do projeto, para que possa ser aberto.
Lançar novas bibliotecas “caras”
Existe um problema: para criar uma biblioteca, não basta obter um repositório git nele. Você também precisa configurar a tarefa para que o projeto possa ser montado, realizar verificação estática (fiapos) e testar. Além disso, além dos testes, é recomendável coletar a cobertura do código. Além disso, você terá que publicar o pacote manualmente a cada vez. E ainda precisa escrever leia-me. Isso é apenas com o leia-me que não posso ajudar.
Então, o que pode ser feito com todas essas tarefas chatas e desinteressantes?
Primeiro passo: Semente
Comecei criando um projeto inicial. É um tipo de kit inicial, tinha a mesma estrutura do meu primeiro projeto para levar o código para um pacote separado. Eu criei nele tarefas e scripts de gulp que criariam, testariam e coletariam a cobertura do pacote em uma ação. Agora, para criar outro projeto, eu precisava clonar a semente em uma nova pasta e alterar a origem para que ela apontasse para o repositório recém-criado no GitHub (então eu ainda usava o GitHub).
Essa maneira de criar projetos fornece outra vantagem. Agora, as alterações relacionadas à construção ou teste do projeto são feitas uma vez, no projeto inicial. E copiar e colar essas alterações não é mais necessário. Em vez disso, no projeto final, da próxima vez que tiver que trabalhar com ele, crio um segundo controle remoto chamado seed e retiro essas alterações a partir daí.
E funcionou para mim por um tempo. Até eu usei a semente em um projeto em que vários desenvolvedores participaram. Escrevi uma instrução em três etapas: pegue o último mestre, crie e publique. E, em algum momento, um dos desenvolvedores, por algum motivo, concluiu a primeira etapa e a terceira. Como isso é possível?
Segundo passo: publicação automática
Apesar de ter sido um erro único, ações manuais como a publicação são chatas. Por isso, pensei que era necessário automatizá-lo. Além disso, o CI era necessário para impedir que as confirmações vermelhas entrassem no mestre. No começo, tentei usar o Travis CI, mas encontrei a seguinte restrição. Ele considera a solicitação de recebimento no mestre equivalente a uma confirmação no mestre. E eu tive que fazer coisas diferentes.
Um de meus colegas me aconselhou a prestar atenção ao GitLab e seu IC, e tudo o que eu queria funcionava lá.
Criei o seguinte processo de trabalho com o projeto, usado quando você precisa corrigir um erro, adicionar novas funcionalidades ou criar uma nova versão:
- Eu crio uma ramificação do mestre. Eu escrevo código e testa nele.
- Eu crio uma solicitação de mesclagem.
- O IC do GitLab executa testes automaticamente em um nó: contêiner mais recente
- A solicitação passa na Revisão de Código.
- Depois que a solicitação é congelada, o GitLab executa o segundo conjunto de scripts. Este conjunto cria uma tag no commit com o número da versão. O número da versão é obtido do package.json, se for aumentado manualmente, se não, a versão publicada mais recente será obtida e incrementada automaticamente.
- O script cria o projeto e executa os testes novamente.
- Nas últimas etapas, a tag version é enviada ao repositório e o pacote é publicado no NPM.
Portanto, a versão indicada na tag sempre corresponde à versão do pacote publicado a partir desse commit. Para que essas operações funcionem, você precisa especificar variáveis de ambiente com chaves de acesso ao repositório e NPM no projeto GitLab.
Última etapa: automatize tudo
Nesse ponto, eu já automatizei bastante, mas ainda havia muitas ações manuais para criar um projeto. Obviamente, isso já estava em andamento, porque as ações foram realizadas uma vez por projeto, e não em cada versão. Mas ainda assim, a instrução consistia em 11 etapas. E eu mesmo me enganei algumas vezes ao tomar essas medidas. Decidi que, desde que comecei a automatizar, preciso levar isso ao fim.
Para que essa automação completa funcione, mas no computador eu preciso ter 3 arquivos na pasta .ssh. Eu pensei que essa pasta estivesse bastante protegida, pois a chave privada id_rsa já está armazenada lá. Este arquivo também será usado para permitir que o GitLab CI passe tags para o repositório.
O segundo arquivo que coloquei é o "gitlab", que contém a chave de acesso à API do GitLab. E o terceiro arquivo é "npm", a chave de acesso para publicar o pacote.
E então a mágica começa. Tudo o que você precisa para criar um novo pacote é executar um comando na pasta inicial: "gulp startNewLib -n [npmName] / [libName]". Feito, o pacote é criado, pronto para desenvolvimento e publicação automática.
Por exemplo, o pacote "vlr / validity" foi criado dessa maneira.
Este comando faz o seguinte:
- Cria um projeto no GitLab
- Clona a semente para uma pasta local ao lado da pasta na qual o comando está sendo executado.
- Altera a origem do projeto criado na etapa 1
- Empurre o ramo principal
- Cria variáveis de ambiente em um projeto a partir de arquivos em uma pasta .ssh
- Cria uma ramificação firstImplementation
- Altera o nome da biblioteca em package.json, confirma e empurra a ramificação
Tudo o que você precisa depois disso é colocar o código lá e criar uma solicitação de mesclagem.
Como resultado, do qual se pode orgulhar, desde o momento em que se decide colocar algum tipo de código em um projeto separado até a publicação da primeira versão, decorrem cerca de cinco minutos. Quatro deles ocupam dois pipelines do GitLabCI e um minuto para iniciar o comando acima, arraste e solte o código e clique nos botões na interface do GitLab para criar e reter a solicitação.
Existem algumas limitações: o nome do GitLab deve corresponder ao nome em npm. E, no entanto, esse comando, diferente do restante da funcionalidade no projeto inicial, funciona apenas no Windows.
Se você estiver interessado neste projeto inicial, pode
estudá-lo no seguinte link .