Domanda
C'è una ragione legittima NOT per usare SVN per i deployment di produzione, o si tratta semplicemente di un caso di preferenza personale e non esiste un vero caso contro SVN?
Sfondo
Il mio ambiente di lavoro ha una cultura di rilascio dei tag in SVN e quindi la distribuzione di tali versioni direttamente sui vari server Web utilizzando svn co o svn switch incluso direttamente alla produzione.
Personalmente ho un problema con questo perché credo che senza l'utilizzo di script di compilazione e distribuzione o di qualche modulo o distribuzione automatizzata si perdano le impostazioni dell'ambiente di integrazione in quanto non documentate. Tuttavia, più di questo ho la sensazione che ci possa essere un pericolo nascosto nel fare ciò che è stato trascurato, qualcosa che non ha ancora alzato la sua brutta testa.
Ho sollevato le mie preoccupazioni con lo staff operativo che è responsabile della distribuzione del codice nei vari ambienti (staging, pre-produzione, produzione ecc.). Le loro argomentazioni erano piuttosto che ha funzionato abbastanza bene finora, senza motivo cambiare.
Modifica
Cosa intendo per compilazione e distribuzione:
Ad esempio, se uno sviluppatore richiede un'impostazione web.config aggiunta per un particolare ambiente. Web.config in genere non viene mantenuto in svn e quindi questi file vengono aggiornati manualmente senza alcuna forma di script di build automatico. Quindi se sono persi o OPS dimentica di aggiungere un campo a web.config per un rilascio, allora hai dei problemi.
Uno script di build che dice utilizza XMLPoke per generare automaticamente un web.config appropriato per un particolare ambiente è l'ideale in quanto disponi di uno script versionable che documenta tutte le modifiche necessarie per ciascuno dei tuoi ambienti.
Metodo di generazione e distribuzione corrente
Per il progetto in questione uno sviluppatore crea una versione manualmente, altri progetti hanno la fase di creazione automatizzata con NANT o MSBuild, che è OK.
Le migrazioni dei database per la maggior parte dei progetti avvengono tramite script DB, o script di migrazione (Migrator.NET) o pacchetti CMS.
Di solito CI viene eseguito da Team City per ogni check-in, abbiamo un processo di revisione del codice che tutti i ticket sono fatti nelle filiali e poi sottoposti a peer review per validazione e correttezza / qualità prima del check-in (funziona bene).
Tuttavia il deploy effettivo del codice è praticamente sempre tramite SVN, sia tramite un checkout di una release con tag o più in generale uno SVN Switch. Questo è qualcosa che mi sembra strano che stiamo usando il nostro repository come parte del processo di distribuzione.
Generalmente la configurazione non cambia molto spesso, le uniche cose che saranno nei file di configurazione sono informazioni specifiche per l'ambiente. Tutto il resto è nel db.
Non fraintendermi funziona, funziona bene. Comunque voglio provare e spingere per una build e una distribuzione automatizzate. L'ho usato con Rails e Capistrano e per progetti personali con Cygwin, Nant e SSH.
Ancora più importante avrei bisogno di argomenti validi molto specifici per consentire ai miei colleghi di passare all'utilizzo di una build e di una distribuzione automatizzate.
O non ci sono argomenti veri validi contro l'utilizzo specifico di SVN per la distribuzione in produzione?