Pregunta
¿Existe una razón legítima para NO usar SVN para implementaciones de producción, o es simplemente un caso de preferencia personal y no existe un caso real contra SVN?
Antecedentes
Mi lugar de trabajo tiene una cultura de etiquetar el lanzamiento en SVN y luego implementar esos lanzamientos directamente en los distintos servidores web utilizando svn co
o svn switch
incluso directamente en producción.
Personalmente tengo un problema con esto, ya que creo que sin usar un script de compilación e implementación o alguna forma o implementación automatizada, pierdes la configuración del entorno de integración ya que no están documentados. Sin embargo, más que eso, tengo el presentimiento de que puede haber un peligro oculto de hacer lo que se ha pasado por alto, algo que todavía tiene que levantar su fea cabeza.
He planteado mis inquietudes con el personal de operaciones que es responsable de implementar el código en nuestros diversos entornos (preparación, producción previa, producción), etc. Sus argumentos fueron más o menos que hasta ahora ha funcionado bastante bien, no hay razón para cambiar.
Editar:
Lo que quiero decir sobre compilar e implementar:
Por ejemplo, si un desarrollador requiere una configuración web.config agregada para un entorno particular. Web.config generalmente no se mantiene en svn y, por lo tanto, estos archivos se actualizan manualmente sin ninguna forma de script de compilación automatizado. Entonces, si se pierden o si OPS se olvida de agregar un campo a web.config para un lanzamiento, entonces tiene problemas.
Un script de compilación que dice que utiliza XMLPoke para generar automáticamente una configuración web.config adecuada para un entorno particular es ideal, ya que tiene un script versionable que documenta todos los cambios necesarios para cada uno de sus entornos.
Método actual de compilación y despliegue
Para el proyecto en cuestión, un desarrollador crea una versión manualmente, otros proyectos tienen el paso de compilación automatizado con NANT o MSBuild, lo cual está bien.
Las migraciones de bases de datos para la mayoría de los proyectos se realizan mediante scripts de base de datos, scripts de migración (Migrator.NET) o paquetes CMS.
Team City generalmente realiza el CI en cada registro, tenemos un proceso de revisión de código para que todos los tickets se realicen en sucursales y luego sean revisados por pares para su validación y corrección / calidad antes de registrarse en el tronco (funciona bien).
Sin embargo, la implementación real del código se realiza casi siempre a través de SVN, ya sea mediante el pago de una versión etiquetada o, más generalmente, un conmutador SVN. Esto es algo que me extraña porque estamos usando nuestro repositorio como parte del proceso de implementación.
La configuración generalmente no cambia muy a menudo, lo único que estará en los archivos de configuración es información específica del entorno. Todo lo demás está en la base de datos.
No me malinterpreten, esto funciona, funciona bien. Sin embargo, quiero intentar impulsar una compilación e implementación automatizada. Lo he usado con Rails y Capistrano, y para proyectos personales con Cygwin, Nant y SSH.
Más importante aún, necesitaría argumentos válidos muy específicos para que mis colegas cambien a usar una compilación e implementación automatizada.
¿O NO hay argumentos válidos reales contra el uso de SVN específicamente para implementar en producción?