Come gestire le librerie utilizzate da più progetti?

Question

Come gestire le librerie utilizzate da più progetti?

#1 da (5 voti)

8

La mia azienda ha diversi prodotti sul mercato, sviluppati in più uffici in Europa e negli Stati Uniti, che utilizzano la stessa libreria comune. Questa libreria comune racchiude molti dettagli specifici del settore, oltre ad alcuni controlli utente avanzati, metodi di estensione, bit matematici, ecc.

I problemi sorgono quando QA ritorna con un bug o il proprietario del prodotto per uno dei prodotti vuole una modifica, e quel bug o cambiamento richiede modifiche al codice nella libreria condivisa. Poiché si tratta di una modifica a una libreria utilizzata da tutti i nostri prodotti, il cambiamento può avere effetti di vasta portata. Il rapporto difetto / bug / richiesta di modifica viene in genere inserito nel backlog del prodotto per il prodotto "originale", ovvero il prodotto sottoposto a test dal QA o di proprietà dell'OP che richiede la modifica. Ciò significa che c'è pochissima visibilità negli altri prodotti per questi cambiamenti, e le cose potrebbero rompersi (molto ovviamente con errori in fase di compilazione o più sottilmente con un comportamento di run-time diverso) quando la libreria viene aggiornata in quegli altri prodotti. Il controllo qualità per gli altri prodotti potrebbe visualizzare le modifiche come errori di regressione.

La libreria è abbastanza matura a questo punto, quindi la maggior parte delle modifiche apportate sono il risultato di correzioni di bug. Le modifiche vengono inviate tramite una richiesta pull, in cui un rappresentante di ciascuno degli uffici regionali può esaminarlo (anche se solo 1 deve approvarlo); le modifiche note ad alto impatto vengono in genere comunicate tramite e-mail, ma possono essere dimenticate dal momento in cui lo sviluppo riprende su un determinato progetto.

Come posso gestire una biblioteca come questa, per garantire una buona visibilità tra il proprietario del prodotto QA e gli sviluppatori?

c# libraries product-backlog

posta mmathis 16.12.2016 - 21:58

fonte

1 risposta

Leggi altre domande sui tag c# libraries product-backlog

Modifica di un'applicazione open source Come faccio ad iniettare oggetti test quando gli oggetti reali sono creati dinamicamente?

score 5 · Answer 1

In base alla descrizione, la libreria comune sembra essere una raccolta di funzionalità aziendali e utilità comuni a molti dei tuoi progetti. Le regressioni causate dalle modifiche di un prodotto potrebbero non essere immediatamente visibili negli altri prodotti.

Alcuni consigli principali sono:

Versioning

Come dici, la libreria è piuttosto stabile. Il versionare questa libreria, se non lo hai già fatto, è il primo passo per prevenire gli effetti collaterali. Una volta rilasciato, si presume che gli elementi di versione siano immutable .

Ogni progetto che consuma dovrebbe bloccarsi su una versione nota della biblioteca. QA deve solo preoccuparsi di interrompere le modifiche quando scelgono di eseguire l'aggiornamento a una versione più recente della libreria. A questo punto, dovrebbero comunque eseguire test completi di regressione.

Il versioning semantico (major-minor-patch) è uno schema di gestione basato sulla compatibilità che potrebbe applicarsi nel tuo caso. Le versioni della libreria possono essere facilmente gestite tramite strumenti di gestione degli artefatti come NuGet. Il codice sorgente può essere mantenuto utilizzando rami, tag o meccanismi simili.

Note sulla versione : con il controllo delle versioni, hai il vantaggio aggiuntivo delle note sulla versione. Ogni versione può descrivere le correzioni dei bug e i miglioramenti apportati a quella versione. Ciò lo rende più visibile ai proprietari dei prodotti, agli sviluppatori e al controllo qualità, in modo che possano prendere decisioni informate.

decomposizione

Sulla base di dati storici, potresti avere una buona idea su quali aree della biblioteca hanno il maggior numero di modifiche o di abbandoni. Potresti anche avere aree di funzionalità abbastanza indipendenti all'interno della stessa libreria.

Potrebbe essere una buona idea separare queste aree in librerie e moduli indipendenti, ognuno con le proprie versioni e versioni di dipendenza bloccate. Ciò aiuta a ridurre l'impatto dell'aggiornamento della versione e isolare gli effetti di ripple su un'area più definita.

I proprietari dei prodotti possono ora tenere traccia di quali sottomoduli richiedono la massima attenzione e potrebbero essere in grado di creare un team dedicato per gestire o QA quelle aree specifiche, se necessario.

Test unitari e test e2e

Definisci le tue "unità" di funzionalità. Nella maggior parte delle utility, l'unità è una singola classe o una singola funzione. In alcuni casi, potrebbe essere un modulo.

Test dell'unità di progettazione per coprire le singole funzionalità. Utilizza la regola 80-20 per decidere quali unità richiedono più test. Inoltre, progetta test end-to-end se necessario, prendendo in giro i consumatori delle librerie di esempio e testando il comportamento previsto.

Questa sarà la prima linea di difesa e dovrebbe avvisare gli sviluppatori che stanno apportando modifiche incompatibili e devono aggiornare la versione.