implantar o website de controle de versão - exportação e links simbólicos?

Question

Eu sou um solitário desenvolvedor.Temos um casal de sites hospedados em um web host.O repositório do svn é, também, o anfitrião de web.Em casa, nós temos uma máquina de desenvolvimento, que é perto o suficiente a replicação do ambiente ao vivo.

Para o website ao vivo, eu tenho uma exportação do subversion, apropriadamente chamado com o número de versão.No site da raiz do documento, na verdade, é um link simbólico para o diretório.De que maneira, eu possa voltar ou sair para exportados versões com nenhum tempo ocioso da máquina, basta alterar onde o link está apontado.

Quando chega a hora de implementar na realidade, eu vou exportar uma versão do tronco para um subdiretório do website ao vivo, como uma área de transição, e fazer alguns testes.De que maneira eu ver como ele realmente se comporta no ambiente real, sem alterar qualquer coisa que o usuário vê.Em seguida, se tudo parece ok, eu vou fazer outro exportar para a minha conta root e mudar o link simbólico ( e teste novamente!)

Isso é um exagero?Quais são outras maneiras de fazê-lo?

Answer 1

Existe Capistrano, que ajuda você nesse processo. Usando SSH e Keys, torna o processo bastante perfeito para implantar alterações e tal. Embora este seja um aplicativo Ruby, você ainda pode usá -lo para implantar PHP ou outros aplicativos, dê uma olhada Aqui para algumas informações

E este artigo fala sobre isso, usando uma pasta compartilhada junto com sua pasta de liberação. A pasta compartilhada pode conter arquivos de configuração para o seu servidor de implantação individual (URL, conexão de banco de dados, etc.), bem como ativos que são carregados durante a vida de um site e não estão no SVN. Você pode fazer com que o Capistrano lide com isso para você também.

Embora alguém que não saiba que a configuração pode ter um pouco de dificuldade em ver isso, isso realmente facilita a implantação. Eu acho que o que o Capistrano faz é bem simples e provavelmente poderia ser escrito em outro idioma para lidar com seu cenário específico.

E outra idéia de vincular isso ao SVN, ou qualquer repositório. É usar seus ganchos para executar essas implantações. ou seja, todo compromisso com o Trunk atualizará o servidor dev. E uma filial o empurrará para o seu ambiente de estadiamento.

Mas esse link Faz um ótimo trabalho ao mostrar como configurar esse tipo de ambiente. Eu acho que o que você configurou é uma boa prática e não é feito o suficiente. A única coisa que pode ajudá -lo é a implantação automatizada em diferentes ambientes e scripts para ajudar na configuração da sua nova implantação.

Atualizar ::
Além disso, eu gostaria de observar, o SVN pode lidar com os symblinks. Portanto, se você estiver fazendo implantações em servidores baseados em UNIX, poderá apenas colocar os symblinks em seu repositório e usar um symbll em relatório.

Então, se você tiver

./releases/200912231043
./shared/uploads

Você pode colocar seu symblink como

./releases/200912231043/uploads -> ../../shared/uploads

Isso fornecerá uma maneira fácil de gerenciar ativos não no SVN sem usar muitos scripts implantando. Agora você pode apenas usar um compromisso para implantar para o seu desenvolvimento e/ou encenação.

Answer 2

Eu acho que essa é exatamente a maneira correta de fazê-lo.Parece ideal para mim:Atualizações vêm como um totalmente testados versão, as alterações são bem documentável por meio de mensagens de confirmação, rolando de volta (e em diante) é fácil e a opção de uma versão para outra é atômica portanto, não há tempo de inatividade.Eu me esforço para fazer o mesmo com cada projeto.

Qual é a sua pergunta?Você está com dúvidas sobre algo?Não é trabalho para você?Se assim for, de que parte do que exatamente?

Answer 3

É o que estou fazendo nos últimos dois anos para alguns projetos - e nunca tive um único problema com essa maneira de fazer as coisas.

A possibilidade de "reversão" com os symblinks pode ser vista como um pouco exagerado, sim ... mas o dia em que você precisa para salvar o site no qual implantou uma versão com um bug crítico, você realmente gosta de ter essa habilidade!
Eu usei algo como 2 vezes em 3 anos - mas, cada vez, realmente salvou o dia ^^

Uma coisa me parece estranha: se eu entender corretamente, você está testando a nova versão do site no banco de dados Live (Produção)?

Nesse caso, se houver um bug no aplicativo, você poderá destruir seu banco de dados de produção - o que, obviamente, seria ruim.

Eu usaria outro banco de dados para esse ambiente de teste, Personnaly - exatamente como uma medida de segurança.

Além disso: você está fazendo muitos testes, o que é bom ... mas por que não automatizar alguns deles?

Isso permitiria que você testasse mais rápido, com mais frequência, e você gastaria menos tempo testando e mais tempo desenvolvendo ;-)