Devo rendere il mio repository il mio DocumentRoot per il mio sito web?

Question

Ho impostato mercurial sul mio server, ma non sono chiaro come dovrebbero essere le cose. Sto cercando altri esempi di configurazioni diverse, ma forse sto usando le parole chiave sbagliate. Al momento, sarà solo una manciata di sviluppatori, e non sono sicuro se dovrei fare il repository come DocumentRoot. Non so davvero quali domande porre poiché questo è nuovo per me, ma sarei grato se qualcuno potesse fornire qualche conoscenza e guida. Alcune domande che ho adesso sono, come dovrei installare i miei server e repository? Devo impostare un VirtualHost separato per un clone di test prima di farlo live? Qualunque cosa sarebbe utile! Grazie in anticipo!

Answer 1

Probabilmente non c'è un motivo per farlo. Vorrei tenerli separati, ma impostare un processo automatizzato (uno script personalizzato o continuous integration (CI)) per la distribuzione da Mercurial al sito eseguendo un singolo comando. Facoltativamente, puoi fare in modo che ogni commit attivi una distribuzione.

MODIFICA: Con l'integrazione continua, è responsabilità del server CI per l'implementazione. Se si utilizza SSH, l'elemento grafico estrarrebbe da hg, esportare e quindi caricare tramite SSH. Questo dovrebbe risolvere i tuoi problemi. Per un confronto tra i server CI che supportano Mercurial, vedere this question.

Answer 2

Non ho La risposta da dare voi, dal momento che molte variabili e hanno bisogno di influenzare il flusso di lavoro, ma qui è alcuni link per iniziare:

1. http://www.zdnetasia.com/a-development-workflow-for-mercurial-62204755.htm
2. https://www.mercurial-scm.org/wiki/Workflows
3. http://www.webdevelopment.nicholastuck.com/tools/one-project-one-repository-mercurial-used-right/

Vi raccomanderò anche di leggere questa eccellente introduzione Mercurial: http://hginit.com/

È inoltre possibile trovare varie domande su SO sui flussi di lavoro con Mercurial, dare un'occhiata alle barre laterali a destra, ad esempio.

Quando avrai qualche domanda più specifica, non esitare a chiedere ancora!

Answer 3

vorrei rendere la vostra directory DocumentRoot una sottodirectory di primo livello del vostro repository, ed ecco alcuni motivi per cui:

1. Se stai usando qualcosa come Apache per gestire il server, si potrebbe mettere altra meta informazioni - come siti disponibili e file di configurazione abilitati ai siti - in una directory di pari livello, dal momento che non fanno realmente parte dei documenti del sito web.
2. Analogamente, è possibile mantenere una directory "docs" proprio accanto al codice.
3. Se la radice del repository è la tua DocumentRoot, a parità di altre condizioni, stai anche servendo la tua directory .hg, dove è tutta la cronologia del tuo repository, e il tuo file .hgignore, quel genere di cose. È possibile risolvere questo problema con un file .htaccess, ovviamente, ma è più semplice avere solo la cartella figlio.

In sostanza, le codebase tendono a non corrispondere esattamente uno a uno con i siti distribuiti, quindi tendo a preferire che la radice del documento sia una sottodirectory.

La distribuzione è un intero "nuovo tipo di worm".Dipende molto dalle vostre esigenze per ciò che si fa, ma ecco quello che faccio:

ho eseguire un'istanza VirtualBox sul mio computer che sembra il più vicino possibile a ciò che il mio server distribuito sembra, almeno il più vicino come posso ottenere i file di configurazione. Direi che questo approccio è meno soggetto a errori rispetto a una voce VirtualHost aggiuntiva. A seconda del progetto, è possibile ottenere questo risultato fino ad essere identico meno forse alcune voci DNS, quindi posso impostare tutto fino a test.myproject o production.myproject, e questo I sempre automatizza (io uso chef, ma questo è eccessivo per un progetto più piccolo) in modo che sia un codice verificabile e non soggetto a confusione. Non c'è niente di peggio di eseguire test del fumo che cancellano il tuo database - e fai in modo che la configurazione indichi accidentalmente il tuo prodotto db. L'esecuzione di una macchina virtuale consente di testare senza problemi gli aggiornamenti all'ambiente o al sistema operativo del server e, se si desidera passare a uno stato precedente della configurazione della macchina, è possibile eseguire il nuke e il ripristino su un'istantanea.

Se davvero si vuole impedire l'accesso SSH sviluppatore per le vostre macchine prod - e IMO, che è una cattiva idea, perché in caso di problemi sul server di produzione, avete impedito agli sviluppatori di diagnosticare o fissandolo - quindi penso che la cosa migliore da fare sia usare qualcosa come hudson, che è un framework di integrazione continua. Puoi solo accedere ssh all'utente Hudson per eseguire lo script di distribuzione, ma chiunque (con i privilegi corretti impostati in Hudson) può eseguire quel lavoro. In effetti, questo è utile avere in un ambiente in cui hai ad es. alcuni membri della gestione prodotto vogliono avere la possibilità di aggiornare il server di produzione senza essere in grado di accedere. La versione "povera persona" di questo sta usando sudo per consentire agli sviluppatori di eseguire un comando come un altro utente che ha ssh accesso - and only allowing them to run the publish script.

Vorrei ancora consigliare ai tuoi sviluppatori di accedere alla tua macchina, anche se non devi consegnare le chiavi al regno. Crea un gruppo "sviluppatori", assegna i tuoi sviluppatori ad esso e fornisci permessi sufficienti per giocare con le directory necessarie del server, e dovresti essere pronto.