Passare al controllo del codice sorgente

La nostra è una società abbastanza piccola (3-4 programmatori e 3-4 progettisti di siti) che sviluppa un'app Web PHP monouso che fornisce le funzionalità a circa 100+ siti Web. Operiamo da un paio d'anni in un ambiente di sviluppo e produzione separato che ha funzionato abbastanza bene. Ci sono sempre state abbastanza funzioni separate da sviluppare che i programmatori non si scontrano mai veramente ed è stato più conveniente lavorare senza il controllo del codice sorgente; anche se aveva il rischio di perdita di dati e abbiamo perso la nostra buona parte di file in una mossa involontaria.

L'altra considerazione è che i nostri progettisti non sono esperti di tecnologia (li ho introdotti al markup html, invece di utilizzare WYSIWYGs). Questo è stato uno dei motivi per esitare a passare al controllo delle versioni.

Tuttavia, ora che abbiamo raggiunto oltre 100 siti e il team di sviluppo sta crescendo, sto cercando di standardizzare le nostre procedure e il controllo del codice sorgente sembra un passo logico per quanto riguarda i programmatori. Spero che questo acceleri anche le nostre implementazioni di patch.

Sfortunatamente, ho un'esperienza molto limitata con l'installazione di un sistema di controllo del codice sorgente. Ciò di cui sono curioso di sapere da persone con una configurazione simile o esperienza nel passaggio:

1) Versioni di tutto (siti, css, modelli html e codice app) e quindi costringere i progettisti a imparare il controllo delle versioni? O sono solo gli sviluppatori che lavorano sul codice dell'applicazione?

2) Quali sono alcune insidie ​​a cui prestare attenzione quando si imposta inizialmente il controllo del codice sorgente?

3) Implementazione di dev => suggerimenti di produzione per il controllo del codice sorgente.

Grazie per tutte le informazioni.

Modifica 1: Dang. Tutti finora raccomandano di controllare tutto. Questo mi farà perdere i capelli presto. Probabilmente susciterà una nuova domanda nel prossimo futuro. Grazie per il consiglio finora, continuate a venire!

Modifica 2: molte buone risposte e esamineremo i vari sistemi di controllo della versione. Grazie per le risposte a tutti!

È utile avere tutto aggiornato, anche per i designer. E se implementato bene con una buona formazione, penso che lo troveranno più utile che oneroso.

Se hai appena iniziato, suggerirei vivamente di utilizzare un sistema di controllo di versione distribuito come git o mercurial . Questa è la tendenza generale nel mondo e ci sono molti vantaggi. È facile lavorare in modalità disconnessa, senza dipendenza dalla rete e la possibilità di fare lavori privati ​​non lucidati ancora sotto il controllo della versione, controllando tutto a livello centrale quando è pronto.

E, non ricorrere ad appelli all'autorità o altro, ma controlla cosa ha da dire Joel Spolsky sull'argomento . (Citazione a scelta: "Subversion = Leeches. Mercurial and Git = Antibiotics.") Tra le altre cose, sottolinea il fatto interessante che questi nuovi sistemi usano un nuovo modello mentale, diverso dal tradizionale controllo di versione - motivo per cui entrare in questo tipo di approccio dall'inizio è una vittoria.

Direi di mettere tutto sotto controllo della versione. Una volta che tutto funziona, puoi copiarlo in un tag che per la maggior parte dei sistemi SCM non richiede molto spazio su disco sul server.

Per quanto riguarda le insidie ​​iniziali, non dovresti preoccuparti molto; eseguire il commit di tutto sul server e, se non è corretto, è possibile mescolarlo in giro ed eliminare le cose extra in un secondo momento. L'unica cosa che non vorrei commettere sono gli artefatti creati dal sorgente, ovvero i file di codice Java appartengono al controllo della versione ma non le classi compilate o interi ISO / DVD dei binari "costruiti dal sorgente".

Lo sviluppo della produzione è facile, in ogni importante traguardo creare un ramo. Il layout della directory nel sistema di controllo della versione di solito assomiglia a:

/ trunk / project / filiali / project / version1 / branch / project / version2 / filiali / project / version3

Supponiamo quindi che trovi un bug nella versione 2 del prodotto, passi a quel ramo, risolvilo e rilasci la versione 2.1. Mentre lavori sulla cartella / trunk / project per la nuova versione 4, dipende da te quali funzioni vengono unite avanti e indietro.

Non lasciatevi ingannare dai bevitori di kool-aid di SCM, ci sono pochissime differenze funzionali tra i popolari sistemi di controllo della versione, vale a dire Subversion e Git. La cosa più importante per il tuo team sarà quanto bene quei server si integreranno con i tuoi strumenti esistenti. Neanche a me piacciono i WYSIWYG ma è sicuramente bello avere eclipse-php o altri IDE compatibili con il server.

Sono uno sviluppatore e ho lavorato in passato come amministratore IT.

Per rispondere a domande specifiche:

1) Sì, versione tutto.

2) Suggerire di impostare un repository di controllo versione fittizio e un progetto fittizio su cui le persone possano imparare.

3) Contrassegnare le versioni che vengono messe in produzione. anche le prove. Quindi puoi sempre controllare una versione specifica che qualcuno sta eseguendo.

Vedo che hai taggato la domanda CVS.

Il mio suggerimento è quello di dare un'occhiata seria alla sovversione, combinata con TortoiseSVN che lo rende molto facile da usare. C'è anche un TortoiseCVS.

Ti suggerisco di eseguire un tutorial interno sul controllo delle versioni. Sarò sorpreso se i tuoi sviluppatori / designer non lo hanno mai visto prima. Tortoise lo rende molto intuitivo.

Può anche essere utile installare una delle interfacce Web in cvs o sovversione.

Il motivo per cui suggerisco la sovversione rispetto a CVS è che, sebbene CVS sia molto valido, presenta alcuni seri problemi di progettazione e implementazione. I biggie per me sono stati: 1) Non è possibile directory di versione 2) La gestione dei file binari non è troppo buona in quanto molte cose sono predefinite come testo. 3) Nessun impegno atomico. 4) Ricordo che spesso facevo casino e lasciavo in giro file di blocco che dovevo rimuovere manualmente dall'archivio codici. Vi era spazio per la corruzione nel fare questo dal momento che i file di blocco sono presenti. 5) Supporto SSL e gestione utenti / password

Subversion risolve sostanzialmente tutti quei problemi, probabilmente molti altri. Ha anche molte funzionalità avanzate come gli esterni (che in realtà uso). Ed è probabilmente per collegare gli utenti / gruppi in active directory che potresti trovare utili. All'epoca utilizzavo CVS che non era disponibile. Potrebbe essere adesso, non ho controllato.

Probabilmente la più grande differenza per svn nell'usarla è che non crei tag. Invece si creano quelle che sembrano essere copie in cui la directory del progetto viene copiata nella cartella Tag e viene assegnato un nome. Dai un'occhiata alla documentazione e capirai cosa intendo. So che sembra strano ma ci si abitua.

Questo sito Web potrebbe essere di qualche beneficio (anche se non posso garantirlo): Configurare un repository svn modulare per i siti Web PHP http://www.howtoforge.com/set-up-a-modular-svn-repository-for -PHP-siti

Con grande rispetto a gran parte della saggezza che appare sopra - ed è saggio - l'implementazione del controllo versione è come l'implementazione dei sistemi di monitoraggio. I miei clienti dicono "cosa devo monitorare" e la risposta ovvia è "monitorare tutto". Ma questa non è una buona notizia: hanno 350 sistemi, ognuno dei quali ha 20-30 variabili di sistema più un gruppo di variabili specifiche per l'uso, e tutti possono essere utilmente monitorati; ma c'è solo uno di me, e vorrebbero vedere dei risultati entro quindici giorni.

Quindi, anche se concordo sul fatto che la best practice consiste nel controllare tutto la versione, se questo non è pratico in primo luogo, iniziare controllando quelle cose la cui mancanza di controllo ti ha causato finora la maggior parte dei problemi .

Se la maggior parte delle interruzioni sono causate dal codice dell'applicazione, iniziare controllandolo; se la maggior parte da patch CSS non pianificate, controllalo; e così via.

Questo non solo ti darà il miglior ritorno per l'investimento nel tempo, ma ti darà a sua volta valide ragioni per estendere in futuro l'uso del controllo della versione: "Poiché abbiamo aggiunto il controllo della versione al codice dell'applicazione, interruzioni non pianificate per 30 minuti sono passati da 11 al mese a 2. Questi due sono stati causati da modifiche HTML statiche, quindi intendiamo controllare le versioni successive ".

Un lancio graduato ti dà anche utenti esperti all'interno dell'organizzazione. Sì, hai dovuto insegnare a tutti e sei gli sviluppatori di app come utilizzare il sistema, ma hanno imparato e non hanno problemi; ora che è il momento di distribuire il sistema al team CSS, hai sei esperti interni in più rispetto a tre mesi fa. A questo punto potresti anche avere dei convertiti; uno sviluppatore a cui è stato salvato il culo dalla capacità di annullare prontamente un cambiamento dannoso potrebbe essere il tuo miglior evangelista del team CSS.

Modifica 1: se decidi di seguire questa strada, un backstop a basso costo è quello di aggiungere un tripwire sopra, almeno su una scatola di produzione. In questo modo, se Things Break ma il VCS dicono che non era nulla di cui attualmente è responsabile, è possibile identificare rapidamente ciò che è cambiato, il che accelera la correzione e suggerisce il prossimo candidato per il controllo della versione.

La versione controlla tutto. Non ha senso avere file HTML sotto il controllo della versione e quindi avere un sito completamente rovinato a causa di un cambiamento nel CSS che non viene controllato e quindi non può essere facilmente annullato.

Insidie: personalmente non me ne sono imbattuto durante il mio uso del controllo della versione abbastanza limitato.

Distribuzione: attualmente uso sovversione ospitata su scatole di Windows, sia al lavoro che a casa. Windows solo perché è ciò che è disponibile. Altrimenti avrebbe potuto essere altrettanto facilmente un altro sistema operativo. La chiave per gli utenti non tecnologici è quella di fornire loro un semplice strumento basato sulla GUI per gestire importazioni, esportazioni, commit, differenze, ecc. Quale strumento utilizzare dipenderà un po 'dal sistema operativo e dal sistema VCS utilizzati.

Usa: Quando sto apportando modifiche al codice, collaudo e commetto spesso. Questo mi permette di tornare indietro per quanto necessario quando sbaglio. Inoltre, confrontando varie revisioni e copiando parti del codice non devo perdere tutte le modifiche solo perché devo tornare a una versione precedente per sistemare alcune cose in un'altra parte del codice.

Vantaggio aggiunto: puoi dare accesso al repository di origine tramite una VPN o una connessione sicura, consentendo agli utenti di lavorare da casa o altrove. ad esempio potrei avere un'idea a casa e modificare il mio codice di lavoro lì e poi, prima di perdere la testa.

Versione tutto.

La distribuzione dipende da quanto è necessario "personalizzare" per ciascuno di questi siti. Se sono identici ad eccezione di uno o due file di configurazione, puoi semplicemente controllare una copia del codice e apportare modifiche minori. Se necessario, eseguire il comando di aggiornamento del controllo versione per ciascuno dei client.

Se vai con il modello di distribuzione "checkout direttamente nel sito del cliente", assicurati che il tuo server escluda l'accesso alle directory di controllo della versione in modo che le persone non possano accedere a http://example.com/. git / e sbirciatina nei tuoi interni. Inoltre, avrei sicuramente un virtualhost di test e produzione per ogni client per assicurarmi che un aggiornamento del sito non vada in tilt. Soprattutto se stai apportando modifiche personalizzate ai file dei singoli clienti, dovrai gestire i conflitti prima che le modifiche diventino attive. In questo caso, verifichi il checkout / l'aggiornamento dell'host virtuale di test e, quando tutto funziona correttamente, copierai l'host virtuale di test sull'host virtuale di produzione.

Tutto ciò che la gente dice su cosa va bene alla versione.

Se decidi di andare con sovversione, posso consigliare di provare lo stack Bitnami Trac; http://bitnami.org/stack/trac

Semplifica l'impostazione di sovversione per te, viene fornito con un sistema di ticketing (che puoi scegliere di utilizzare in questa fase o meno) per tenere traccia di modifiche e bug e un wiki che puoi utilizzare per documentare come vuoi che i tuoi sviluppatori utilizzino il sistema.

Dai a tutti i tuoi sviluppatori Windows TortoiseSVN. Insegna a tutti alcune nozioni di base sulla riga di comando svn.

Alla fine della giornata lo strumento è meno importante della mentalità che è necessario instillare nei propri sviluppatori. Spero che vedranno presto che il controllo della versione è una buona cosa perché impedisce loro di perdere lavoro e consente loro di tornare da vicoli ciechi che non li portano da nessuna parte a stati noti. I benefici superano il (lieve) sovraccarico.