¿Cómo manejan la gente el manejo de la producción del sistema de gestión de contenido?

Question

He estado sumergiéndome en las tecnologías de desarrollo web para divertirme (ya debería salir más), y estoy un poco sorprendido por la falta de soporte claro para el montaje de producción (es decir, desarrollo, prueba, rendimiento y entornos de producción)) En realidad, el apoyo no es la palabra; Los sistemas de gestión de contenido parecen trabajar activamente en contra de los esfuerzos para permitir una puesta en escena limpia.

Actualmente estoy usando Drupal. Me ha costado mucho encontrar cómo la comunidad resuelve este problema. La mayoría de las publicaciones que he visto recomiendan reproducir los pasos realizados en el desarrollo del sistema de producción (leer esto acortó mi vida un poco). También escuché cómo los datos de producción vuelven a los desarrolladores para que puedan agregar características incrementales. Este no puede ser el camino a seguir, ¿y si el cliente no quiere que vuelvas a poner tus datos en tu entorno de desarrollo?

Así que, finalmente, mi pregunta:

Cómo están manejando temas de parada de producción del mundo real para un CMS?

Vengo de un entorno en el que empujar a la producción se siente como enviar a la gente a la luna, por lo que es posible que deba relajarse un poco. Sin embargo, todavía estoy interesado en las respuestas que implican el control de la fuente, permiten la reversión de la producción y las pruebas.

Answer 1

He respondido question sobre las estrategias de implementación de la base de datos.

También hay una implementación de código question.

Donde trabajo estamos trabajando en una implementación de Drupal bastante grande. Tenemos aproximadamente la siguiente configuración.

Todos los desarrolladores tienen un sandbox local (Drupal + DB). El código de confirmación de una rama que se comparte entre todos los demás desarrolladores (hay alrededor de 15 de nosotros). Esto incluye los cambios de configuración que realizan las funciones de actualización.

Cuando los desarrolladores hacen un svn up, también ejecutan update.php para realizar cualquier cambio de configuración localmente.

Tenemos un sistema de prueba de sprint que se ejecuta de manera simple y se puede utilizar para las pruebas de los usuarios.

Al final de un sprint (utilizamos scrum), fusionamos la rama en el tronco y ejecutamos pruebas al respecto.

A continuación, etiquetamos esto como un lanzamiento y lo implementamos en vivo (usando Capistrano), finalmente ejecutamos update.php en vivo para aplicar cambios de configuración en vivo.

las correcciones de emergencia se despliegan desde el tronco para vivir como un comunicado de punto 7.1, etc.

Si quieres más detalle a continuación, por favor deje un comentario.

Answer 2

Actualmente estoy usando Drupal. Me ha costado mucho encontrar cómo la comunidad resuelve este problema.

Es uno de los puntos débiles de Drupal; Realmente no trata adecuadamente este asunto. Es particularmente difícil de solucionar porque una gran parte de la configuración de Drupal reside en la base de datos.

Answer 3

Después de invertir unas pocas semanas para superar la curva de aprendizaje de Drupal, la cuestión de que "la configuración es demasiado almacenada en el DB" es muy desconcertante si está creando un sitio de cualquier complejidad.

Eche un vistazo al trabajo que Development Seed está haciendo para evitar este problema. Están liderando el desarrollo de los módulos Context, Features y Spaces que funcionan en conjunto para almacenar datos de configuración en módulos (fuera del DB) para que puedan ser versionados con el código.