Ambiente de producción controlado por versión

Mi pregunta es, ¿cómo controlo la versión del entorno de producción de una buena manera?

Este es nuestro entorno actual:

  • (Servidor interno) Desarrollo – Código fuente controlado por la versión
  • (Servidor del cliente) Entorno de testing de aceptación
  • (Servidor del cliente) Entorno de ensayo
  • (Servidor del cliente) Entorno de producción

Cuando lanzamos nuevas funcionalidades para las testings de aceptación, hacemos una publicación en Visual Studio, creamos los cambios y los aplicamos en el server de testing. Allí hacemos una carpeta de respaldo (para que podamos revertir los cambios) y hacemos una carpeta de lanzamiento para que podamos mover estos cambios a etapas cuando se aprueben.

Esto implica mucho trabajo manual al crear carpetas de respaldo, liberar carpetas, recrear la estructura del directory y tratar de rastrear qué funcionalidad entra en cada lanzamiento. Es alegre y siempre hay problemas con algún desarrollador que no sigue el procedimiento de lanzamiento.


En teoría, podría hacer un repository para el entorno de testing. (olvide el código fuente, esto es sobre la aplicación publicada) En cada versión, el desarrollador hace una confirmación y proporciona un comentario sobre la funcionalidad que está lanzando.

Cuando la funcionalidad se debe mover de Prueba a Estadificación, exportamos los cambios realizados desde la última date. Se actualizó el entorno de testing y se copyron en la aplicación de Etapas. Ahí hacemos un compromiso que luego se puede extraer para liberarlo al entorno de producción.

Los inconvenientes de esto es que usar subversion saturará la aplicación con esos directorys .svn. Esto puede solucionarse impidiendo el acceso a esos directorys en IIS o web.config. Otra solución sería usar Git en el directory sobre el directory raíz de la aplicación. Pero es más difícil trabajar con Git para un desarrollador inexperto en un entorno de Windows.

¿Alguien tiene experiencia con este problema? ¿Cómo controlas la versión de tu entorno de producción? ¿Qué pasa si necesita revertir un lanzamiento, tiene una carpeta de respaldo que creó antes del lanzamiento?

Lo he discutido con nuestros desarrolladores y no pueden ver ningún problema con el uso de subversión para el control de versiones y la copy de security del entorno de testing / almacenamiento / producción. Por el contrario, estarían contentos de no crear carpetas de lanzamiento / copy de security cada vez que necesiten liberar nuevas funcionalidades.

Al mismo time, hay algo de insecurity sobre esto. Ninguno ha oído hablar de esto antes, teniendo la aplicación en un sistema de control de versiones y no estamos seguros de cuáles serían los inconvenientes.

Si tiene experiencia en un escenario como este, me gustaría saberlo.

Mikael Lundin

Otra forma de hacer las cosas sería usar un server de compilation. Cada vez que ingresa código, el server de compilation construye y empaqueta la nueva compilation dentro del entorno de desarrollo. Luego verifica en el package desplegable con tu código.

A continuación, puede implementar la compilation empaquetada en los otros entornos. De esta forma, no tiene que hacer una copy de security de las versiones allí porque ya tiene todas las versiones comstackdas en su repository principal. Si se asegura de que la implementación esté completamente automatizada y se pueda hacer con un solo command (¿con PowerShell?), Ya no es necesario mantener copys de security en los serveres.

Esto es realmente mejor y más fácil de mantener que la solución que propone. Debido a que cada versión de la compilation se mantiene junto con el código, siempre puede encontrar un entorno de desarrollo completo para cualquier package de compilation. Si controla la versión de sus serveres por separado y encuentra un error en alguna parte, puede ser difícil encontrar la versión del código que causa el error.

He estado usando mercurial (Hg) como un sistema de control de versiones de producción. (No es el código, sino los binarys realmente implementados). Eso funciona bastante bien. Subversion no es del todo correcto para usar en mi escenario porque quiero poder sincronizar los cambios de producción (como los files de configuration) con las testings y tal vez con el desarrollo. la subversión es más difícil de sincronizar / fusionar entre diferentes repositorys (una gran cantidad de afrontamiento manual). Y con la label hg y la actualización de hg, es muy sencillo volver a una label estable (o inestable).

Ah, y estoy totalmente de acuerdo, deberías usar un server de compilation (cruisecontrol.net) o algo así y mantener todas tus cosas allí también. Mi escenario no es suficiente porque la configuration de un sistema de producción de clientes es, específicamente, personalizada e incluso con testings exhaustivas y lo que no puede haber es una configuration que ya no hace lo mismo entre dos versiones (o la input). los datos han cambiado significativamente)

Usamos la subversión como una forma de implementar cosas en nuestros diferentes serveres (prod, demo, dev, etc.) y no hemos encontrado dificultades. Las únicas cosas a tener en count son las diferencias de bases de datos y las diferencias de files de configuration. Los files de configuration se pueden personalizar para no sobrescribir los files en cada implementación diferente, pero luego no se obtienen las versiones para los cambios en esa plataforma específica.

Con este tipo de sistema, puede utilizar las tags de subversion para actualizar / retrotraer fácilmente a versiones de implementación específicas.

Gracias por sus respuestas y sugerencias.

Veo que tengo que volver a pensar la forma en que manejamos las versiones en estos entornos. Tener un server de compilation con todos los lanzamientos que se hayan realizado podría resolver una parte del problema. Recibiré los comentarios de compromiso sobre el código fuente, y un control mucho mejor de qué característica va dentro de qué compilation. Todavía necesito hacer un seguimiento de qué compilation está en qué entorno para poder revertir un lanzamiento si algo salió mal.

@Jonke voy a echar un vistazo a Mercurial. Tal vez un entorno de producción controlado por la versión sea excesivo si tiene un sistema de compilation en el que cada revisión tiene un código fuente controlado por la versión. Pero aún me gustaría tener una forma rápida de revertir los cambios a una revisión anterior si algo sale mal durante el deployment de la nueva funcionalidad. También me gusta la forma en que obtiene los files de configuration controlados por la versión en el server, ya que el entorno de producción siempre tiene una configuration diferente del entorno de desarrollo.

Tal vez estoy buscando la bala de plata 🙂