Software magra (webapplication) Engenharia de lançamento

Question

Eu estou olhando para re-organizar a forma como nós liberamos nosso software interno. Todo o código (PHP webapps, alguns aplicativos Java e scripts Perl) é verificada em repositórios Subversion, mas não existem ramos ou tags, tudo é verificado no tronco (apenas cerca de 1-3 devs por app). Nos servidores Linux produção, o software é apenas directamente executado a partir de uma cópia svn de trabalho (na verdade, a maioria das mudanças acontecer lá também).

Uma vez que temos um monte de pequenas aplicações e solte muitas vezes pequenas mudanças para o sistema funcionando, eu estou procurando uma maneira muito magra ou transparente para fazer alguma engenharia de lançamento e limpar esta ABIT confusão.

Existem algumas ferramentas para fora lá que podem me ajudar a fazê-lo em um ambiente heterogêneo (linguagem-wise) assim? Ou tem alguém uma idéia como fazer isso de forma adequada?

Caso contrário, eu tinha pensado em escrever alguns scripts de liberação (shell) que criam automaticamente as etiquetas de subversão do tronco e, em seguida, fazer uma verificação geral da tag correspondente aos servidores de produção. Mas isso soa hack'ish meio bem para mim.

Obrigado,

Haes.

Answer 1

Integração Contínua é definitivamente o caminho a percorrer - qualquer CI (mesmo arquivos em lote minimalistas) é melhor do que nenhum - mas isso só vai ser tão bom quanto as políticas que você tem no lugar. Desde seus arquivos realmente não acabar como um 'binário' ou 'distribuível', marcando um comunicado podem simplesmente exigem apenas que você marcar o repositório, ou mesmo apenas esconder a algum lugar Subversion número de revisão. A política importante que você precisa é que qualquer liberação pode ser reconstruído sempre que precisar - assim você pode comparar versões atuais e anteriores, ou voltar para uma versão mais antiga, se algo der errado. Não se preocupe com a 'sobrecarga' de criar tags no SVN -. Isso é muito eficiente

roteiro liberação A que faz a subversão sons tag bem. A implementação CI (eu recomendo CruiseControl desde que é ideal para o trabalho heterogêneo, embora heterogeneidade requer um pouco mais a sobrecarga de configuração) é grande, já que você pode chutar automaticamente o processo de fora em um checkin subversão e executar testes automatizados que determinam se é bom suficiente para tag ou não.

Eu definitivamente não auto-deploy para um servidor de liberação. A 'área de teste' (chamemos-lhe 'nightly build', 'teste beta', qualquer que seja) seria melhor. Permita que os usuários bater afastado em que antes de decidir é bom o suficiente para rolar para fora para os servidores de produção. E, desde que você tem a política no lugar de ser capaz de reverter para uma versão anterior, você mitigada a possibilidade de uma má roll-out.

O auto-checkout para servidores de produção é a única parte 'hackish' - um check-out automático, teste, tag, beta deploy é liso o suficiente. Rolando-out à produção não deve ter um botão fácil, porém.

Answer 2

Utilize etiquetas e ramos; torná-lo uma parte do ciclo de desenvolvimento. Quando você atualizar esse ramo "estável-1.0", testei a alteração (s) e marcou-o "release-1.0.5", você simplesmente fazer "svn switch" no servidor para a nova tag. não funcionou, apesar de ter testado isso? Volte, e descobrir o que está errado.

Mas cuidado, ramificação na subversão pode ser uma dor, pelo menos pré versão 1.5. Se você ou seus desenvolvedores não têm experiência com ramos, esperar um pouco de aborrecimento e / ou erros no início. Mas enquanto você cometeu nenhum código deve ser perdida (no pior dos casos, simplesmente difícil de fusão).

Seus desenvolvedores realmente deve aprender a usar ramificação; ele pode ser muito útil para uma variedade de propósitos (não apenas para a engenharia release).

Do não comutar automaticamente código em seus servidores de produção; alguém pode acidentalmente apertou o botão errado. atualizações de produção deve sempre ser feito com cuidado. Scripts para adicionar novas tags é, IMHO, devido desnecessário a simplicidade dele, mas sua milhagem pode variar.

Uma última coisa, não permita que ninguém a ter alterações em seu servidor de produção. Pode causar conflitos, e aqueles tendem a ter tempo para resolver. Para não mencionar, ele destrói a sua capacidade de reproduzir uma determinada versão em diferentes estações de trabalho (funciona bem aqui! Por que não no servidor? Hmm).

Answer 3

Alguns servidores de integração contínua fazer esse tipo de coisa, Hudson , por exemplo, tem integração subversão. Ele pode marcar, teste executar e implantar para você.

Answer 4

i usaria Hudson. além de buscar a partir e marcação no SVN (sblundy ref), pode ser útil no gerenciamento de liberação com o bom plugins . f.ex., você poderia tentar um plugin para "promover" as compilações de implantar a produção, e manter uma lista de ambos os promovido constrói-se e uma mudança / commit log para as várias versões.