Che cosa è un modo realistico per gestire le patch software specifiche del cliente?

Quando inizi a distribuire patch specifiche per il cliente, hai immediatamente creato una nuova versione del tuo prodotto che deve essere mantenuta lungo il suo lato. Ciò significa che le modifiche devono essere propagate tra le due versioni. Di solito le patch specifiche del cliente sono personalizzazioni che dovrebbero essere di proprietà del cliente, incluso il codice sorgente.

Sembra improbabile che una patch per risolvere qualcosa non possa trasformarla nel ramo principale a meno che non si tratti di una soluzione temporanea meno che ottimale per un problema immediato. Se questo è il caso, la patch dovrà essere mantenuta solo fino a quando la correzione prevista lo farà nella linea principale.

Mi sembra che la chiave sia "visibile" - non si tratta di avere un ramo di codice separato, ma piuttosto un'opzione di configurazione che modifica il comportamento?

La vedi come una cosa a breve o lungo termine? Il fatto è che l'azienda ha già deciso di accogliere questo cliente in modo così breve che è già una decisione aziendale risolta principalmente dalle pratiche commerciali (accettando il costo aggiuntivo / addebitando al cliente il costo).

Se a lungo termine, probabilmente vedrai dei risparmi se ridicherai il software per soddisfare facilmente le esigenze dei clienti attraverso la configurazione (o l'impostazione, ecc.).

Se si tratta di un significato relativamente a breve termine, unirai presto tali modifiche al ramo principale / sviluppo e tutti gli utenti vedranno anche le modifiche, quindi sarà probabilmente accettabile lavorare entro i limiti della tua situazione attuale. Come ho detto, la decisione su cosa fare avrebbe dovuto essere presa quando è stata presa la decisione di accogliere il cliente.

Per farla breve. A lungo termine risolverlo tecnicamente, trattarlo a breve termine.

Ovviamente c'è un punto in cui si tratta di un lancio di monete. Se sei a quel punto, farei qualsiasi cosa preferiscano gli sviluppatori.

Usiamo anche sovversione - e ci imbattiamo in tale scenario esatto.

Ecco alcuni punti chiave da ricordare:

1. Mentre è necessario evitare rami specifici per i clienti, è necessario minimizzare il bisogno; chiedi sempre se è possibile generalizzare la soluzione che potrebbe funzionare solo per tutti.

2. I rami specifici del cliente devono provenire da una nuova versione. Supponiamo che tu abbia una versione 1.2 e che tu abbia derivato dalla versione 1.2.1 alla 1.2.11 - i rami cliente dovrebbero essere autorizzati a tutte le patch, quindi il ramo cliente deve rimanere compatibile rispetto alla versione principale.

3. Il ramo specifico del cliente deve essere creato fresco quando si avvia una nuova versione non compatibile. La parte sfortunata è che in qualche modo potresti aver bisogno di rifare il lavoro. Una soluzione può essere quella di creare tutte le patch dalle filiali dei clienti che devono essere estratte e qualsiasi cosa sia ancora compatibile può essere applicata alla nuova filiale del cliente.

4. Sempre, in nessun caso, dovresti spingere indietro le modifiche specifiche del cliente per rilasciare ramo o tronco. Tuttavia, idealmente si dovrebbe cercare di generalizzare il lavoro in modo tale che il lavoro specifico del cliente venga ridotto.

Ho provato a mettere insieme queste idee per mostrare in :

Che ne dici di introdurre un meccanismo di estensione nel tuo codice?

Il tuo codice principale ha:

class Foo
{
}

All'avvio del programma, verifica la presenza di DLL / equivalente morale nella sua cartella di avvio per le personalizzazioni locali. Se ne trova uno, viene caricato e potrebbe contenere la versione specifica dell'azienda di Foo

class FooForABC : Foo
{
}

FooForABC implementa lo stesso comportamento di Foo ma sovrascrive le funzioni necessarie per fornire il comportamento specifico di cui ABC ha bisogno. La tecnica dovrebbe essere abbastanza flessibile da gestire qualsiasi scenario tu debba supportare.