Flusso di lavoro del controllo della versione per software semi-personalizzati

5

Ho un prodotto di app Web (PHP, MySQL) per il quale offro un servizio di bpoking. Cioè, è possibile acquistare il prodotto principale, che è piuttosto ampio, e quindi averlo personalizzato come preferisci. Ciò potrebbe includere nuove funzionalità, che regolano fondamentalmente il modo in cui funzionano le funzionalità esistenti, disattivando funzionalità, apportando modifiche che richiedono uno schema di database diverso, ecc.

Desidero trovare un modo ragionevole di gestire un gran numero di versioni diverse del prodotto nel controllo di versione in modo tale da apportare modifiche al core e apportare modifiche alle versioni in base alle esigenze, nonché apportare modifiche a un rilascio indipendentemente. A volte potrei desiderare di passare da una versione all'altra.

Il mio istinto era di usare Git e avere le uscite come rami. È possibile selezionare commit specifici per unire nuovamente il trunk, quindi penso che questo potrebbe funzionare.

Tuttavia, ovunque mi sia sembrato suggerisco che sia una cattiva idea avere un codice separato in modo permanente nelle filiali. Il suggerimento è di utilizzare una base di codice singola e avere tutte le differenze nelle funzionalità configurabili, in modo che ogni versione possa comportarsi separatamente. Questo suona bene per il software che è venduto in più edizioni, che hanno abilitate diverse funzionalità, ma penso che sarebbe un disastro completo per il mio software.

Sto cercando un buon flusso di lavoro di sviluppo per una configurazione come questa, che può o meno essere basata sul controllo della versione.

    
posta gandaliter 09.09.2014 - 18:10
fonte

3 risposte

4

Crea una massiccia applicazione con funzionalità che puoi attivare e disattivare utilizzando i file di configurazione o le impostazioni del database. La visualizzazione del sito e l'elaborazione delle richieste degli utenti diventano solo una questione di gestione delle autorizzazioni all'interno del sistema più grande. Avresti due livelli base di permessi:

  1. Impostazioni pacchetto - Qui puoi attivare o disattivare le funzioni a seconda di quanto denaro il cliente supera di $

  2. Ruoli utente - Questo è asservito alle Impostazioni pacchetto, ed è dove si definisce un "ruolo" per una persona (ad esempio, un "Editor" contro un "Writer" contro un "Amministratore"). "Scrittori" possono creare e modificare contenuti. Gli "editori" possono pubblicarlo. "Amministratori" possono modificare le impostazioni.

Ogni caratteristica dovrebbe essere il suo "modulo". Ogni modulo potrebbe avere uno o più ruoli ad esso associati. Ad esempio, avere un modulo carrello acquisti potrebbe non richiedere un "Editor", ma un "Product Manager" potrebbe essere solo il ticket.

Mantenere queste informazioni in un database e creare un sistema di gestione per queste autorizzazioni ti darebbe tanta flessibilità per riconfezionare questo software in futuro. Durante la Grande Recessione, molte aziende hanno visto le loro offerte di prodotti esistenti essere rifiutate per alternative più economiche. Le aziende sopravvissute hanno preso le stesse funzionalità e le hanno riconfezionate in combinazioni diverse per ridurre i costi.

Dovresti tenerlo a mente. Se il punto di prezzo del tuo mercato cambia improvvisamente su o giù, dovresti essere in grado di riconfezionare facilmente il tuo software per approfittare del cambio di prezzo (o semplicemente sopravvivere e pagare le bollette fino a quando le cose migliorano).

    
risposta data 09.09.2014 - 18:57
fonte
3

L'intero settore è alla ricerca di un buon flusso di lavoro per questo. Sei incappato in un problema molto comune che la maggior parte della progettazione di sistemi ha cercato di risolvere per decenni. Come personalizzi il software senza dover scrivere un tutto da capo ogni volta?

Sfortunatamente, hai scelto php, che non è molto ben progettato, quindi non avrà molte funzionalità che ti aiuteranno a mantenere tutto organizzato e astratto fino al livello appropriato di astrazione per ogni scopo. Ti darò alcuni consigli generici raccolti da un paio di decenni passati a cercare di risolvere questo problema.

  1. Stabilisci confini costanti. Va bene che il tuo software non è infinitamente personalizzabile. I sistemi infinitamente personalizzabili sono anche noti come "sistemi di sviluppo" che è quello che userete voi per scrivere il vostro software: PHP, ecc. Portatelo troppo lontano e finirete per reinventare il sistema che state usando per scrivere il sistema in primo luogo.

  2. Non è necessario memorizzare tutto come impostazione del database. Va bene offrire personalizzazioni come file, come i file .css o un insieme di file di moduli in php inseriti in una cartella. Puoi anche "codificare" le tue modifiche.

  3. Non utilizzare le istruzioni if-then con clientId o customerName per decidere cosa fare all'interno del tuo software. Consenti alle directory del file system o ai valori del database di inserire il nome del cliente, non le istruzioni del controllo di flusso.

  4. La maggior parte delle modifiche richieste dai client sarà nell'interfaccia utente, che si tratti di pagine Web o di messaggi di posta elettronica. Rendi le parti del sistema più semplici da modificare e conta di crearne di personalizzate per ciascun cliente.

  5. Non abbiate paura delle offerte di servizi white label come Wordpress, MailChimp e simili. Hanno già reso i loro sistemi multi-tenant, facendoti risparmiare tempo.

Buona fortuna!

    
risposta data 09.09.2014 - 21:12
fonte
2

Avere filiali per versioni diverse può funzionare.

Penso che il compito principale sia mantenere aggiornata la versione del ramo. Pertanto, questo approccio suggerisce frequenti fusioni / riduzioni delle modifiche nei rami master e versione per mantenerle aggiornate come richiesto.

    
risposta data 09.09.2014 - 19:06
fonte