Qual é o seu fluxo de trabalho de implantação de aplicativo web favorito com SVN?

Question

Atualmente, estamos usando uma configuração de implantação um tanto complicada que envolve um servidor SVN remoto, 3 ramificações SVN para DEV, STAGE e PROD, promovendo código entre eles por meio de patches, etc.Eu me pergunto o que você usa para implantação em uma situação de equipe de desenvolvimento pequena?

Answer 1

trunk para desenvolvimento e um branch (produção) para o material de produção.

Na minha máquina local, tenho um VirtualHost que aponta para o branch trunk, para testar minhas alterações.

Qualquer commit no trunk aciona um gancho de commit que faz uma exportação svn e sincroniza com o URL de desenvolvimento do servidor online - portanto, se o site for stackoverflow.com, esse gancho atualiza automaticamente dev.stackoverflow.com

Então eu uso o svnmerge para mesclar patches selecionados do tronco para a produção em meus checkouts locais.Tenho um VirtualHost novamente na minha máquina local apontando para o branch de produção.

Quando eu confirmo as alterações mescladas no ramo de produção, novamente um gancho de exportação SVN atualiza a exportação de produção (ao vivo) e o site está ativo!

Answer 2

Quando trabalhei em uma pequena equipe de desenvolvimento (pequena significa eu, outro programador e o chefe), era uma bagunça bastante caótica.No entanto, descobrimos que atribuir um tipo de processo "gatekeeper" funcionou para nós.

O gatekeeper foi a pessoa que mais trabalhou no app (neste caso, eu tinha 2 projetos que desenvolvi do zero, ele tinha uns 4).

Basicamente, sempre que ele tinha que trabalhar em meus projetos, ele me notificava de que estava trabalhando, eu me certificava de que o repositório estava atualizado e edificável, então ele descia, fazia suas alterações e então confirmava .Ele me informaria que estava feito, eu iria desmontar, construir e implantar.Se houvesse alterações no banco de dados, tínhamos uma pasta DB Change com todos os scripts que corrigiriam o banco de dados.

Obviamente tem muitos buracos, mas o processo funcionou para nós e nos impediu de construir uns sobre os outros.

Answer 3

Não tive nenhum problema com a organização comum de tags/ramos/troncos.

O desenvolvimento contínuo geral acontece no tronco.

A manutenção de um release em produção acontece na ramificação de lançamento apropriada.

As alterações na ramificação de lançamento que ainda são relevantes para o tronco são mescladas.

Quando uma nova versão está pronta para implantação, ela é marcada no tronco e, em seguida, uma ramificação é criada a partir dessa tag.O novo branch de lançamento é verificado no servidor, paralelamente ao lançamento atual.Quando chega a hora de mudar, os caminhos são manipulados ("mv appdir appdir.old && mv appdir.new appdir").

Os desenvolvedores que apoiam a versão de produção então svn mudam sua cópia de trabalho para o novo branch ou fazem um novo checkout a partir dele.

Answer 4

Três filiais parecem um trabalho extra.

As diferenças ambientais podem ser tratadas tendo diferentes versões dos arquivos relevantes no tronco.ou sejabanco de dados.yml e banco de dados.yml.prod.O processo de implantação deve ter consciência ambiental e simplesmente copiar os arquivos por ambiente em vez dos arquivos padrão.

Answer 5

Uma ramificação tronco simples contém o código mais atual e, em seguida, corta uma ramificação sempre que entrarmos no ar.Isso parece funcionar de forma bastante eficaz.Você pode facilmente ir para a ramificação anterior sempre que a ramificação atual que você cortou para o sistema ativo falhar.Além disso, é fácil corrigir bugs no branch que está ativo no momento, e como o branch efetivamente morre quando você corta um novo, só há um branch real no qual você precisa trabalhar (e então mesclar as correções de lá para o ramo vivo).

Answer 6

Não usamos ramificações para preparar coisas relacionadas à web;apenas para testar coisas experimentais que levarão muito tempo (leia:mais de um dia) para voltar ao tronco.O tronco, no estilo de 'integração contínua', representa um estado atual (esperançosamente) funcional.

Assim, a maioria das alterações são confirmadas diretamente no tronco.Um servidor CruiseControl.NET será atualizado automaticamente em uma máquina que também execute IIS e tenha cópias atualizadas de todos os recursos extras do site disponíveis, para que o site possa ser testado internamente de forma completa e limpa.Após o teste, os arquivos são carregados no servidor público.

Eu não diria que é a abordagem perfeita, mas é simples (e, portanto, adequada para nossa equipe relativamente pequena) e relativamente segura, e funciona muito bem.

Answer 7

Trunk contém a base de código de desenvolvimento "primária" atual.

Muitas vezes, um desenvolvedor cria uma ramificação individual para qualquer projeto de médio a longo prazo que possa atrapalhar a base de código do tronco e atrapalhar os outros desenvolvedores.Quando terminar, ele retornará ao tronco.

Criamos um lançamento marcado sempre que enviamos o código para produção.A pasta em /tags é simplesmente o número da versão.

Para implantar em produção, estamos fazendo uma exportação SVN para teste.Quando isso for satisfatório, usamos um rsync simples para implementar nos clusters de produção.

Answer 8

Eu recomendo fortemente o livro (atualmente em versão preliminar) Entrega Contínua, que descreve um processo completo de gerenciamento de entrega de software, baseado em princípios de integração contínua (entre outros).

Eu não gosto muito da abordagem de ramificação e mesclagem, pois ela pode ficar muito confusa e é um grande desperdício, já que você acaba gastando tempo em atividades que na verdade não agregam nenhum valor novo.Você já desenvolveu, testou e corrigiu seu código uma vez, por que criar uma situação (copiar o código para outra ramificação) que exige que você refaça esse trabalho?

De qualquer forma, a maneira de evitar ramificações e fusões é construir seus artefatos implantáveis ​​a partir do tronco e promover os artefatos construídos (em vez da origem) à medida que eles passam no teste, na preparação, etc.Dessa forma, você tem 100% de certeza de que o que está colocando em produção é o mesmo que testou.

Se você possui recursos diferentes que podem precisar ser lançados em cronogramas diferentes, mudar sua abordagem de implementação (tornar a funcionalidade configurável ou, melhor ainda, modular) pode ajudá-lo a manter um único tronco de desenvolvimento.

Answer 9

Usamos ramificação de lançamento - isso parece ser mais eficiente para nós do que a ramificação de recursos que estávamos fazendo.

Não faça ramificações diferentes para ambientes diferentes.

Answer 10

Eu pessoalmente trabalho localmente (desenvolvimento), adicionando/corrigindo funcionalidades e quando acho que está pronto me comprometo com o trunk (produção).No servidor de produção, acabei de fazer uma atualização do SVN.

Answer 11

Trabalho com uma situação semelhante à que você tem atualmente.Recebi a tarefa de encontrar uma solução “melhor” e ela foi algo como o seguinte.

A ramificação ativa representa os servidores em seu estado atual.

Qualquer trabalho de desenvolvimento deve ser feito em um branch retirado do live.Este pode ser um trabalho de meia hora para uma pessoa ou um projeto multi-equipe de um ano.Sempre que desejar, as mudanças ativas podem ser incorporadas a esses ramos de desenvolvimento.

Antes de um trabalho ser lançado, as alterações do trabalho são mescladas novamente e marcadas como um possível lançamento.Esta versão é testada no ambiente de teste e se passar no teste, o novo live será retirado da tag.

É possível mesclar vários trabalhos em uma única versão, se isso funcionar melhor.

Isso significa que é bastante simples manter os ramos de desenvolvimento atualizados com o live e, se um trabalho em desenvolvimento for abandonado, há um mínimo de organização a ser feita.

Para mudar de trabalho em um projeto para outro, um desenvolvedor pode simplesmente svn mudar seu ambiente de trabalho local para um branch diferente.

Um dos problemas que tivemos com o sistema conforme você descreve é ​​que o DEV pode ficar desatualizado com o PROD rapidamente, então você não está desenvolvendo contra o live e não é fácil detectar dependências cruzadas até o estágio.A solução acima resolve esses problemas, embora permaneça bastante leve.