Gestione dei pacchetti NPM privati e CI / CD

Al lavoro abbiamo un'applicazione che viene eseguita direttamente su macchine dev, ma distribuita a sciami Docker (uno sciame QA e uno sciame di produzione). Il codice e le pipeline CI / CD sono tutti in GitLab CE.

Utilizza diversi pacchetti NPM interni e privati. Ci riferiamo a questi pacchetti nel package.json in questo modo:

"@project/utils": "[email protected]:project/utils.git#branch"

Questo ci dà alcuni problemi:

1. Quando si sviluppa localmente su un ramo di funzionalità, è necessario modificare manualmente il file package.json ma non inserirlo, per aggiungere il ramo di funzione all'URL di dipendenza.
2. Poiché si tratta di un URL git, Yarn / NPM non controllerà e otterrà l'ultimo codice (anche se la versione di package.json è incrementato) . Devi eliminare la dipendenza da node_modules ed eliminare (o modificare) il file yarn.lock / package-lock.json (anche se credo che yarn upgrade fa ora aggiorni i pacchetti git). Abbiamo degli script per farlo ma, ew.
3. Abbiamo script nelle nostre pipeline CI / CD che devono "sistemare" i rami nel package.json per le dipendenze interne, questo aumenta considerevolmente il tempo di costruzione e lo rende piuttosto fragile. Fondamentalmente:
   1. yarn install --frozen-lockfile
   2. ./fixInternalPrivatePackages.sh package.json $BRANCH #where $branch can be #qa, feature-blah, etc.
   3. yarn install #to now get any changed dependencies, sometimes modifies other unrelated deps in the lockfile
   4. yarn run build

E poi viene trasferito su un registro Docker.

Con questa configurazione il lockfile a volte viene modificato causando il fallimento delle build. È anche un problema gestire su macchine di sviluppo. Gli sviluppatori a volte effettuano il check-in del loro package.json con il% di#branch sbagliato e questo fa fallire le build di altri popoli.

Possibili soluzioni:

1. Automatizza il tagging delle dipendenze interne, quindi regola il pacchetto.json con questi tag (potrebbe davvero essere solo l'hash del commit).
2. Repository di pacchetti privati. Questo risolve il problema con l'ottenimento dell'ultima versione se l'ultima viene sempre inviata. Credo che questo dovrebbe risolvere anche la situazione degli script di fixInternalPrivatePackages hacky.
3. Git / NPM pre / post hook / script per correggere il package.json di un progetto (rimuovere tutti i rami, ecc.)

Ma tutte queste soluzioni sembrano solo più cerotti su un problema fondamentale. Lo stiamo facendo nel modo giusto? Ci sono progetti di esempio con dipendenze interne come questa da cui potrei trarre ispirazione?

Mi sembra che una questione fondamentale sia che le dipendenze interne hanno bisogno del proprio ciclo QA e Gt; Prod in modo indipendente, in modo che siano già bloccate su una versione specifica prima che il resto dell'app venga spostato da QA- > prod.

Un altro è che mentre filato e npm ora hanno lockfile (non parliamo del tempo prima dei lockfile), il nostro flusso di lavoro rompe questa funzionalità quando deve modificare il pacchetto. json per cambiare ramo e reinstallare le dipendenze senza --frozen-lockfile switch. Vogliamo build riproducibili e non posso garantire che li abbiamo.

Ci vuole molto tempo per portare uno sviluppatore al massimo sul nostro progetto a causa di tutti questi problemi di gestione della configurazione, il codice stesso è molto più semplice della conoscenza DevOps necessaria per farlo funzionare.