implementazione del controllo della versione per lo sviluppo Web

Question

Sto cercando di passare al controllo della versione, poiché i miei progetti si stanno ingrandendo. Attualmente il mio sviluppo più o meno così:

• ho la versione "live" ospitato in linea
• Ho una versione locale, così come un server web locale
• modifico la versione locale e fare dei test su mio webserver locale
• Infine, corro Unison che aggiorna la versione live dalla mia versione locale (così come l'aggiornamento mia versione locale con eventuali modifiche alla versione live)

mio l la piattaforma ocal è Gentoo, Linux. Ho guardato un po 'in SVN, ma penso che potrebbe non essere adatto alle mie esigenze, in quanto il mio server web locale (e Unison) sarebbe solo in grado di accedere al codice attualmente estratto e così via. Potrei sbagliarmi, ma non ne so molto di questo.

Qualcuno potrebbe darmi una mano a configurare una sorta di controllo di versione sul codice esistente, il che renderebbe l'ultima versione accessibile a un server Web locale e che non riduce i tempi di accesso per i file non modificati? (Non voglio Unison caricamento di ogni singolo file ogni volta che faccio un cambiamento)

Answer 1

Io uso sovversione per questo, e funziona bene.

In genere mi allontano, fino a quando non ho pulito qualcosa per un rilascio.

A quel punto creerò un ramo chiamato qualcosa come release-. Salterò sul sistema di produzione e verificherò la mia filiale appena creata.Per diversi progetti, avrò un'area di gestione temporanea che viene eseguita sul sistema di produzione.

Per esempio, potrei avere un albero di directory che assomiglia a questo:

/web/sites/release-1 
/web/sites/release-2 
/web/sites/release-3 
/web/sites/release-4 
/web/sites/stage ==> release-4 
/web/sites/live ==> release-3 

"palcoscenico" e "Live" sono link simbolici, e sono ciò che Apache ha per DocumentRoot per VirtualHosts www.example.com e stage.example.com)

Questa configurazione mi consente di testare le cose con molta attenzione nell'ambiente di produzione reale e quindi di interromperlo scambiando i collegamenti simbolici.

Per diramazioni prima della distribuzione, posso apportare correzioni di emergenza alla produzione nel caso raro che sia necessario. Posso quindi unire queste modifiche al tronco ogni volta che è conveniente e appropriato.

Un ultimo consiglio: se si utilizza copie di lavoro dei progetti di sovversione in un ambiente di produzione, è necessario mantenere apache da permettere alle persone di sfogliare le directory .svn nel progetto:

in httpd.conf:

<Directory ~ "\.svn"> 
    Order allow,deny 
    Deny from all 
</Directory> 

Answer 2

Ecco la mia configurazione attuale, sono sicuro che si possa fare qualcosa di simile:

io uso SVN, che è ospitato sul server principale. Ci sono due server, sviluppo e produzione. Eseguo tutto il mio lavoro di editing su un checkout sul server di sviluppo, quindi quando le modifiche sono pronte per essere pubblicate, li impegno e quindi aggiorno il checkout sul server di produzione, che è il sito live.

Answer 3

Mercurial stile:

> cd ~/code 
> hg init 
> hg add * 
> hg commit -m "Initial checkin" 

che ti porterà un repository Mercurial lavora. Leggi il link per maggiori informazioni su come usarlo.

È possibile clonare dal server Web locale e dal server Web in tempo reale per mantenere le informazioni aggiornate.

Answer 4

Per espandere la risposta di @ Nathon. Volete fare:

cd ~/code # this is where your code lives now 
# set your local webserver to run from *this* directory 
hg init 
hg add * 
hg commit -m "Initial checkin" 
hg clone ~/code ~/staging 
cd ~/staging 
# set Unison to run from *this* directory 

Fate il vostro sviluppo in ~/code, verificandolo con il vostro server locale. Impegnati quando vuoi. Quando ottieni qualcosa che funziona, taggalo. Poi fare:

cd ~/staging 
hg pull 
hg update your-tag-name 
# run unison. 

ho l'impressione che anche voi volete il vostro server locale per eseguire dall'area di gestione temporanea, ma questa sembra una cattiva idea, dal momento che si desidera utilizzare per controllare il vostro lavoro come si va avanti . Se si desidera una sorta di ambiente QA, è possibile eseguire un secondo server Web dalla gestione temporanea, ma lo farei solo in aggiunta a, non in preferenza a, dev.