Vorrei arrivare al punto di considerare l'utilizzo di git per la distribuzione ottima pratica .

I due problemi che hai elencato hanno poco a che fare con l'utilizzo di git per la distribuzione stessa. Sostituisci .git / per il file di configurazione contenente le password del database e hai lo stesso problema. Se ho accesso in lettura alla tua radice web, ho accesso in lettura a tutto ciò che è contenuto in esso. Questo è un problema di protezione avanzata del server che devi discutere con l'amministrazione del sistema.

git offre alcuni vantaggi molto interessanti quando si tratta di sicurezza.

1. Puoi applicare un sistema per la distribuzione in produzione. Configurerei anche un hook post-receive per distribuire automaticamente alla produzione ogni volta che viene effettuato un commit su master . Presumo, ovviamente, un flusso di lavoro simile a git flow.

2. git semplifica estremamente il rollback del codice distribuito in produzione a una versione precedente se viene sollevato un problema di sicurezza. Questo può essere utile per bloccare l'accesso a falle di sicurezza mission-critical che è necessario tempo per risolvere correttamente.

3. Puoi applicare un sistema in cui i tuoi sviluppatori devono firmare i commit che fanno. Questo può aiutare a rintracciare chi ha distribuito cosa in produzione se viene rilevata una falla di sicurezza intenzionale.

Non c'è niente di sbagliato nel distribuire da un repository git, infatti è una pratica abbastanza comune e, come dici tu, molto meno incline agli errori che copiare file su ftp o rsync.

Date le informazioni che hai fornito, prenderei nota dei seguenti punti:

• Non limitarti a inserire l'ultimo master. La produzione dovrebbe essere distribuita da un tag di rilascio. Usa git flow o simile per ottenere un po 'più di processo intorno alla distribuzione del codice e alla creazione dei tag. Poiché i tag sono un riferimento immutabile al tuo codice in un dato momento, è più stabile che puntare a un ramo principale che potrebbe essere aggiornato da un commit errato.

• Per quanto riguarda il servizio di. git directory questo non dovrebbe essere un grosso problema. Basta reindirizzare qualsiasi cosa con prefisso .git a un 404 in .htaccess.

• La tua autenticazione git dovrebbe essere basata su chiave ssh, quindi nessuna password repo deve essere memorizzata sul server.

Evviva per i flussi di lavoro di distribuzione git!

Non sono d'accordo con l'opinione popolare qui. Git è per il controllo della versione, non per la distribuzione / CI.

I metodi che le persone sostengono qui vanno bene per i piccoli progetti, ma in generale, non scalano molto bene.

... il che non vuol dire che non dovresti continuare a fare quello che stai facendo. Tieni solo presente, con il progredire della tua carriera, che i progetti su cui stai lavorando probabilmente supereranno un flusso di lavoro di distribuzione puramente basato su git.

Il principale cambiamento di paradigma è smettere di pensare alla distribuzione di filiali e inizia a pensare alla distribuzione dei risultati della compilazione e all'inserimento delle dipendenze dall'ambiente per disaccoppiare la tua infrastruttura dalla tua strategia di ramificazione.

Ad esempio, per utilizzare il paradigma sopra relativo alla "distribuzione dei file" e al rollback. Se stavi distribuendo file, potresti mantenere più versioni dell'applicazione sul server di produzione e, se devi eseguire il rollback, puoi indirizzare il tuo server web a una versione precedente ricollegando la radice web. Due comandi della shell, microsecondi di inattività, meno spazio per errori rispetto all'utilizzo di git.

Un altro esempio: hai il flusso di lavoro principale standard dev branch> staging branch> master, con un server per ciascuno. Hai delle cose pronte per andare in dev, ma alcune altre cose sullo staging non hanno superato il QA. Quindi è necessario eseguire alcune operazioni orribili: rimuovere i commit errati dallo stage, ridistribuire lo stadio e anche rimuovere o correggere i commit errati nello sviluppo e sperare che lo sviluppo e lo staging non finiscano per non essere sincronizzati.

Invece, cosa succede se si taglia un ramo di rilascio master, si uniscono le cose che sono pronte per entrare in quel ramo di rilascio e si crea il risultato, si avvia un server di test su AWS e si distribuisce il risultato su di esso, si esegue il controllo di qualità e si funziona test su quel server di staging temporaneo, quindi ha inviato lo stesso risultato al cluster di produzione e lo ha distribuito? Quindi disattiva la scatola di staging temporanea che hai attivato, unisci la versione in master e tagga master con un numero di versione.

Ovviamente questi sono esempi estremi. Di solito, non è così pulito, anche se vogliamo che lo sia: probabilmente è necessario eseguire alcuni processi di compilazione nell'ambiente di destinazione perché sono presenti modifiche al database che devono essere eseguite. E se hai mod di database non idempotenti tra le versioni, beh, il rollback non sarà così facile indipendentemente dal metodo che usi, perché dovrai eseguire il rollback del db (in generale, prova a distribuire il database idempotente modifiche, quindi rimuovere i bit di database obsoleti in una versione successiva, dopo essere sicuri che siano fuori dal flusso dell'applicazione).

Ad ogni modo, immagino che quello che sto cercando è che la mia risposta a "Usare git per la distribuzione è una cattiva pratica?" è, in generale, "Sì", nello stesso modo in cui l'uso delle ruote da allenamento è dannoso per la bicicletta. È un miglioramento rispetto a rompere ripetutamente il culo sul cemento, ma si spera che alla fine lo supererai.

Puoi utilizzare l'argomento --separate-git-dir = <git dir> quando chiami git clone. Questo inserirà un collegamento simbolico nella directory .git (simbolico a Git, non penso che sia un collegamento simbolico al tuo sistema operativo), e puoi specificare <git dir> da qualche parte al di fuori della radice del documento.

Un approccio alternativo che ho adottato prima è qualcosa di simile al commento di Terry Chia riguardo agli hook post-ricezione.

Git ha un certo numero di hook che possono essere usati per eseguire tutti i tipi di attività prima / durante / dopo più azioni diverse.

Crea un repository nudo in qualsiasi punto diverso dalla tua cartella web. Il repository nudo può quindi essere utilizzato come remoto per eseguire il push a e un hook post-ricezione può essere attivato per estrarre il nuovo codice in una directory specificata.

Questo approccio ha alcuni vantaggi: la posizione di distribuzione funge da strada "a senso unico" in cui il codice deve passare attraverso il controllo del codice sorgente per finire in produzione. È possibile distribuire diversi rami / versioni in posizioni diverse (tutti dallo stesso repository nudo). Fornisce anche un bel modo semplice per eseguire il rollback utilizzando git checkout standard.Tuttavia, un avvertimento / conseguenza di ciò è che le modifiche al codice sul server non si rifletteranno in git (i repository spogli non hanno directory funzionanti), quindi avresti per eseguire manualmente git --work-tree = / path / to / code status per vedere eventuali modifiche (ma non dovresti comunque cambiare il codice di produzione, giusto?)

Concordo con Terry Chia sul fatto che sia un'ottima pratica. Assicura:

• che la revisione in atto sia quella giusta,
• con tutti i file necessari e controlla la completezza della versione,
• rendere la procedura di distribuzione rapida e semplice

Ma, devo aggiungere che ci sono avvertenze che mi sento di condividere.

Di solito, in un repository git metti:

• codice,
• docs,
• unit test,
• script di distribuzione,
• strumenti di integrazione,
• .deb archivi,
• patch sql
• o cose del genere, e forse un mucchio di altre cose

Bene, in produzione vuoi solo il codice!

Perché documenti, unit test, strumenti o archivi .deb potrebbero occupare molto spazio su disco e non hanno nulla a che fare in produzione .

Con Subversion (prima della versione 1.7) potevi controllare solo la directory src / e hai tutti i vantaggi, ma con Subversion> 1.7 e con Git non puoi farlo.

Un'alternativa sarebbe usare i sottomoduli git per realizzare quel tipo di architettura: repository del progetto | - doc | - src -> sottomodulo al repository project-src. \ tests Ma allora il tuo progetto / test e il codice project-src non sarebbero sincronizzati e questo farebbe davvero schifo.

La soluzione sarebbe quindi usare "sparse checkout", vedi: https://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository

Quindi puoi usare git , ma fai attenzione a questi inconvenienti.

Ecco lo script che uso per fare in modo che git venga inviato a prod.

https://gist.github.com/Zamicol/f160d05dd22c9eb25031

Si presume che qualsiasi cosa inviata al ramo master sia pronta per la produzione. Tutti gli altri rami spinti vengono ignorati. Puoi modificare questo hook script in base alle tue esigenze.

Per quanto riguarda le tue preoccupazioni, metto la mia directory git in / var / git ei miei file di produzione da qualche altra parte (come / var / www) e limito l'accesso a queste directory.

Potresti anche avere il tuo repository git su un server separato dal tuo server di produzione e quindi usare qualcosa come scp e ssh nel script sopra per spostare i file dal server git al server di produzione. Ciò ti consentirebbe di utilizzare ancora git per eseguire il push to prod mantenendo il codice separato dalla produzione.