Come applicare le modifiche specifiche dell'ambiente all'interno del classico modello di branching di Git?

Question

Come applicare le modifiche specifiche dell'ambiente all'interno del classico modello di branching di Git?

#1 da (13 voti)

7

Comprendo il classico modello di distribuzione e distribuzione come detto (in alcune piccole varianti di seguito):

apporta le modifiche sul ramo dev
unisci dev > staging branch, distribuire sul server di staging, testarlo
unisci dev > ramo di produzione, distribuire il server di produzione.
non effettuare commit direttamente sui rami di staging o produzione. Unisci solo le modifiche in quei rami da dev.

Il mio problema è relativo al punto (4): ho alcuni file che saranno diversi a seconda che stia girando su dev, staging o produzione. Questi possono includere cose come robot.txt, file di avvio del server (forse lo staging è su Heroku e il lancio con un Procfile mentre la produzione è su EC2), ecc. Cose che sono specifiche della versione di distribuzione e non specifiche dell'applicazione.

Il modello di ramificazione sopra riportato sembra dire che subito dopo l'esecuzione completa della distribuzione, production = staging = dev. Tuttavia, non lascia spazio per quelle regolazioni tra i diversi ambienti.

Come viene risolto nell'industria?

===== soluzioni Posso pensare =======

utilizzando le variabili di ambiente su ogni ambiente. Il lavoro per in switch di configurazione del codice. Lo uso già ma non vedo come questo possa influire su modifiche che si trovano al di fuori del codice dell'applicazione.
aggiungendo le modifiche alla distribuzione come commit direttamente sul ramo di staging e produzione e l'unione delle modifiche dell'applicazione da dev (ad esempio, la gestione temporanea conserva una versione diversa di robot.txt, quindi di produzione). Sembra contraddire il punto (4)

branching deployment configuration-management

posta Jad S 17.11.2017 - 17:23

fonte

1 risposta

Leggi altre domande sui tag branching deployment configuration-management

Come faccio a gestire gli effetti collaterali in Event Sourcing? Cosa si intende per "Ripeti attività"?

score 13 · Answer 1

Git non è adatto per gestire diverse varianti del tuo codice.
Git non è un meccanismo di distribuzione.
Git è solo un sistema di gestione del codice sorgente.

Una cosa che si perde quando si usa git push come comando FTP glorificato è che il codice sorgente è il codice sorgente, e non necessariamente la stessa cosa che si distribuisce. Ciò vale anche per i sistemi interpretati in cui il codice sorgente può essere eseguito direttamente.

Un modo per risolvere questo problema è introdurre un processo di generazione e distribuzione che raccolga i file necessari e li distribuisca a un determinato obiettivo. Il tuo albero dei sorgenti in Git potrebbe quindi trovarsi in uno stato valido per eseguirlo in una modalità di sviluppo, ma per i tuoi target di produzione verranno utilizzati diversi file di configurazione. Ad esempio, ma non necessariamente, un'immagine Docker potrebbe essere un tale formato di implementazione.

Se una destinazione di distribuzione (come Heroku) si aspetta di essere distribuita tramite Git, sarebbe possibile utilizzare un altro repository o ramo separato dal codice sorgente che contiene lo stato da distribuire. Questo sembra piuttosto hacker, ma in realtà funziona molto bene. Tuttavia, questo ramo / repository non contiene alcun codice sorgente che deve essere controllato in versione poiché è in gran parte un duplicato del codice sorgente reale (dal quale può essere ricostruito in qualsiasi momento). Può quindi essere occasionalmente desiderabile potare questi rami. Si perde anche un'associazione diretta tra il commit distribuito e il commit del codice sorgente corrispondente. Heroku potrebbe anche offrire altri tipi di implementazione che non violano Git, ma non ne sono a conoscenza.

Se una destinazione di distribuzione consente di eseguire gli script di pre-distribuzione, questa sarebbe un'altra soluzione. Tale script può quindi impostare l'ambiente necessario. Affinché funzioni, questo script deve essere ignorato da altri target o in grado di rilevare sotto quale destinazione è in esecuzione.

In ogni caso, l'aggiunta di commit specifici della destinazione di distribuzione durante il processo di rilascio che non dovrebbero essere riuniti in dev è un antipattern. Questi verranno rimossi in un'unione, o non diventeranno mai parte della storia di altri rami. Git non è bravo a mantenere un insieme di modifiche che vivono solo su un ramo se vuoi unire altri rami.