como gerenciar efetivamente várias ocorrências de um aplicativo

5

Eu desenvolvi uma aplicação web para um cliente que é ao vivo para seus clientes. Recentemente, o aplicativo foi vendido de forma que é replicado para outros nomes de domínio, de modo que há 4 ou mais instâncias do aplicativo que devo desenvolver e manter.

No momento, cada cópia do aplicativo tem seu próprio repositório SVN e, quando se trata de fazer alterações no aplicativo que afeta todas as instâncias, atualizo uma e depois uso Beyond Compare para mesclar as alterações nas outras cópias. / p>

Seria uma solução melhor usar ramificações svn para manter um sistema principal e mesclar sub-filiais e vice-versa para bugs? Cada aplicativo pode ter alterações feitas que são específicas do cliente, como logotipos, cores, etc.

As Ramificações são a melhor maneira de continuar ou continuar tendo cada uma em seu próprio repositório e usar o BC para mesclar onde necessário?

    
por Gortron 15.12.2010 / 20:09
fonte

3 respostas

4

Isso vai depender dos detalhes, é claro, mas o ideal é que você queira uma base de código-fonte única com extensões para o código específico do cliente. Por exemplo, você pode organizar o código específico do cliente em plug-ins da maneira que um sistema de gerenciamento de conteúdo faria. Ou use um sistema de templates para GUIs customizadas. Eu tentaria evitar a manutenção de 4 conjuntos de código de núcleo, se possível, já que é só pedir problemas. Especialmente se daqui a um ano isso é 10 conjuntos de código à medida que você adiciona clientes.

Como outro exemplo, o maior aplicativo PHP em que trabalho tem uma interface de administrador que permite ao administrador ativar ou desativar recursos específicos. Alguns são projetados apenas para clientes únicos, outros são recursos 'premium' para vários clientes. Mas ainda é tudo uma base de código. Durante o tempo de execução, ele verifica com base em quem está logado e apresenta ao usuário funcionalidade adicional, quando aplicável.

    
por 15.12.2010 / 20:45
fonte
2

A abordagem típica é ter um único núcleo, que pode ser configurado conforme necessário em um módulo separado. Para núcleos simples, você pode se contentar com instruções if baseadas em variáveis no módulo de configuração.

Para núcleos mais avançados, você precisa ser capaz de fornecer código específico ao cliente, sobrepondo-se à funcionalidade padrão. Como exatamente isso acontece (tempo de compilação versus tempo de execução) depende do que é mais conveniente para você.

Mas você precisa desesperadamente consolidar seu código em uma única base de código. Caso contrário, a complexidade sobrecarregará você rapidamente se você conseguir mais clientes.

    
por 15.12.2010 / 21:55
fonte
1

Controle de versão distribuída em que você tem um repositório separado para cada instância e confirma as alterações conforme necessário.

O

link pode ajudar a entender isso.

Estamos em uma situação semelhante e não é algo que o Subversion faz bem. Estamos olhando para o Mercurial como alternativa.

Se essa não for uma opção de curto prazo, você precisará separar cada instância do código principal (que pode ser compartilhado) e do código que não pode. Isso minimiza, pelo menos, o código específico do cliente e diminui a escala do problema.

    
por 15.12.2010 / 20:16
fonte