È accettabile distribuire app Web per la produzione direttamente da SVN

Domanda

Esiste un motivo legittimo per NON utilizzare SVN per distribuzioni di produzione o si tratta semplicemente di un caso di preferenza personale e non esiste un caso reale contro SVN?

sfondo

Il mio posto di lavoro ha una cultura di etichettatura delle versioni in SVN e quindi dell'implementazione di tali versioni direttamente sui vari server Web utilizzando svn coo svn switchincludendo direttamente nella produzione.

Personalmente ho un problema con questo perché credo che senza usare uno script di compilazione e distribuzione o una forma o una distribuzione automatizzata si perdono le impostazioni dell'ambiente di integrazione perché non sono documentate. Per di più, ho la sensazione che ci possa essere un pericolo nascosto nel fare ciò che è stato trascurato, qualcosa che deve ancora sollevare la sua brutta testa.

Ho sollevato le mie preoccupazioni con il personale delle operazioni che è responsabile della distribuzione del codice nei nostri vari ambienti (messa in scena, pre-produzione, produzione) ecc. I loro argomenti erano praticamente che ha funzionato abbastanza bene finora, nessun motivo per cambiare.

Modificare:

Cosa intendo per build e deploy:

Ad esempio, se uno sviluppatore richiede un'impostazione web.config aggiunta per un determinato ambiente. Web.config non è generalmente tenuto in svn e quindi questi file vengono aggiornati manualmente senza alcuna forma di script di build automatizzato. Quindi, se vengono persi o OPS dimentica di aggiungere un campo a web.config per una versione, allora hai dei problemi.

Uno script di build che utilizza XMLPoke per generare automaticamente un web.config appropriato per un particolare ambiente è l'ideale in quanto si dispone di uno script versionabile che documenta tutte le modifiche necessarie per ciascuno dei propri ambienti.

Metodo di compilazione e distribuzione corrente

Per il progetto in questione uno sviluppatore crea manualmente una versione, altri progetti hanno la fase di compilazione automatizzata con NANT o MSBuild che è OK.

Le migrazioni del database per la maggior parte dei progetti avvengono tramite script DB o script di migrazione (Migrator.NET) o pacchetti CMS.

L'IC è di solito eseguito da Team City in base al check-in, abbiamo una procedura di revisione del codice secondo la quale tutti i biglietti vengono effettuati nelle filiali e quindi sottoposti a peer review per la convalida e la correttezza / qualità prima del check in trunk (funziona bene).

Tuttavia, la distribuzione effettiva del codice è praticamente sempre tramite SVN, sia tramite un checkout di una versione taggata o più in generale uno Switch SVN. Questo è qualcosa di strano per me che stiamo usando il nostro repository come parte del processo di distribuzione.

La configurazione generalmente non cambia molto spesso, le uniche cose che saranno nei file di configurazione sono informazioni specifiche dell'ambiente. Tutto il resto è nel db.

Non fraintendetemi, funziona, funziona bene. Tuttavia, voglio provare a spingere per una generazione e distribuzione automatizzata. L'ho usato con Rails e Capistrano e per progetti personali usando Cygwin, Nant e SSH.

Ancora più importante, avrei bisogno di argomenti validi molto specifici per convincere i miei colleghi a utilizzare una build e una distribuzione automatizzate.

Oppure NON ci sono argomenti validi validi contro l'utilizzo specifico di SVN per la distribuzione in produzione?

Dalla mia esperienza, ci sono sia vantaggi che svantaggi:

Professionisti:

• A volte si eseguono hot fix urgenti sul server di produzione, quindi è possibile ricontrollare direttamente da lì. (Anche se teoricamente, per motivi di sicurezza è sempre una buona idea usare l'accesso in sola lettura al repository dal server di produzione.)

• Semplicità: consegni rapidamente, anche se come altri menzionati qui, passare a uno schema di aggiornamento degli script può essere altrettanto semplice.

Contro:

• Il sistema può diventare instabile durante gli svn upaggiornamenti DB e dell'utente. Per un sito ad alto traffico questo significa che alcuni utenti colpiranno messaggi di errore, pagine spezzate o pagine vuote al massimo. Bene, questo è ciò che vediamo molto spesso su vari servizi sociali. Un buon servizio, tuttavia, lo fa "atomicamente", nel senso che mette il sistema in modalità manutenzione per la durata di un aggiornamento. ( Hai rotto reddit! )

• Conflitti: risolvere conflitti improvvisi sul server di produzione è un'idea terribile: di nuovo, il servizio diventa instabile mentre lo risolvi.

• File non correlati sul server di produzione che potrebbero appartenere o meno a te, anche se ovviamente puoi evitarlo controllando la sottostruttura corretta nel repository.

• Sicurezza: qualcuno che ha ottenuto l'accesso al tuo server di produzione, legittimamente o meno, ottiene anche l'accesso ai tuoi repository, possibilmente anche ad altri prodotti, e forse anche con accesso in scrittura! L'apertura complessiva del server SVN interno al mondo esterno è una cattiva idea. I repository di origine dovrebbero essere protetti da un firewall aziendale, punto.

• Ci saranno comunque degli script di aggiornamento, ad esempio per aggiornare la struttura del DB, gestire cronjobs, ecc. Quindi perché non avere uno script che fa tutto? - ovvero estrae l'ultima versione preconfezionata, passa alla modalità di manutenzione, aggiorna le fonti, esegue script specifici per la versione, ecc.

Modifica: per coloro che sono ancora nello schema SVN, non dimenticarlo nella configurazione di Apache:

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

Ho installato un server CI sul mio lavoro che crea automaticamente il nostro installatore supponendo che i test unitari abbiano successo. Ci è voluto circa un giorno di lavoro e mi ha risparmiato molto di più da quando l'ho installato.

Se esiste un processo manuale nella configurazione del sito Web di rilascio / installazione / produzione, risparmierai invariabilmente te stesso e il tempo dell'azienda. Questo è appropriato per te poiché dalla tua domanda sembra che ci siano passaggi di configurazione manuali nel tuo processo di installazione.

Per un riferimento, vedi Joel stesso che parla di come un processo di creazione di un clic ti consente di risparmiare a breve e medio termine.

Assicurarsi di disporre dei controlli di check-in appropriati su SVN. Ad esempio, considera questo:

• Le funzionalità vengono archiviate per una versione
• Il codice viene distribuito nella gestione temporanea, il QA fa il suo lavoro
• I bug sono stati corretti, un altro giro di test (tuttavia funziona nel tuo team)
• Idem per pre-prod
• Distribuire alla produzione

Se qualcuno fa accidentalmente check-in dopo la fase di pre-prod, c'è il rischio di rompere qualcosa. Se questo è controllato - come in nessun check-in consentito durante il pre-prod ad eccezione delle correzioni di bug - non vedo alcun rischio.

Aggiornamento: hai un problema in attesa che si verifichi se non esegui il check-in dei file di configurazione. Non posso davvero offrire alcun consiglio per questo diverso da "per favore, e veloce!"

Sembra ok fintanto che non c'è nulla al di fuori del repository. Infatti, credo che non si debba investire tempo negli strumenti di implementazione nei primi mesi del progetto. Perché ci saranno troppe distribuzioni, non abbastanza clienti da preoccuparsi di un processo di rilascio formale.

Ma una volta che il progetto ha circa un anno vale la pena considerare di investire nello strumento di implementazione. Le ragioni semplici sono

• Il business cresce quindi prevedi di ospitarlo su più di un server
• Potrebbero esserci dei bug in un ambiente particolare e non hai spazio per replicare il bug. Non esiste un modo semplice per configurarlo senza un processo tar-untar-forget_about_home_for_a_week.
• Qualcuno probabilmente romperà la build. Chi ha rotto la build

Se vuoi convincerli, chiedi loro di configurare un altro server per test interni o QA.