Como manter uma versão demo de um aplicativo?

Preciso demonstrar nosso aplicativo de produção para clientes em potencial. A maneira como eu a configurei hoje é simples. O aplicativo de demonstração é uma duplicata exata do sistema de produção, exceto que os dados no banco de dados são ofuscados para proteger os dados de nossos clientes atuais. Isso funciona muito bem porque não requer nenhuma alteração de aplicativo.

Boss lançou hoje um potencial BOMBSHELL e disse que o sistema de demonstração precisa conter um link especial e que APENAS aparece na demonstração. Ele continuou explicando que, no futuro, pode haver diferenças muito maiores entre os aplicativos de demonstração e de produção (por exemplo, uma área inteira de funcionalidade). O que eu faço agora?

Algumas coisas que pensei em fazer:

• Manter um ramo diferente no subversion específico para o sistema de demonstração
• Crie um pacote de instalação que possua as alterações para demonstração, depois reverta e construa um pacote de instalação de produção
• Modularize o aplicativo (não faço ideia de como)
• Diga: "Dane-se! Eu não farei isso!" (RI MUITO)
• Use algum tipo de lógica condicional no aplicativo para determinar se é um aplicativo de demonstração ou de produção. Por exemplo (se o URL contiver 'demo', mostre mais hide).

Se você ainda não adivinhou, este é um aplicativo da web

De qualquer forma, não tenho experiência nesse cenário sobre qual é o melhor ou se nada disso é bom. Alguém tem uma resposta, estratégia, alguma coisa !?

• Manter um ramo diferente no subversion específico para o sistema de demonstração

  • Sim! Isso ajuda verdadeiramente. Mas tenha cuidado em como você faz isso. O melhor é que, quando o sistema principal evoluir, você deve saber como reduzir suas alterações o mais próximo possível.

• Crie um pacote de instalação que possua as alterações para demonstração, depois reverta e construa um pacote de instalação de produção

  • Isso pode funcionar - mas se você estiver fazendo muitas demos - você perderá sua boa parte da vida nisso.
• Modularize o aplicativo (não faço ideia de como)
  • Esta é a melhor resposta. Ver abaixo.
• Diga: "Dane-se! Eu não farei isso!" (RI MUITO)
  • Definitivamente não! Não porque você deveria ter medo. Mas um bom engenheiro não desiste de desafios.
• Use algum tipo de lógica condicional no aplicativo para determinar se é um aplicativo de demonstração ou de produção. Por exemplo (se o URL contiver 'demo', então mostre mais hide).
  • Definitivamente não! Isso tornaria seu produto muito fraco ao longo do tempo.

Quando você pensa em um produto Demo (a menos que esteja falando de versões de trilha) - não pense como um 'produto separado', mas pense nele como um 'ambiente separado'. Se você e eu instalarmos o mecanismo word-press em nossos respectivos sites, teremos o mesmo produto, mas com dados diferentes. Você deve arquitetar seu produto para que coisas específicas da instalação (e uso) - possam ser criadas, como se cria fontes de conteúdo diferentes. Da mesma forma, por exemplo - você está criando um aplicativo .Net ou JAVA nativo, a funcionalidade permanece a mesma - mas de onde vem os recursos visuais (incluindo telas de apresentação e botões) podem ser pastas diferentes para mostrá-los de forma diferente. Mais tarde - a demanda chegará a alterar os layouts - é quando você sabe que precisa de mais itens de modelo!

Não pule para a modularização de uma só vez. Quando e quando o requisito chegar, comece primeiro um ramo separado (linha de desenvolvimento) e faça a demonstração! (Como todas as demos são normalmente no dia seguinte às 10:30 da manhã). O desvio que você criou agora informa o que modularizado deveria ter sido obtido a partir de recursos externos. Aplique isso e junte-o na próxima vez que a mesma demonstração fosse sua versão padrão (com URL diferente).

Quase sempre, se você acabar criando "produto separado" como demonstração - está convidando problemas, dores ou ambos!

Dipan.

A melhor abordagem seria modularizar para que você possa ativar ou desativar itens em qualquer aplicativo.

Sua demonstração é uma instalação de produto, com uma configuração que ativa coisas diferentes do aplicativo de produto real e aponta para um banco de dados diferente.