Attualmente la nostra organizzazione ha diverse applicazioni Web in esecuzione su server lampada. Sono per lo più contenuti statici, ma includono anche php tramite codeigniter / laravel / vanilla php.
Ogni volta che apportiamo modifiche a uno qualsiasi dei file, aggiorneremo un repository git su un server separato per tracciare quella modifica. Tuttavia, disponiamo anche di manutentori di contenuti e di numerosi clienti aziendali fidati che aggiorneranno il contenuto statico sulle pagine e aggiorneranno tali modifiche al server di produzione senza impegnarsi a git.
Come puoi immaginare a volte questo può essere piuttosto confuso, ei conflitti accadono spesso dove un individuo tirerà giù l'ultimo repo pensando che i cambiamenti siano attuali, faccia il loro aggiornamento, spinga il file alla produzione, e poi 15-20. alcuni minuti dopo riceviamo telefonate perché hanno sovrascritto le modifiche non registrate nel repository.
Ho considerato cosa fare riguardo a questo dilemma e sono giunto alla seguente conclusione. Abbiamo bisogno di avere un repository di produzione configurato sulla scatola di produzione, al di fuori del webroot (in modo che non sia pubblicamente accessibile), e creare un servizio che si impegnerà ogni volta che un file è stato caricato sul server. Questo servizio può essere scritto per avvisare un amministratore se / quando sorgono conflitti e inviare modifiche a un repository remoto in un lasso di tempo (ogni ora / notte / settimana / ecc.).
La mia domanda è ... sembra ragionevole? C'è un modo migliore per realizzare questo compito? Capisco e sono completamente d'accordo sul fatto che la risoluzione ideale sarebbe quella di consentire solo modifiche alla produzione tramite un hook attivato quando viene eseguito un commit al repository e costringono gli utenti ad imparare Git (o un altro strumento di distribuzione che integra Git), tuttavia questo non è un'opzione.