Implementare la strategia di ramificazione nell'applicazione DevOps for Multi-Tenant

Question

Implementare la strategia di ramificazione nell'applicazione DevOps for Multi-Tenant

#1 da (0 voti)

0

Ho posto questa domanda su Stack Overflow e ho ricevuto un suggerimento di postarla qui per una migliore idoneità. Quindi, ecco la mia domanda:

Sono nuovo di DevOps, e ho una soluzione con Umbraco come CMS, Mobile App come front-end per il contenuto aggiunto in CMS e .Net MVC web API per connettere CMS con l'app mobile. Ho anche WebJob e Microsoft flusso per alcune attività di pianificazione.

Devo implementare DevOps per la mia multi tenant application, ecco il mio scenario:

La soluzione avrà un'applicazione master che servirà solo come elenco principale di funzionalità per l'amministrazione per abilitare le funzionalità durante la creazione di una nuova comunità. Più comunità con database separati, ogni comunità ha più funzionalità (Feature1, Feature2). Ci dovrebbe essere un modo per gli sviluppatori di integrare l'integrazione e di integrare le funzionalità indietro.

Dopo aver aggiunto la funzione a qualsiasi comunità, può avere le sue personalizzazioni in particolare. In alcuni scenari gli sviluppatori devono anche aggiungere queste modifiche al master o alle comunità di pari livello. Ho anche aggiunto l'immagine per una migliore comprensione.

Ho bisogno di aiuto per creare la strategia di ramificazione per la mia soluzione che soddisfi tutti i requisiti di cui sopra e riduca al minimo le probabilità di conflitti mentre uniamo i rami in tutte le direzioni. Ho sotto le opzioni nella mia mente.

Dovrei considerare ciascuna caratteristica come un ramo separato? In caso affermativo, che ne pensi di gestire le modifiche specifiche della comunità eseguite in una singola comunità?
Dovrei considerare ogni comunità come un ramo separato? In caso affermativo, come separare il codice funzione da unire al ramo della comunità?
Dovrei considerare il codice condiviso tra tutte le comunità? In caso affermativo, quali sono le modifiche specifiche della comunità?

Tutto sarà pronto al volo una volta implementato (nella base di codice con Visual Studio 2017). Quale strategia dovrei fare? O c'è un approccio migliore di questi? Come posso risolvere i conflitti di fusione se generati dopo la distribuzione? Inoltre, in DevOps dovrei andare per Git o TFS?

git branching devops

posta Developer 20.12.2018 - 07:09

fonte

1 risposta

Leggi altre domande sui tag git branching devops

Significato / utilizzo della barra verticale in Pratiche basi per linguaggi di programmazione? Progettazione controller per architettura Java modulare

score 0 · Answer 1

Rendilo semplice per te. Basta mettere tutte le "comunità" in un singolo ramo.

Nella maggior parte delle metodologie di sviluppo, i rami di funzionalità vengono creati per isolare lo sviluppo di una funzione; una volta completata la funzione, deve essere unita al ramo principale e diventano parte dell'applicazione di base. I branch delle funzionalità non sono pensati per isolare diverse configurazioni di un'applicazione.

Aggiungi i flag di funzionalità all'applicazione, usa i modelli di strategia per fornire un comportamento diverso per diverse configurazioni.

In questo modo, non è necessario ricreare le applicazioni più volte per ogni comunità, tutti utilizzano gli stessi eseguibili esatti, con le differenze descritte in alto livello in un insieme di file di configurazione.

Se la configurazione della comunità è complessa, è possibile che si desideri eseguire anche la versione dei file di configurazione, ma questi file di configurazione devono essere sottoposti a una versione in un repository separato rispetto all'applicazione di base. Probabilmente vorresti creare un repository per ogni "community", o in alternativa potrebbero essere diversi git root nello stesso repository, è improbabile che tu debba voler condividere le configurazioni tra "community", quindi dovresti evitare di unirmi tra diverse radici della comunità. Un'altra alternativa è creare un ramo unifamiliare con tutte le comunità come cartelle, questo dovrebbe essere fatto con cautela, poiché potrebbe essere difficile dividere le configurazioni per una singola "community" senza perdere la cronologia git, poiché le loro storie saranno intrecciate con altre "comunità".