Le migliori pratiche per quando una dipendenza di terze parti si rompe?

Question

Le migliori pratiche per quando una dipendenza di terze parti si rompe?

#1 da (4 voti)
#2 da (2 voti)
#3 da (1 voti)

4

Sto lavorando in un progetto php e le nostre dipendenze di terze parti sono gestite con packagist tramite composer.json . Roba abbastanza standard. A volte ci imbattiamo in una situazione in cui un determinato plug-in ha qualche problema, tale che vorremmo continuare a utilizzare il plug-in, ma il problema lo rende una responsabilità o semplicemente inutilizzabile.

Un'idea potrebbe essere quella di effettuare una richiesta di pull per risolvere il problema, ma ciò implica "a. il repository viene monitorato attivamente e b. in realtà sappiamo come risolvere il problema". Potremmo non averne né Se abbiamo (b) ma non (a) potremmo sborsare il pronti contro termine con la nostra correzione? O potremmo modificare il file nella directory vendor e impegnarlo nel repository? Entrambe le prospettive sembrano poco attraenti.

Più recentemente il pacchetto php-whois ha avuto un problema, perché utilizzava un codice terribilmente asinino:

if (empty($r)) {
    if ($hasreg)
        $r['registered'] = 'no';
}

Se $r non è impostato, o ='' o =0 o =null o un numero di altre situazioni, empty($r) sarà true e $r['registered'] = 'no' genererà almeno un avviso, oppure, a partire da php ~ 7.1 +, innesca un errore fatale.

Qual è la migliore linea d'azione? Trova un nuovo pacchetto php-whois ? Risolvi la (facile) correzione (esegui solo $r=[]; ) e impegnati nel nostro repository? Qualcos'altro?

Questa è una situazione complicata in cui non mi trovo spesso, ma è emersa più di una volta.

Uso di Laravel 5.3 , nel caso sia pertinente.

third-party-libraries

posta chiliNUT 11.05.2017 - 05:35

fonte

3 risposte

Leggi altre domande sui tag third-party-libraries

Possono esserci più aggregati per lo stesso concetto? Come avvicinarsi a questo progetto Java legacy? [duplicare]

score 4 · Answer 1

Dipende, non esiste una soluzione generale. Cose che devi considerare:

le condizioni di licenza del pacchetto di terze parti (in particolare per il caso in cui desideri modificare il codice sorgente)
la volontà del fornitore / manutentore di correggere i bug, o di accettare la richiesta di pull, in combinazione con i suoi tempi di risposta
per i pacchetti commerciali: il tuo contratto con il venditore
la possibilità di creare una soluzione alternativa nel tuo codice, senza modificare il codice del pacchetto
la complessità del pacchetto e la possibilità di implementare le proprie correzioni di bug senza interrompere altre cose
la disponibilità di pacchetti alternativi, la loro qualità, i termini della licenza e lo sforzo necessario per passare a tale alternativa
i tuoi requisiti per i tempi di risposta nel caso in cui il tuo sistema abbia un problema a causa di questo

Ti consiglio ogni volta che devi scegliere un componente di terze parti, investi alcuni pensieri in questo punto prima inizi a utilizzare il pacchetto, altrimenti non stupirti se ti svegli un po 'di mattina e riconosci ti sei dipinto in un angolo.

score 2 · Answer 2

Il problema è che stai eseguendo l'aggiornamento a nuove versioni di librerie di terze parti e trasferisci la cosa in produzione senza testarla accuratamente.

L'aggiornamento di una dipendenza non è diverso da qualsiasi altra modifica nel codice. Ciò significa che una volta effettuato il cambiamento, è necessario eseguire test di regressione automatici per essere sicuri che tutto funzioni correttamente.

The php version of the production server is slightly more recent than the version used in the vagrant box we develop on. So, everything was fine in development and didn't become an issue until we pushed to production

Questi test dovrebbero essere eseguiti su un ambiente il più vicino possibile alla produzione. Se li si esegue su una versione diversa di PHP e quindi si spinge la modifica in produzione con noncuranza, avrà regressioni, e non è colpa di una libreria di terze parti, ma piuttosto di un flusso di lavoro imperfetto.

Quindi, torna alla tua domanda:

One idea might be to make a pull request to fix the issue [...] we could fork the repo with our own fix? Or we could modify the file in the vendor directory and commit it to the repo? Both prospects seem unappealing.

Se contribuisci attivamente a librerie di terze parti, in altre parole se il tuo capo pensa che fare ciò avrà benefici finanziari per l'azienda, allora fallo.

Se no, non è il tuo lavoro. Sei pagato per lavorare sul progetto, non contribuire alle librerie di terze parti. Il tuo compito è quello di garantire che qualunque cosa accada con le dipendenze, il tuo progetto funzionerebbe ancora. Cosa potrebbe accadere?

Una regressione potrebbe essere introdotta nella prossima versione della libreria. Questo è il problema che hai citato nella tua domanda.

Per mitigare il rischio di esserne influenzati, hai impostato una versione specifica della libreria che è stata testata correttamente e si è dimostrata compatibile con la tua app e il tuo ambiente di produzione. Si esegue l'aggiornamento alle versioni successive in modo analogo per eseguire qualsiasi modifica sul codice sorgente, coinvolgendo il controllo della versione e i test di regressione.
Una libreria può essere rimossa da un repository.

Per mitigare tale rischio, dovresti assicurarti di avere una sorta di proxy che memorizza nella cache tutte le versioni di tutti i repository che hai scaricato, o usi un repository di risorse. Per quanto ne so, la seconda soluzione è più comune.
Una libreria si sposta progressivamente in una direzione che non ti piace, rendendola sempre più problematica da usare.

Per attenuarlo, ti assicuri di non utilizzare la libreria di terze parti in tutto il codice. Dovrebbe esserci un'astrazione tra il tuo codice e il mondo esterno, e un adattatore ben progettato dovrebbe consentire di passare, se necessario, a una libreria diversa. In questo modo, quando sembra che una diversa libreria risponda meglio ai requisiti, basta scrivere un altro adattatore e scambiare le librerie. Semplice come quello.

score 1 · Answer 3

Ecco cosa facciamo: (che potrebbe essere totalmente inappropriato per il tuo negozio):

Siamo un negozio di Windows C ++ / C #, quindi gestiamo dipendenze di terze parti (open source o meno), esp. in C ++, è storicamente più complicato comunque.

Le migliori pratiche (?) per quando una dipendenza interrompe

Quello che facciamo con il 100% delle nostre dipendenze di terze parti è che noi:

Ospita il codice sorgente disponibile nei nostri server SCC
Ospita tutti i file binari sui nostri server SCC / artefatti
Prova a creare autonomamente i binari, dove è disponibile il codice sorgente (C ++). (Considerando tutti i flag del compilatore, questa è una necessità per la maggior parte del codice C / C ++ di terze parti. Almeno in questo modo ho anche% file coerenti di% di file.)
Anche per le librerie C # open source, dove utilizziamo i raccoglitori dal Web, è necessario che il loro codice sorgente sia disponibile sul nostro server prima di utilizzarli, ad esempio Nessun accesso a nuget pubblico: solo il nostro server aziendale per il codice rilasciato .

Quando si rompe:

Se qualcosa si rompe, poiché dovremmo essere in grado di costruirlo sulla nostra infrastruttura, diciamo, un giorno circa, (considerando che potremmo non averlo toccato per un po '), applichiamo la correzione del codice sorgente al nostro repository di origine del componente, ricostruirlo e abbiamo finito dalla nostra parte.

Laddove possibile, inviamo anche richieste / patch di pull ai progetti originali, in modo che possiamo in seguito ritornare a una versione aggiornata e non aggiornata della lib di terze parti originale.