¿Almacenar contenido editable del sitio?

Tenemos un sitio web basado en Django para el que queríamos que parte del contenido (texto y lógica de negocios, como planes de precios) sea fácilmente editable internamente , por lo que decidimos almacenarlo fuera de la base de código. Por lo general, el motivo es uno de los siguientes:

• Es algo que la gente no técnica quiere editar. Un ejemplo es la redacción de textos publicitarios para un sitio web: los programadores preparan una plantilla con el texto predeterminado "Lorem ipsum ...", y el contenido real se inserta más tarde en la base de datos.

• Es algo que queremos poder cambiar rápidamente, sin la necesidad de implementar un nuevo código (que actualmente hacemos dos veces por semana). Un ejemplo serían las características actualmente disponibles para los clientes en diferentes niveles de precios. En lugar de codificarlos, los leemos de la base de datos.

La solución descrita es flexible, pero hay algunas razones por las que no me gusta.

• Debido a que el contenido debe leerse desde la base de datos, hay una sobrecarga de rendimiento .

  Mitigamos eso mediante el uso de un esquema de almacenamiento en caché, pero esto también agrega cierta complejidad al sistema.

• Los desarrolladores que ejecutan el código localmente ven el sistema en un estado significativamente diferente en comparación con la forma en que se ejecuta en producción. Las pruebas automatizadas también ejercitan el sistema en un estado diferente. Situaciones como probar nuevas características en un servidor de ensayo también se vuelven más complicadas: si el servidor de ensayo no tiene una copia reciente de la base de datos, puede ser inesperadamente diferente de la producción.

  Podríamos mitigar eso comprometiendo ocasionalmente el nuevo estado en el repositorio (por ejemplo, agregando migraciones de datos), pero parece un enfoque incorrecto. ¿Lo es?

¿Alguna idea de la mejor manera de resolver estos problemas? ¿Existe un mejor enfoque para manejar el contenido que estoy pasando por alto?

Debería pensar en el contenido editable como una característica completa .

• Obviamente se necesita cierta complejidad adicional. Tal vez podría almacenar el recurso estático después de la edición para evitar daños en el rendimiento.
• El contenido es información, por lo que es parte del estado del sistema. Los desarrolladores deben lidiar con eso pensando que los usuarios pueden hacer casi todo lo que su interfaz de usuario les permite.
• Si las pruebas automatizadas se basan en el estado de la base de datos, las pruebas también deben establecer el estado de la base de datos (TestDataBuilders, accesorios ...) antes de ejecutarlas, o hacerlas pruebas unitarias (tal vez a través de burlas).

Pero, en lugar de hacer que el contenido sea editable, puede hacer que esa gente técnica forme parte de su flujo de desarrollo. En lugar de desarrollar -> desplegar -> alterar datos, puede modificar los datos -> desarrollar -> desplegar. Tal vez podría tomar prestadas algunas ideas de plataformas de blogs estáticos como Octopress .

Esta es una buena tarea para tus DevOps. :) Puedes hacer lo siguiente:

1. Ponga recursos editables en un repositorio de artefactos / VCS separado (usaré la terminología de Git aquí).
2. Implemente su proceso de compilación e implementación para que estos recursos simplemente se extraigan de ese repositorio a una ubicación separada en el servidor (puede establecer alguna convención para diferentes entornos, por lo que no necesitará configurar esta ubicación por separado para cada uno).
3. Cuando el usuario cambia algo en el sitio web, el cambio simplemente se guarda en el archivo de recursos. La inserción al repositorio remoto se ejecuta de forma asíncrona en cada cambio.
4. Para implementar cualquier cambio, el desarrollador deshabilita la funcionalidad de edición y combina sus cambios en el repositorio remoto. Luego, en producción, extrae los archivos combinados del repositorio remoto. Después de eso, la funcionalidad de edición se puede volver a habilitar.

Es posible automatizar todo excepto la fusión con Chef o cualquier otra herramienta, por lo que esta solución puede ser cómoda tanto para usuarios, desarrolladores y SQA.

¿Alguna idea de la mejor manera de resolver estos problemas?

Tuvimos la misma situación. Terminamos usando las siguientes aplicaciones de Django:

• I18N sabor de páginas planas
• con el editor Redactor WYSIWYG habilitado.

No es perfecto, pero te brinda todo lo que necesitas:

• las personas no técnicas pueden editar,
• No se necesita implementación de código.
• Si necesita control de versiones, la aplicación de reversión le dará exactamente eso.

Para que los desarrolladores experimenten las mismas páginas que en el sistema de producción, si ese es un requisito real, exporte desde la producción hasta el desarrollo y pruebe usando accesorios.

¿Existe un mejor enfoque para manejar el contenido que estoy pasando por alto?

Conceptualmente, creo que estás en el camino correcto. Pregúntese si necesita implementar su propia solución, o si puede vivir con algún tipo de CMS. Flatpages es una versión muy simple de eso. CMS más sofisticados están disponibles.