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

16

Sto cercando di raccogliere modi efficaci in cui altri hanno risolto il seguente problema. Al lavoro siamo stati costretti a rilasciare una patch software (da installare sui sistemi degli utenti finali) che vogliamo essere visibile solo a un cliente specifico. Il codice personalizzato si trova nel proprio ramo di controllo del codice sorgente. Il problema è che abbiamo due righe di codice parallele (e script di compilazione) da mantenere sincronizzati e ogni volta che correggiamo il codice originale dobbiamo correggere e testare il codice specifico del cliente.

Sono curioso, come fanno le altre organizzazioni a gestire questo scenario? Siamo aperti alle soluzioni aziendali e non solo a quelle tecniche (legate al controllo del codice sorgente). Ad esempio, abbiamo parlato di dire al cliente che non possono ricevere aggiornamenti su quel ramo.

La nostra strategia di branching è così (basata sulla Guida Branching TFS di Visual Studio , anche se per questo stiamo usando Subversion) inserisci qui la descrizione dell'immagine

version-control business release-management

— Vimes
fonte

Se stavi usando hgo gitpotrei suggerirti di esaminare le code di patch ( estensione delle code mercuriali o stacked Git ) ma non so se TFS ha qualcosa di simile.

— Mark Booth,

Forse avrei dovuto specificare che stiamo usando Subversion anche se usiamo una strategia di ramificazione che suggerisce TFS: P Le code di patch ridurrebbero i test necessari? Sembra che questi siano per patch di controllo del codice sorgente? Abbiamo a che fare con patch installate dai clienti sui sistemi degli utenti finali.

— Vimes

2

Una soluzione aziendale sarebbe: non farlo.

— JeffO,

@JeffO good call =) In ogni caso, c'è un modo per rendere questo un interruttore di runtime guidato dai dati?

— Patrick Hughes, il

1

@JohnB - Siamo spiacenti, non lo so, ma se si dispone di patch di origine, il sistema di compilazione dovrebbe essere in grado di automatizzare i test, oltre a mantenere le patch per cliente al di fuori di ciò svnche non ingombrano il normale flusso di lavoro. Se le code di patch sembrano essere utili, puoi provarle usando git-svn o hgsubversion . L'uso di un front-end DVCS per appianare un flusso di lavoro complicato svnpotrebbe persino incoraggiare le persone a prendere in considerazione il passaggio a un DVCS all'ingrosso, per ottenere tutti gli altri vantaggi.

— Mark Booth,

5

Quando inizi a distribuire patch specifiche per il cliente, hai immediatamente creato una nuova versione del tuo prodotto che deve essere mantenuta a fianco di essa. 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 riparare qualcosa non lo faccia nel ramo mainline a meno che questa non sia una soluzione temporanea non ottimale per un problema immediato. In tal caso, la patch dovrà essere mantenuta solo fino a quando la correzione prevista non verrà inserita nella linea principale.

— Charles Lambert
fonte

5

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

— Loren Pechtel
fonte

Questo potrebbe funzionare per personalizzazioni semplici, ma quelle più complesse potrebbero rendere il prodotto più imbarazzante e instabile per tutti i clienti.

— FrustratedWithFormsDesigner

3

@FrustratedWithFormsDesigner Personalizzazioni complesse per singoli clienti rappresentano una grave negligenza nella gestione e nella progettazione del prodotto. Qualsiasi soluzione che richiede una filiale separata per un singolo cliente per un prodotto rappresenta una grave inadeguatezza nel prodotto per soddisfare tutte le esigenze dei clienti e una cattiva gestione da parte del proprietario del prodotto.

— maple_shaft

2

Ho anche visto questo morso più volte il mio precedente datore di lavoro. È solo una cattiva pratica, ma di solito è qualcosa che i dirigenti vogliono e non si tireranno indietro. Soprattutto se stai usando Subversion, questo è solo un incubo che non andrà via: mantenere il codice sincronizzato farà male, di volta in volta.

— Steve Hill,

1

@maple_shaft - Ma hai pensato di porre la domanda "hai mai usato la ramificazione del codice per implementare l'internazionalizzazione"?

— psr

3

@maple_shaft - Stavo scherzando, ma, in realtà, quello era il mio punto, usare le ramificazioni per gestire l'internazionalizzazione è almeno tanto grave quanto le filiali specifiche dei clienti. Non è discutibile nel senso che probabilmente non vorrai nemmeno lavorare in un posto simile. È discutibile che stavo andando fuori tema.

— psr

3

Lo vedi come una cosa a breve o lungo termine? Il fatto è che l'azienda ha già deciso di soddisfare questo cliente così a breve termine che è già una decisione aziendale che deve essere risolta principalmente dalle pratiche commerciali (accettare il costo aggiuntivo / addebitare al cliente il costo).

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

Se è relativamente a breve termine, significa che presto unirai tali modifiche nel ramo principale / di 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, risolvilo tecnicamente, a breve termine.

Naturalmente c'è un punto in cui si tratta di un lancio di una moneta. Se sei a quel punto, farei qualunque cosa preferiscano gli sviluppatori.

— ElGringoGrande
fonte

2

Usiamo anche la sovversione - e ci imbattiamo esattamente in questo scenario.

Ecco alcuni punti chiave da ricordare:

Mentre è necessario, si devono evitare filiali specifiche per i clienti, la necessità deve essere ridotta al minimo possibile; chiedi sempre se è possibile generalizzare la soluzione che potrebbe funzionare solo per tutti.
Le filiali specifiche 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 - alle filiali dei clienti dovrebbero essere consentite tutte le patch, quindi le filiali dei clienti devono rimanere compatibili rispetto alla versione principale.
È necessario creare una filiale specifica per il cliente quando si avvia una nuova versione non compatibile. La parte sfortunata è che in qualche modo potresti richiedere di rifare il lavoro. Una soluzione può essere quella di creare tutte le patch dalle filiali dei clienti che devono essere estratte e tutto ciò che risulta essere ancora compatibile può essere applicato alla nuova filiale dei clienti.
Sempre, in nessun caso, è necessario rinviare le modifiche specifiche del cliente per rilasciare filiale o trunk. Tuttavia, idealmente si dovrebbe cercare di generalizzare il lavoro in modo tale da ridurre tale lavoro specifico per il cliente.

Ho provato a mettere insieme queste idee per mostrarle diagramma sotto :

— Dipan Mehta
fonte

1

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, si carica e potrebbe contenere una versione specifica dell'azienda di Foo

class FooForABC : Foo
{
}

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

— Winston Ewert
fonte