Armazenando conteúdo editável do site?

Temos um site baseado no Django para o qual desejamos tornar parte do conteúdo (texto e lógica de negócios, como planos de preços) facilmente editáveis ​​internamente e, por isso, decidimos armazená-lo fora da base de código. Geralmente, o motivo é um dos seguintes:

• É algo que pessoas não técnicas desejam editar. Um exemplo é o copywriting para um site - os programadores preparam um modelo com texto cujo padrão é "Lorem ipsum ..." e o conteúdo real é inserido posteriormente no banco de dados.

• É algo que queremos mudar rapidamente, sem a necessidade de implantar um novo código (o que atualmente fazemos duas vezes por semana). Um exemplo seria os recursos atualmente disponíveis para os clientes em diferentes níveis de preços. Em vez de codificá-los, nós os lemos do banco de dados.

A solução descrita é flexível, mas há algumas razões pelas quais eu não gosto.

• Como o conteúdo precisa ser lido no banco de dados, há uma sobrecarga de desempenho .

  Atenuamos isso usando um esquema de cache, mas isso também adiciona alguma complexidade ao sistema.

• Os desenvolvedores que executam o código localmente veem o sistema em um estado significativamente diferente em comparação à forma como ele é executado na produção. Testes automatizados também exercitam o sistema em um estado diferente. Situações como testar novos recursos em um servidor de temporariedade também ficam mais complicadas - se o servidor de temporariedade não tiver uma cópia recente do banco de dados, poderá ser inesperadamente diferente da produção.

  Poderíamos atenuar isso comprometendo o novo estado ao repositório ocasionalmente (por exemplo, adicionando migrações de dados), mas parece uma abordagem errada. É isso?

Alguma idéia de como melhor resolver esses problemas? Existe uma abordagem melhor para lidar com o conteúdo que estou ignorando?

Você deve pensar no conteúdo editável como um recurso completo .

• Alguma complexidade adicional é obviamente necessária. Talvez você possa armazenar o recurso estático após a edição para evitar danos ao desempenho.
• O conteúdo é dados, portanto faz parte do estado do sistema. Os desenvolvedores devem lidar com isso, pensando que os usuários podem fazer praticamente tudo o que sua interface do usuário permitir.
• Se os testes automatizados dependem do estado do banco de dados, eles também devem definir o estado do banco de dados (TestDataBuilders, equipamentos ...) antes de executar ou fazer testes de unidade (talvez através de zombaria).

Mas, em vez de tornar o conteúdo editável, você pode tornar esse pessoal técnico parte do seu fluxo de desenvolvimento. Em vez de desenvolver -> implantar -> alterar dados, você pode alterar dados -> desenvolver -> implantar. Talvez você possa emprestar algumas idéias de plataformas de blog estáticas como Octopress .

Essa é uma boa tarefa para seus DevOps. :) Você pode fazer o seguinte:

1. Coloque recursos editáveis ​​em um repositório separado de artefato / VCS (usarei a terminologia Git aqui).
2. Implemente seu processo de construção e implantação para que esses recursos sejam simplesmente retirados desse repositório para separar o local no servidor (você pode estabelecer algumas convenções para diferentes ambientes, para que não seja necessário configurar esse local separadamente para cada um).
3. Quando o usuário altera algo no site, a alteração é simplesmente salva no arquivo de recurso. O envio para o repositório remoto é executado de forma assíncrona em cada alteração.
4. Para implantar quaisquer alterações, o desenvolvedor desabilita a funcionalidade de edição e mescla suas alterações no repositório remoto. Em seguida, na produção, ele obtém os arquivos mesclados do repositório remoto. Depois disso, a funcionalidade de edição pode ser reativada.

É possível automatizar tudo, exceto a fusão com o Chef ou qualquer outra ferramenta, para que esta solução seja confortável para usuários, desenvolvedores e SQA.

Alguma idéia de como melhor resolver esses problemas?

Tivemos a mesma situação. Acabamos usando os seguintes aplicativos Django:

• I18N sabor de páginas planas
• com o editor Redactor WYSIWYG ativado.

Não é perfeito, mas oferece tudo o que você precisa:

• pessoas não técnicas podem editar,
• nenhuma implantação de código é necessária.
• Se você precisar de controle de versão, o aplicativo de reversão fornecerá exatamente isso.

Para que os desenvolvedores experimentem as mesmas páginas do sistema de produção, se esse for um requisito real, exporte da produção para o desenvolvimento e teste usando acessórios.

Existe uma abordagem melhor para lidar com o conteúdo que estou ignorando?

Conceitualmente, acho que você está no caminho certo. Pergunte a si mesmo se você precisa implementar sua própria solução ou se pode conviver com algum tipo de CMS. Flatpages é uma versão muito simples disso. CMS mais sofisticado está disponível.