¿Cómo transferir archivos a producción?

Somos un grupo que comenzó a trabajar en un sitio web bastante grande con una base de código existente. Tenemos una prueba y un servidor de producción.

Nuestra idea es tener un repositorio de prueba con varios desarrolladores que tengan acceso push; y un repositorio bendecido al que solo unos pocos pueden acceder. Se supone que el bendecido repositorio siempre es estable y representa la última versión de producción.

¿Cómo puedo automatizar el proceso de transferencia de archivos a producción? ¿Es malo tener los archivos de producción bajo control de versiones? De esa manera, empujar al repositorio bendito significaría despliegue. Pero, ¿qué sucede cuando hay conflictos de fusión? ¿Se romperá el servidor de producción hasta que se resuelva?

En pocas palabras:
el proceso de inserción en sí mismo debería ser completamente automático. Ya sea que tenga alguna secuencia de comandos personalizada o simplemente extraiga del repositorio "bendito" al entorno de producción. Eso depende de ti. Simplemente debe tener algo automatizado, porque los procesos automatizados pueden hacerse confiables (en lugar de cargar archivos a mano y tal).

Sin embargo, el proceso de inserción debe activarse manualmente. Impulsa sus actualizaciones y, una vez que se siente seguro, lo etiqueta como candidato de lanzamiento y lo lleva a su entorno de prueba (lo ideal sería lo más similar posible a su entorno de producción). Una vez que se prueba el RC, se puede iniciar el empuje.
A partir de hoy, nada más puede darle, lo que pueden hacer los probadores humanos.

Esto suena un poco lento, en el sentido de que el ciclo de retroalimentación es relativamente grande. Pero para una prueba adecuada, es importante tomar una instantánea fija, que luego se examina durante 24-48h (o tal vez más, dependiendo del tamaño del proyecto). Lo opuesto es un escenario, donde encuentras muchos errores justo después de presionar e intentas arreglarlo con algunas soluciones rápidas que introducen nuevos errores.
Es mejor hacer una versión con errores conocidos (de gravedad aceptable), que uno con errores desconocidos (de gravedad desconocida).

Aprendí mucho sobre la implementación al observar cómo opera Capistrano. Estaba trabajando con RoR en ese momento, por lo que fue una elección lógica y aunque nunca logré que se comportara para el proyecto en el que estaba trabajando, la forma en que realiza actualizaciones automáticas fue muy útil.

Puede estar en una situación en la que puede usarlo directamente, incluso, no necesariamente está vinculado a Rails, pero si no, la forma en que se comporta es ciertamente útil.

Dependiendo de la plataforma que esté utilizando, existen muchas herramientas que podrían tener sentido para automatizar los lanzamientos de producción. Yo trabajo en una tienda .NET, así que hemos estado usando NAnt (aunque MSBuild es una mejor opción hoy en día). Java tiene Ant, y posiblemente otras cosas. Ruby tiene cosas como Rake. Luego, hay plataformas de integración continua como TeamCity y Hudson que también se pueden usar para administrar lanzamientos.

Nunca he visto ni oído hablar de tener el código prod directamente en un repositorio de control de fuente separado, pero eso ciertamente podría funcionar. Como dijo back2dos, la clave es automatizar. Tenemos nuestros scripts de compilación diseñados para verificar desde el control de origen, compilar y enviar al entorno de ensayo para pruebas. Luego, cuando nos gusta cómo funciona la puesta en escena, los scripts se copian de QA a Prod.

Mi recomendación es mirar las herramientas disponibles y elegir una, y luego diseñar un proceso que funcione bien con la herramienta seleccionada. No intentes reinventar demasiado la rueda; este es un problema muy resuelto.