Come evitare il branchageddon con le grandi organizzazioni?

10

Come evitare una situazione branchageddon quando si lavora con grandi organizzazioni?

Collaboriamo con numerose organizzazioni finanziarie di grandi dimensioni il cui approccio non prevede l'aggiornamento del software, ma solo patch di sicurezza elevate / critiche e funzionalità personalizzate. Queste organizzazioni prenderanno solo patch e versioni personalizzate tra i principali aggiornamenti. Gli aggiornamenti principali possono essere separati da anni e comportare costi elevati. Questo approccio fa sì che noi (la software house) abbiamo una filiale del nostro codice per cliente principale, che comporta tutti i costi e le inefficienze della ramificazione a lungo termine.

Le mie domande alla comunità sono:

Hai provato approcci di accettazione degli aggiornamenti simili da parte dei tuoi clienti?
Quali suggerimenti hai per aiutarti a lavorare con questo approccio?
Quali suggerimenti hai per aiutare a cambiare gli approcci delle organizzazioni per prendere gli aggiornamenti del software?

release process branch

— Mark Wheeler
fonte

Ehi Mark, sembra che tu abbia un dilemma interessante. Come gestite lo sviluppo di questi aggiornamenti per cliente? Li sviluppi su base una tantum per ogni cliente o è qualcosa che sviluppi e applichi a tutti i clienti?

— PrestonM,

Personalmente, potrei cercare un altro impiego in questa situazione. Sembra un incidente di sicurezza in attesa di accadere ... Posso dirti per il fornitore di elettrodomestici per cui ho lavorato, avevano un grosso bug che è stato corretto in un aggiornamento a cui, secondo quanto riferito, non potevano andare. Volevano una soluzione personalizzata. Ci siamo rifiutati di costruirne uno e abbiamo detto loro che dovevano andare a sistemare le loro politiche aziendali - non avremmo lanciato un hotfix personalizzato per un bug che avevamo già corretto solo per evitare problemi politici interni.

— James Shewey,

Gestiamo gli aggiornamenti specifici del client personalizzato tramite più rami di codice e correggiamo gli aggiornamenti di sicurezza di tutti i rami e ripristiniamo il codice di ramo di fissaggio nel trunk. Spesso il cliente A non accetta gli aggiornamenti del cliente B nella propria filiale, ma solo i propri aggiornamenti e le patch di sicurezza. Ciò è guidato da un desiderio di stabilità nel loro ramo e quindi devono solo testare gli aggiornamenti rilevanti per loro. Prendono gli aggiornamenti del bagagliaio meno frequentemente (ad esempio mesi o anni) quando sono pronti per eseguire repliche di test complete, che possono richiedere mesi per essere completate. I test automatizzati potrebbero essere la risposta!

— Mark Wheeler,

3

Come menzionato da Michael, offri una soluzione standard basata su versioni / numeri di rilascio, con una durata ragionevolmente lunga per il tuo settore (forse interlacciato con una o più versioni intermedie di durata più breve, se ha senso per i tuoi clienti tipici).

Offri ai tuoi clienti la possibilità di intraprendere questa traccia di rilascio standard, magari con una scadenza decente per la migrazione.

Se insistono su una strategia di supporto delle filiali completamente personalizzata, è sufficiente addebitarli di conseguenza, per coprire correttamente tutti i costi aggiuntivi per offrire tale assistenza completamente personalizzata - ha senso solo dal punto di vista commerciale. Alcuni clienti migreranno per ridurre i loro costi (che ti aiuteranno a ridurre il numero di filiali personalizzate), altri no.

La fatturazione con supporto variabile, che cresce progressivamente con l'età delle versioni di rilascio da cui provengono le filiali personalizzate, può anche essere un incentivo per i clienti a migrare più rapidamente verso le filiali più recenti, aiutando con una chiusura più rapida delle filiali personalizzate più vecchie. Ciò può aiutare a ridurre il numero di filiali personalizzate per cliente, se si dispone di clienti che eseguono simultaneamente più versioni del software.

Assicurati di non cadere nella trappola di eseguire fusioni di filiali complete da / verso una qualsiasi delle filiali di rilascio (sia standard che personalizzate), tutte le modifiche ad esse devono essere sia correzioni unite sviluppate individualmente che selezionate ciliegia.

Poiché ciascuno di questi rami divergerà gradualmente l'uno dall'altro, il numero di hotfix che richiedono personalizzazione / sviluppo individuale crescerà in modo esponenziale (la semplice fusione di ciliegie fallirà). È necessario tenere conto dei costi di sviluppo per questi.

Con nessuna (significativa) succursale nell'immagine puoi (e dovrei, non posso sottolineare abbastanza la sua importanza) costruire pipeline CI / CD completamente automatizzate per queste succursali, accompagnate da un buon sistema di tracciamento / gestione dell'hotfix in atto, rendendo la consegna dell'hotfix solo di routine (o quasi).

— Dan Cornilescu
fonte

Dan - così ovvio e semplice ma ha perfettamente senso. Il denaro fa girare il mondo e, a sua volta, dovrebbe aiutarci a compensare il costo di filiali di lunga durata o incoraggiare i clienti a migliorare e stare vicino al bagagliaio. Grazie per il tuo buon consiglio.

— Mark Wheeler,

1

Forse se gestissi filiali per versione anziché per cliente, potresti contribuire a ridurne il numero?

Altrimenti, l'unico modo per evitarlo è quello di essere in grado di ospitare il software da soli e passare a un modello SaaS in cui sarebbe possibile mantenerne solo una versione.

— Michael Pereira
fonte

Purtroppo i nostri clienti spesso operano in ambienti molto chiusi a causa dei dati finanziari con cui stanno lavorando, quindi un modello SaaS non sarebbe accettabile.

— Mark Wheeler,