Git repo strategia di applicazioni Web aziendali clienti anche accedere al server

0

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.

    
posta nullReference 08.12.2016 - 18:07
fonte

1 risposta

1

Suggerirei di creare una terminologia standard e di creare una semplice documentazione, in modo che tutte le parti interessate possano accettare una politica.

Ci sono (almeno) due problemi che devono essere risolti. Il primo è che il contenuto dinamico è gestito al di fuori del repository. Quindi, ti piacerebbe una soluzione, in modo tale che eventuali modifiche del contenuto dinamico vengano tracciate nel repository. Ciò potrebbe essere ottenuto attraverso l'automazione dei commit del repository delle directory di contenuto dinamico , sul server di produzione. E, che potrebbe essere implementato tramite commit periodici (ad esempio frequenti lavori cron) o tramite trigger quando viene completato un caricamento FTP.

Il secondo problema è che quando il codice applicazione è commesso da sviluppatori , e successivamente spinto o implementato al server di produzione, il contenuto dinamico può potenzialmente essere sovrascritto. Il repository Git può gestire questo, rifiutando un push che ha un conflitto di contenuto dinamico (poiché il contenuto viene tracciato e richiederebbe allo sviluppatore di tirare / unire / risolvere). In alternativa, le directory del contenuto dinamico possono essere aggiunte al file .gitignore, in modo che uno sviluppatore non impegni mai alcun file di contenuto dinamico.

    
risposta data 09.12.2016 - 19:25
fonte

Leggi altre domande sui tag