¿Es aceptable implementar aplicaciones web en producción directamente desde SVN?

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 coo svn switchincluso 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?

Desde mi experiencia, hay ventajas y desventajas:

Pros:

• A veces, hace arreglos urgentes en el servidor de producción, luego puede volver a ingresarlos directamente desde allí. (Aunque en teoría, por razones de seguridad, siempre es una buena idea usar acceso de solo lectura al repositorio desde el servidor de producción).

• Simplicidad: entrega rápidamente, aunque como otros han mencionado aquí, cambiar a un esquema de script de actualización puede ser tan fácil.

Contras:

• Su sistema puede volverse inestable durante sus svn upactualizaciones y las de DB. Para un sitio de alto tráfico, esto significa que algunos usuarios recibirán mensajes de error, páginas rotas o páginas vacías en el mejor de los casos. Bueno, eso es lo que muy a menudo vemos en varios servicios sociales. Sin embargo, un buen servicio lo hace "atómicamente" en el sentido de que pone el sistema en modo de mantenimiento mientras dura una actualización. ( ¡Rompiste reddit! )

• Conflictos: resolver conflictos repentinos en el servidor de producciones es una idea terrible: nuevamente, el servicio se vuelve inestable mientras lo arreglas.

• Archivos no relacionados en el servidor de producción que pueden pertenecerle o no, aunque, por supuesto, puede evitarlo revisando el subárbol correcto en el repositorio.

• Seguridad: alguien que obtuvo acceso a su servidor de producción, legítimamente o no, también obtiene acceso a sus repositorios, posiblemente también a otros productos, y posiblemente también con acceso de escritura. En general, abrir su servidor SVN interno al mundo exterior es una mala idea. Sus repositorios de origen deben estar detrás de un firewall de la empresa, punto.

• De todos modos, habrá scripts de actualización, por ejemplo, para actualizar la estructura de la base de datos, administrar cronjobs, etc., entonces, ¿por qué no tener un script que lo haga todo? - es decir, extrae la última versión preempaquetada, cambia al modo de mantenimiento, actualiza las fuentes, ejecuta scripts específicos de la versión, etc.

Editar: para aquellos que todavía están en el esquema SVN, no olviden esto en su configuración de apache:

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

He configurado un servidor CI en mi trabajo que crea automáticamente nuestro instalador suponiendo que las pruebas unitarias pasen con éxito. Me tomó cerca de un día de trabajo y me ha ahorrado mucho más que eso desde que lo configuré.

Si hay algún proceso manual en la configuración de su sitio web de lanzamiento / instalación / producción, invariablemente se ahorrará tiempo a usted y a la compañía. Esto es apropiado para usted, ya que parece que hay pasos de configuración manual en su proceso de configuración.

Para una referencia, vea al propio Joel hablar sobre cómo un proceso de compilación de un solo clic lo salva a corto y mediano plazo.

Asegúrese de tener los controles de registro adecuados en SVN. Por ejemplo, considere esto:

• Las características se registran para una versión
• El código se implementa en etapas, el control de calidad hace su trabajo
• Los errores se corrigen, otra ronda de pruebas (sin embargo, funciona en su equipo)
• Lo mismo para pre-prod
• Implementar en producción

Si alguien realiza checkins accidentalmente después de la etapa previa a la producción, existe el riesgo de romper algo. Si esto se controla, como no se permiten registros durante la producción previa, excepto para la corrección de errores, no veo ningún riesgo.

Actualización: tiene un problema a la espera de que suceda si no registra sus archivos de configuración. Realmente no puedo ofrecer ningún consejo para esto que no sea "por favor, ¡y rápido!"

Parece correcto siempre que no haya nada fuera del repositorio. De hecho, creo que uno no debería invertir tiempo en herramientas de implementación los primeros meses del proyecto. Porque habrá demasiadas implementaciones, no habrá suficientes clientes para preocuparse por un proceso de lanzamiento formal.

Pero una vez que el proyecto tiene aproximadamente un año, vale la pena considerar invertir en una herramienta de implementación. Razones simples son

• El negocio crece, por lo que planea alojarlo en más de un servidor
• Puede haber errores en un entorno particular y no tiene ningún lugar para replicar el error. No hay una manera fácil de configurarlo sin un proceso tar-untar-forget_about_home_for_a_week.
• Es probable que alguien rompa la construcción. Quien rompió la construcción

Si desea convencerlos, pídales que configuren otro servidor para pruebas internas o QA.