melhore nossa estratégia de implantação

Question

Temos um aplicativo de comércio eletrônico que desenvolvemos em nossa empresa. É um aplicativo LAMP razoavelmente padrão que temos desenvolvido dentro e fora por cerca de 3 anos. Desenvolvemos o aplicativo em um domínio de teste, aqui adicionamos novos recursos e corrigimos bugs, etc. Nosso acompanhamento de bugs e desenvolvimento de recursos é gerenciado em uma solução de subversão hospedada (unfuddle.com). Conforme os bugs são relatados, fazemos essas correções no domínio de teste e, em seguida, confirmamos as alterações no svn quando estamos felizes que o bug foi corrigido. Nós seguimos esse mesmo procedimento com a adição de novos recursos.

Vale a pena destacar a arquitetura geral do nosso sistema e aplicativo em nossos servidores. Cada vez que um novo recurso é desenvolvido, nós transferimos essa atualização para todos os sites usando nosso aplicativo (sempre um servidor que controlamos). Cada site que usa nosso sistema usa essencialmente os mesmos arquivos para 95% da base de código. Temos algumas pastas dentro de cada site que contêm arquivos feitos sob medida para esse site - arquivos / imagens css, etc. Além disso, as diferenças entre cada site são definidas por várias configurações dentro de cada banco de dados de sites.

Isso segue para a implantação propriamente dita. Como e quando estamos prontos para lançar uma atualização de algum tipo, executamos um comando no servidor no qual o site de teste está ativo. Isso executa um comando de cópia (cp -fru / testsite / / othersite /) e passa por cada força de vhost atualizando os arquivos com base na data modificada. Cada servidor adicional que hospedamos tem um vhost que rsync a base de código de produção e depois repetir o procedimento de cópia em todos os sites no servidor. Durante esse processo, nós removemos os arquivos que não queremos sobrescritos, movendo-os de volta quando a cópia foi concluída. Nosso script de implementação executa várias outras funções, como a aplicação de comandos SQL para alterar cada banco de dados, adicionando campos / novas tabelas etc.

Nós nos preocupamos cada vez mais com o fato de que nosso processo não é estável o suficiente, não é tolerante a falhas e também é um pouco um método de força bruta. Também estamos cientes de que não estamos fazendo o melhor uso do subversion, pois temos uma posição em que trabalhar em um novo recurso nos impediria de lançar uma correção de bug importante, já que não estamos usando ramificações ou tags. Também parece errado que tenhamos muita replicação de arquivos em nossos servidores. Também não conseguimos executar facilmente uma reversão no que acabamos de lançar. Realizamos um diff antes de cada lançamento, para que possamos obter uma lista de arquivos que serão alterados, para que saibamos o que foi alterado depois, mas o processo de reversão ainda seria problemático. Em termos de banco de dados, comecei a investigar o dbdeploy como uma possível solução. O que realmente queremos é uma orientação geral sobre como podemos melhorar nosso gerenciamento e implantação de arquivos. Idealmente, queremos que o gerenciamento de arquivos esteja mais estreitamente vinculado ao nosso repositório, de modo que um rollout / rollback seja mais conectado ao svn. Algo como usar o comando de exportação para garantir que os arquivos do site sejam os mesmos dos arquivos repo. Também seria bom se a solução pudesse parar a replicação de arquivos em torno de nossos servidores.

Ignorando nossos métodos atuais, seria muito bom ouvir como outras pessoas abordam o mesmo problema.

para resumir ...

• Qual é a melhor maneira de criar arquivos em vários servidores permanecem em sincronia com svn?
• Como devemos evitar arquivo replicação? links simbólicos / algo mais?
• Como devemos estruturar nosso repo para podemos desenvolver novos recursos e corrigir antigos queridos?
• Como devemos desencadear lançamentos / reversões?

Obrigado antecipadamente

EDITAR:

Eu tenho lido muitas coisas boas recentemente sobre o uso de Phing e Capistrano para este tipo de tarefas. Alguém pode dar mais informações sobre eles e como seria bom para esse tipo de tarefa?

    

Answer 1

Meu conselho para fazer lançamentos é ter Versões de recurso e versões de manutenção. Lançamentos de recursos seriam os lançamentos que recebem novos recursos. Estes são adicionados ao seu tronco do subversion. Quando você acha que esses recursos estão completos, você os ramifica em uma ramificação de lançamento. Quando o processo de controle de qualidade estiver satisfeito com essa versão, você codificará a versão e implantará o código em seus servidores.

Agora, quando você recebe um relatório de bug, você envia esta correção para o branch e para o tronco. Quando estiver satisfeito com o número de bugs corrigidos, você pode marcar e implantar uma versão de manutenção.

É importante que você tenha uma ramificação da sua base de código ativo (ou tenha a capacidade de criar uma conhecendo a revisão ativa) separada de sua ramificação de desenvolvimento, para que você possa implantar correções em seu código ativo sem ter que implantar novos recursos ou código não testado.

Eu recomendaria usar o sistema de empacotamento nativo de sua distribuição para implantar novo código. Se você tem um pacote que contém toda a sua base de código, você sabe que todo o seu código foi implementado em uma espécie de operação atômica, você pode ver qual versão está instalada em um relance, pode verificar sua base de código usando checksum. Retroceder é apenas um caso de instalar a versão do pacote anteriormente instalada.

O único roadblock que vejo para você implementando isso é que você parece ter várias cópias da base de código para clientes diferentes em execução em um único servidor. Eu tentaria organizar seu código para que todos os clientes executassem os mesmos arquivos e não usassem cópias. Não sei quão fácil isso seria para você, mas reduzir o número de cópias com as quais você terá de lidar reduzirá enormemente sua dor de cabeça.

Estou assumindo que, como você mencionou o LAMP, você está usando PHP ou outra linguagem de script, que não requer um processo de compilação. Isso significa que você provavelmente está perdendo um processo maravilhoso chamado Integração Contínua. O que isso basicamente significa é que seu código está sendo continuamente testado para garantir que ainda esteja em um estado liberável. Toda vez que alguém verifica um código novo, um processo o pega e executa o processo de criação e teste. Com uma linguagem compilada você normalmente usaria isso para garantir que o código ainda fosse compilado. Com cada idioma, você deve aproveitar a oportunidade para executar testes de unidade (seu código está em unidades testáveis, não é?) E testes de integração. Para sites, uma boa ferramenta para testar testes de integração é o Selenium. Em nossas construções Java, também medimos a cobertura de código e as métricas de código para ver como progredimos com o tempo. O melhor servidor de IC que encontramos para o Java é o Hudson, mas algo como o buildbot pode funcionar melhor em outros idiomas. Você pode criar pacotes usando seu servidor de CI.

    

Answer 2

Começamos a usar o Puppet (principal produto dos Reductive Labs). É uma estrutura baseada em Ruby para automatizar jobs sys-admin. Eu estava no puppetcamp há algumas semanas e aqui estão os links de vídeo:

Apresentação de Lucas Kanies - introdução de marionetes

Além disso, se você quiser ver todas as apresentações feitas no puppetcamp em San Francisco, este é o link:

Apresentações feitas sobre como os outros usavam o Puppet

Aproveite.