php - sirve - sistema de gestion de contenidos caracteristicas
¿Cómo se manejan las personas que manejan la producción del sistema de gestión de contenido? (3)
Actualmente estoy usando Drupal. Me ha costado mucho encontrar cómo la comunidad resuelve este problema.
Es una de las debilidades 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.
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, pruebas, 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 manejan los problemas de producción de producción del mundo real para un CMS?
Vengo de un contexto en el que presionar para la producción se siente como enviar personas 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.
Después de invertir algunas semanas para superar la curva de aprendizaje de Drupal, la cuestión de "demasiada configuración se almacena 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 solucionar este problema. Están liderando el desarrollo de los módulos Context , Features y Spaces que trabajan en conjunto para almacenar datos de configuración en módulos (fuera del DB) para que puedan ser versionados con el código.
He respondido una question sobre estrategias de implementación de DB.
También hay una question sobre el despliegue del código.
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 usar para las pruebas de los usuarios.
Al final de un sprint (usamos scrum), fusionamos la rama en trunk y ejecutamos pruebas sobre esto.
Luego etiquetamos esto como un lanzamiento y lo implementamos para que funcione (usando Capistrano), finalmente ejecutamos update.php en vivo para aplicar cambios de configuración en vivo.
Cualquier solución de emergencia se implementa desde el enlace troncal a la versión en vivo, como un lanzamiento de punto 7.1, etc.
Si quieres más detalles, por favor deja un comentario.