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

votos
15

No momento, estamos usando uma configuração de implantação um pouco complicado que envolve um servidor remoto SVN, 3 ramos do SVN para o DEV, palco, e PROD, promovendo código entre eles através de patches, etc. Eu me pergunto o que você usa para implantação em uma situação pequena equipe dev ?

Publicado 06/08/2008 em 17:48
fonte usuário
Em outras línguas...                            


11 respostas

votos
15

tronco para o desenvolvimento, e um ramo (produção) para o material de produção.

Na minha máquina local, eu tenho um VirtualHost que aponta para o ramo do tronco, para testar as minhas alterações.

Qualquer comprometer com tronco desencadeia um gancho de cometer que faz uma exportação svn e sincronização para URL dev do servidor online - por isso, se o site é stackoverflow.com então este gancho atualiza automaticamente dev.stackoverflow.com

Então eu uso svnmerge fundir patches selecionados a partir do tronco para a produção em meus checkouts locais. Eu tenho um VirtualHost novamente na minha máquina local apontando para o ramo de produção.

Quando eu confirmar as alterações incorporadas ao ramo de produção, uma vez mais um gancho de exportação SVN atualiza a produção para exportação (live) eo site é viver!

Respondeu 27/08/2008 em 00:45
fonte usuário

votos
3

Eu não tive nenhum problema com a tags / branches / organização comum tronco.

desenvolvimento geral em curso acontece no tronco.

Manutenção de um comunicado na produção acontece no ramo release apropriado.

Alterações para liberar ramo que ainda são relevantes para tronco são mesclados.

Quando uma nova versão está pronto para implantação é marcado a partir do tronco, em seguida, um ramo é criado a partir dessa tag. O novo ramo de lançamento está marcada para o servidor, paralela à versão atual. Quando é hora de mudar, os caminhos são malabarismos ( "mv appdir appdir.old && mv appdir.new appdir").

Os desenvolvedores que suportam a liberação de produção, então svn mudar a sua cópia de trabalho para o novo ramo, ou fazer um novo check-out a partir dele.

Respondeu 04/02/2009 em 15:17
fonte usuário

votos
3

Três ramos apenas soa como o trabalho extra.

diferenças ambientais podem ser manipulados por ter diferentes versões dos arquivos relevantes no tronco. ie database.yml & database.yml.prod. O processo de implantação deve ser ambientalmente consciente e simplesmente copiar os arquivos por meio ambiente durante os default.

Respondeu 07/08/2008 em 22:35
fonte usuário

votos
3

Quando eu trabalhava em uma equipe de desenvolvimento pequeno (small-me o que significa, outro programador e o chefe), era bastante a bagunça caótica. No entanto, descobrimos que Atribuindo um tipo de "gatekeeper" do processo funcionou para nós.

O porteiro foi a pessoa que tinha feito a maior parte do trabalho no aplicativo (neste caso, eu tinha 2 projectos i desenvolvidos a partir do zero, ele tinha como 4).

Basicamente, sempre que ele teve que trabalhar em meus projetos, ele me que ele estava fazendo um trabalho notificar, eu tinha certeza que o repositório foi up-to-date e edificável, então ele iria puxar para baixo, fazer suas mudanças, então comprometer . Ele me informar que ele foi feito, eu iria puxar para baixo, construir e implantar. Se houve mudanças DB tivemos uma pasta Alterar DB com todos os scripts que iria corrigir o DB.

É, obviamente, tem um monte de buracos, mas o processo funcionou para nós, e nos impediu de construir uns sobre os outros.

Respondeu 06/08/2008 em 18:18
fonte usuário

votos
2

Um ramo tronco simples contém o código mais atual, em seguida, cortou um ramo sempre que ir ao vivo. Isso parece funcionar muito eficaz. Você pode facilmente ir para o ramo anterior sempre que o ramo atual que você cortar para o sistema vivo falhar. Além disso, é fácil de corrigir bugs no ramo que está atualmente vivo, e uma vez que o ramo efetivamente morre quando você corta um novo, há sempre apenas uma filial real, você precisa trabalhar (e em seguida, mesclar correções de lá para o ramo vivo).

Respondeu 06/08/2008 em 17:53
fonte usuário

votos
1

Eu recomendo o livro (atualmente em cortes brutos) de Distribuição Contínua , que descreve um processo completo para o gerenciamento de entrega de software, baseada em princípios de integração contínua (entre outros).

Eu não gosto fortemente o ramo e mesclar abordagem, pois ele pode ficar muito confuso, e é muito desperdício, pois você acaba gastando tempo em atividades que realmente não entregar qualquer novo valor. Você já desenvolvido, testado e fixa o código de uma vez, por que criar uma situação (basta copiar o código para outro ramo) que exige que você refazer esse trabalho?

De qualquer forma, o caminho para evitar ramificação e fusão é construir seus artefatos implementáveis ​​do tronco, e promover os artefatos construídos (ao invés de fonte) que passa teste, staging, etc. Desta forma, você está 100% certo de que a coisa que você está colocar em produção é a mesma coisa que você testou.

Se você tem características diferentes, que podem precisar de ser lançado em horários diferentes, mudando a sua abordagem à forma como você implementar (fazer funcionalidade configurável, ou melhor ainda modular) pode ajudar você a manter um único tronco de desenvolvimento.

Respondeu 30/04/2010 em 13:41
fonte usuário

votos
1

Tronco contém a atual base de código de desenvolvimento "primário".

Um desenvolvedor, muitas vezes, criar um ramo individual para qualquer meio de projeto de longo prazo que poderiam mangueira a base de código tronco e ficar no caminho dos outros devs. Quando ele está completa ele vai mesclar volta para o trunk.

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

Para implantar a produção que estamos fazendo um SVN Exportar para Armazenamento temporário. Quando isso é satisfatória usamos um rsync simples para rolar para fora aos clusters de produção.

Respondeu 04/02/2009 em 07:10
fonte usuário

votos
1

Nós não usamos ramos para encenar coisas web-relacionados; apenas para testar as coisas experimentais que levarão um longo tempo (leia-se: mais de um dia) para mesclar volta para o trunk. O tronco, no estilo 'integração contínua', representa um (espero) de trabalho, estado atual.

Assim, a maioria das mudanças começa comprometido direto para o tronco. Um servidor CruiseControl.NET irá atualizar automaticamente em uma máquina que também executa o IIS e tem up-to-date cópias de todos os recursos do site extra, por isso o site pode ser totalmente, de forma limpa testado in-house. Após o teste, os arquivos são enviados para o servidor público.

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

Respondeu 17/08/2008 em 19:52
fonte usuário

votos
0

Eu trabalho com uma situação semelhante ao que você tem atualmente. I foi encarregado de encontrar uma solução 'melhor' e funcionou algo ao longo das linhas do seguinte.

O ramo vivo representa os servidores em seu estado atual.

Qualquer trabalho de desenvolvimento deve ser feito em um ramo que é retirado ao vivo. Este poderia ser um trabalho meia hora uma pessoa ou um projeto equipa multi longo ano. Tão frequentemente quanto é apreciado mudanças para viver pode ser incorporado esses ramos de desenvolvimento.

Antes de uma peça de trabalho vai viver, mudanças de ao vivo são mesclados novamente e ele é marcado como uma liberação potencial. Este comunicado é testado no ambiente de teste e se ele passa no teste o novo ao vivo é retirado do tag.

É possível mesclar várias peças de trabalho em uma liberação se isso funciona melhor.

Isso significa que ele é bastante simples para manter ramos de desenvolvimento até à data com ao vivo e se um trabalho em desenvolvimento é descartado lá é mínima arrumar a fazer.

Para mudar de trabalhar em um projeto para outro desenvolvedor pode simplesmente svn mudar seu ambiente de trabalho local a um ramo diferente.

Um dos problemas que tivemos com o sistema como você descreve é ​​que DEV pode sair do encontro com PROD rapidamente, para que você não está desenvolvendo contra o vivo e não é fácil de detectar dependências cruzadas até o estágio. A solução acima resolve esses problemas, enquanto ainda permanecem bastante leve.

Respondeu 04/02/2009 em 14:01
fonte usuário

votos
0

Eu, pessoalmente, trabalhar localmente (desenvolvimento), acrescentando / fixação características e quando eu acho que ele está pronto Eu me comprometo a tronco (produção). No servidor de produção Eu só faço uma atualização SVN.

Respondeu 04/02/2009 em 12:58
fonte usuário

votos
0

Usamos ramificação release - este parece ser mais eficiente para nós do que o recurso ramificação que estávamos fazendo.

Não faça ramos diferentes para os diferentes ambientes.

Respondeu 27/08/2008 em 00:50
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more