Come gestite i cambiamenti nei framework open source che utilizzate per i vostri progetti?

Potrebbe essere una mia stranezza personale, ma mi piace tenere aggiornato il codice nei progetti viventi, comprese le librerie / i framework che usano. Parte di ciò è che ritengo che un'app Web sia più sicura se è completamente patchata e aggiornata. Parte di esso è solo un tocco di compulsività ossessiva da parte mia.

Negli ultimi sette mesi, abbiamo fatto una riscrittura importante del nostro software. Abbiamo abbandonato il framework Xaraya, che era lento ed essenzialmente morto come prodotto, e convertito in Cake PHP. (Abbiamo scelto Cake perché ci ha dato la possibilità di eseguire una riscrittura molto rapida del nostro software e abbastanza un aumento delle prestazioni su Xaraya per far valere la pena.)

Abbiamo implementato unit test con SimpleTest e seguito tutte le convenzioni di denominazione di file e database, ecc.

Cake è ora in fase di aggiornamento alla 2.0. E non sembra esserci un percorso di migrazione praticabile per un aggiornamento. Le convenzioni di denominazione per i file sono cambiate radicalmente e hanno eliminato SimpleTest a favore di PHPUnit.

Questo ci costringerà a rimanere sul ramo 1.3 perché, a meno che non ci sia una sorta di strumento di conversione, non sarà possibile aggiornare Cake e quindi migliorare gradualmente il nostro codice legacy per raccogliere i benefici del nuovo framework Cake . Quindi, come al solito, finiremo con un vecchio framework nel nostro repository Subversion e lo ripareremo noi stessi secondo necessità.

E questo è ciò che mi prende ogni volta. Quindi molti prodotti open source non rendono abbastanza facile mantenere aggiornati i progetti basati su di essi. Quando gli sviluppatori iniziano a giocare con un nuovo giocattolo luccicante, verranno fatte alcune patch critiche ai rami più vecchi, ma la maggior parte del loro focus sarà sulla nuova base di codice.

Come gestite i cambiamenti radicali nei progetti open source che utilizzate? E, se stai sviluppando un prodotto open source, tieni a mente i percorsi di aggiornamento quando sviluppi nuove versioni?

Il problema non è unico per l'open source. Gli stessi problemi si verificano con progetti commerciali. Forse ancora di più perché non hai una fonte puoi mantenerti se la compagnia abbandona il supporto.

I progetti open source di tipo utente finale hanno cicli di upgrade rapidi e le versioni precedenti perdono il supporto molto rapidamente. D'altra parte, i progetti progettati per consentire agli utenti di mettere a punto un notevole sforzo di codifica tendono ad avere lunghi cicli di supporto del vecchio ramo dopo un importante aggiornamento. Abbastanza a lungo da permetterti di prenderti il ​​tempo prima di aspettare che si stabilizzi e maturi, quindi migrando e testando a fondo il tuo codice.

Può essere difficile resistere alla tentazione di avere l'ultima e la più grande, ma rendersi conto che esiste un compromesso fondamentale nel software tra stabilità e nuove funzionalità. Non puoi averne uno senza sacrificare l'altro. Ecco perché esistono rami bugfix, quindi puoi scegliere quale lato dello spettro si adatta meglio alle tue esigenze.

Abbiamo risolto questo problema modularizzando il nostro codice.

Il nostro sito Web principale è stato realizzato circa otto anni fa e abbiamo avuto la fortuna di essere realizzato da uno dei primi collaboratori del Spring Framework, quindi era una fondazione piuttosto ben costruita. Ma sfortunatamente siamo stati anche abbastanza sfortunati che questo sviluppatore ha deciso di rovesciare Spring dopo una discussione sulla direzione in cui stava andando, quindi questa base di codice è ora bloccata su una fork non mantenuta di Spring 1.1.4 (o qualcosa di quell'annata).

Abbiamo provato a riscrivere il codice per passare alle nuove versioni di Spring, ma ciò si è rivelato estremamente difficile. Quindi la nostra soluzione era iniziare a costruire nuove funzionalità del sito come moduli in un'applicazione completamente separata, utilizzando i più recenti framework come Spring 3.x, Hibernate 3.6, ecc.

Ora abbiamo due applicazioni Web in esecuzione sullo stesso URL di base e utilizziamo il modulo mod_proxy di Apache per allocare ciascun percorso all'applicazione appropriata. Ad esempio, "/ members" va alla vecchia applicazione e "/ directory" va alla nuova applicazione. Tuttavia, un visitatore del sito non avrebbe idea di utilizzare diverse applicazioni; sembrano esattamente gli stessi per l'utente.

Le due applicazioni devono comunicare, ad esempio quando un membro accede al sito (utilizzando la nostra nuova applicazione) dobbiamo notificare alla vecchia applicazione che sono ora connessi. Lo facciamo utilizzando un semplice servizio Web, esposto solo a localhost. La quantità di integrazione necessaria tra le due app si è rivelata minima.

Una parte importante di questo lavoro è stata l'identificazione e il confezionamento di risorse condivise. Quindi tutto il testo, la grafica, i fogli di stile, i Javascript e i modelli statici sono stati spostati dall'applicazione originale in un progetto separato, terzo, utilizzato sia dalle applicazioni nuove che vecchie. Ciò garantisce che entrambe le applicazioni Web appaiano e agiscano allo stesso modo anche se sono completamente separate.

Immagino che col tempo sostituiremo sempre più l'applicazione originale fino a quando alla fine non sarà completamente necessaria. La cosa bella di questa tecnica è che possiamo farlo lentamente attraverso una serie di piccoli cambiamenti a basso rischio - non è necessario un passaggio improvviso massiccio e rischioso a un nuovo sistema.

Non lo faccio sempre. Molti progetti open source hanno filiali di manutenzione attive per precedenti versioni principali. A volte quelli sono gestiti da persone che hanno bisogno di quella versione per essere mantenuta. Molti progetti restano in una versione importante fino a quando non sono pronti per una versione principale.

E questo è ciò che mi prende ogni volta.

Ogni volta? Devi fare delle scelte notevolmente sbagliate. Ci deve essere un esempio in cui non è successo.

Quando gli sviluppatori iniziano a giocare con un nuovo giocattolo luccicante

Questo è un suggerimento. Evita nuovi giocattoli luccicanti quando usi progetti open source. Evitare la versione 1.0.

Come gestite i cambiamenti radicali nei progetti open source che utilizzate?

Step 1. Scegli i progetti open source con molta, molta attenzione. Confronta sempre due o più progetti concorrenti.

Passaggio 2. Quando si confrontano due progetti concorrenti, provare a comprendere la funzione "essenziale" offerta e il modo in cui entrambi si avvicinano. Evita di "sposare" un'API specifica troppo presto.

Step 3. Abbraccia i principi di progettazione di "Late Binding" e "Loose Coupling". Cerca di isolarti dalle modifiche del progetto open source.

Passaggio 4. Confrontare esplicitamente costi / benefici tra progetti open source e "rolling your own". Di tanto in tanto, creare la propria soluzione potrebbe essere meglio che far fronte a una soluzione open source.

La modifica dei nomi dei file non dovrebbe essere troppo difficile. Sì, è una sceneggiatura grande, brutta. Sì, deve essere eseguito per diverse settimane durante la conversione. Ma è un costo limitato.

Se succede ogni volta, sviluppa strategie di coping migliori. Dal momento che la tua osservazione del mondo reale è che succederà sempre, sperare che il mondo reale cambi non sarà davvero di grande aiuto. Hai una dura esperienza nel cambiamento. Sfruttalo. Consideralo come un'infezione e sviluppa la tua risposta immunitaria.