Como começar a implementação de aplicações PHP a partir de um repositório Subversion?

https://stackoverflow.com/questions/800294

03-07-2019
|

Pergunta

I ouviu a frase "implantação de aplicativos", que soa muito melhor / mais fácil / mais confiável do que upload de arquivos alterados individuais para um servidor, mas não sei por onde começar.

Tenho uma aplicação Zend Framework que está sob controle de versão (em um repositório Subversion). Como faço para ir sobre "implantação" minha aplicação? O que devo fazer se eu tiver um "uploads" diretório que eu não pretende substituir?

I hospedar meu aplicativo através de um terceiro, então eu não sei muito mais do que FTP. Se nada disso envolve o registo no meu servidor, por favor explicar o processo.

Solução

deploy automático + correr de testes para um servidor de teste é conhecido como integração contínua. A idéia é que se você verificar em algo que quebra os testes, você iria ser notificado imediatamente. Para PHP, você pode querer olhar para Xinc ou phpUnderControl

Você seria geralmente não deseja implantar automaticamente para a produção embora. A coisa normal a fazer é escrever alguns scripts que automatiza a tarefa, mas que você ainda precisa iniciar manualmente. Você pode usar estruturas como Phing ou outros acúmulos de ferramentas para isso (Uma escolha popular é Capistrano ), mas você também pode simplesmente bata alguns shell-scripts juntos. Pessoalmente eu prefiro o último.

Os scripts próprios poderiam fazer coisas diferentes, dependendo da sua aplicação e instalação, mas um processo típico seria:

ssh para o servidor de produção. O resto dos comandos são executados no servidor de produção, através de ssh.
executar svn export svn://path/to/repository/tags/RELEASE_VERSION /usr/local/application/releases/TIMESTAMP
Serviços de paragem (Apache, daemons)
executar unlink /usr/local/application/current && ln -s /usr/local/application/releases/TIMESTAMP /usr/local/application/current
executar ln -s /usr/local/application/var /usr/local/application/releases/TIMESTAMP/var
executar /usr/local/application/current/scripts/migrate.php
iniciar os serviços

(Supondo que você tenha a sua aplicação em /usr/local/application/current)

Outras dicas

Eu não recomendaria a atualização automática. Só porque os testes de unidade passar não significa que sua aplicação é 100% de trabalho. E se alguém cheques em um novo recurso aleatória, sem quaisquer novos testes de unidade, e o recurso não funciona? Os testes de unidade existentes podem passar, mas o recurso poderia ser quebrado de qualquer maneira. Os usuários podem ver algo que é feito meio. Com a implantação automática de um check-in, você pode não notar por algumas horas, se algo feito ao vivo que não deveria ter.

De qualquer forma, não seria tão difícil de obter uma implementação automática de ir se você realmente queria. Você precisa de uma pós-check-in gancho, e realmente os passos seriam:

1) Faça uma exportação a partir do último check-in 2) Carregar exportação para servidor de produção 3) Descompacte / config a exportação recém-carregado

Eu sempre realizados os últimos passos manualmente. Geralmente é tão simples como SVN exportação, zip, upload, descompacte, configure, e os dois últimos passos que somente o alias um par de comandos bash em conjunto para executar. Então eu trocar o diretório app raiz com o novo, garantindo que manter o antigo em torno de como uma cópia de segurança, e é bom para ir.

Se você está confiante em sua capacidade de erros de captura antes que iria automaticamente ao vivo, então você pode olhar para automatizar esse procedimento. Isso me dá jibbly-jibblies embora.

Aqui está um excelente artigo sobre o uso do Subversion para implantar projetos web -. Que responde a muitas das suas perguntas

http://athleticsnyc.com/blog/entry/ on-usando-subversão-for-web-projectos

Na minha empresa webdev que recentemente começou a utilizar Webistrano , que é um Web GUI ao Capistrano populares ferramenta.

Queríamos um fácil de usar, rápido ferramenta de implantação com uma interface centralizada, prestação de contas (que implantado qual versão), reversão para versões anteriores e, de preferência livre. Capistrano é bem conhecido como um instrumento de implantação para Ruby em aplicações dos trilhos, mas não centralizada e destina-se essencialmente a aplicações dos trilhos. Webistrano melhora-lo com uma interface gráfica, prestação de contas, e adiciona suporte básico para implantação PHP (use o tipo de projeto 'file pura').

Webistrano é em si um aplicativo Ruby on Rails, que você instala em um desenvolvimento ou servidor intermediário. Você adiciona um projeto para cada um de seus websites. Para cada projeto que você adicionar etapas, tais como Prod e Dev.

Cada estágio pode ter diferentes servidores para implantar a e configurações diferentes. Write (ou modificar) a 'receita', que é um script Ruby que diz Capistrano o que fazer. No nosso caso, eu usei apenas a receita fornecido e acrescentou um comando para criar um link simbólico para a dir uploads compartilhada, assim como você mencionou.

Quando você clica Deploy, Webistrano SSHS em seu servidor remoto (s), faz um svn checkout do código, e quaisquer outras tarefas que requerem tais como migrações de banco de dados, criar um link simbólico ou a limpeza das versões anteriores. Tudo isso pode ser mexido, claro, afinal, ele é simplesmente script.

Estamos muito felizes com ele, mas ele me levou alguns dias para aprender e configurar, especialmente desde que eu não estava familiarizado com Ruby e Rails. Ainda assim, posso altamente recomendável para uso em produção em pequenas e médias empresas, uma vez que está provado muito confiável, flexível e nos salvou muitas vezes o investimento inicial. Não só por acelerar as implantações, mas também reduzindo erros / acidentes.

Este tipo de coisa é o que você chamaria de "Integração Contínua". Atlassian Bamboo (custo), Sun Hudson (gratuito) e Cruise Control (free) são todas as opções populares (em ordem de minha preferência) e tem suporte para a saída PHPUnit pega (porque a produção JUnit suporte PHPUnit).

O material de implantação pode ser feito com um gatilho pós compilação. Como algumas outras pessoas sobre esta discussão, gostaria de ter um grande cuidado antes de fazer implantações automatizadas no check-in (e de passagem de teste).

verificação fredistrano, é um clone Capistrano funciona muito bem (pequena pouco confuso instalação mas depois de tudo corre grande)

http://code.google.com/p/fredistrano/

Para os envios punho, a solução clássica é mover o diretório real fora do webspace principal, deixando-o apenas para uma nova versão a ser verificado (como eu faço no roteiro abaixo) e, em seguida, usando Apache para 'Alias' -lo de volta no lugar como parte do site.

Alias /uploads /home/user/uploads/

Existem menos opções para você, se você não tem tanto controle do servidor no entanto.

Eu tenho um script que eu uso para implantar um determinado script para o dev sites / vivos (ambos executar no mesmo servidor).

#!/bin/sh

REV=2410
REVDIR=$REV.20090602-1027

REPOSITORY=svn+ssh://topbit@svn.example.com/var/svn/website.com/trunk
IMAGES=$REVDIR/php/i
STATIC1=$REVDIR/anothersite.co.uk

svn export --revision $REV  $REPOSITORY $REVDIR

mkdir -p $REVDIR/tmp/templates_c
chown -R username: $REVDIR
chmod -R 777       $REVDIR/tmp $REVDIR/php/cache/
chown -R nobody:   $REVDIR/tmp $REVDIR/php/cache/ $IMAGES
dos2unix $REVDIR/bin/*sh  $REVDIR/bin/*php
chmod 755 $REVDIR/bin/*sh $REVDIR/bin/*php

# chmod -x all the non-directories in images
find $IMAGES -type f -perm -a+x | xargs -r chmod --quiet -x
find $STATIC1 -type f -perm -a+x | xargs -r chmod --quiet -x

ls -l $IMAGES/* | grep -- "-x"

rm dev && ln -s $REVDIR dev

Eu coloquei o número Revison, e data / hora que é usado para o nome do diretório com check-out. O chmod no meio também fazem sre as permissões nas imagens são OK como também são simbolicamente para o nosso servidor de imagem dedicado.

A última coisa que acontece é um link simbólico velho ... / site / dev / é relinked para o diretório recém-check-out. A configuração do Apache, em seguida, tem um doc-root of ... / site / dev / htdocs /

Há também uma correspondência ... / site / live / htdocs / docroot, e novamente, 'ao vivo' é um outro link simbólico. Este é o meu outro script que irá remover o link simbólico ao vivo, e substituí-lo por pontos que quer que dev a.

#!/bin/sh
# remove live, and copy the dir pointed to by dev, to be the live symlink
rm live && cp -d dev live

Eu só estou empurrando uma nova versão do site a cada poucos dats, então você não pode querer estar usando isso várias vezes ao dia (meu cache APC não gostaria mais do que algumas versões do site em torno), mas para mim, eu acho que isso seja muito para a minha própria implementação sem problemas.

Depois de 3 anos, eu aprendi um pouco sobre as melhores práticas de implantação. Eu uso atualmente uma ferramenta chamada Capistrano porque é fácil de configurar e usar, e muito bem lida com um monte de padrões.

Os princípios de um processo de implantação automatizada é assim:

O código está pronto para produção, por isso é marcado com a versão do release: v1.0.0
Assumindo que você já tenha configurado seu script de implantação, você executar o script, especificando a tag que você acabou de criar.

O SSH roteiro é sobre a seu servidor de produção que tem a seguinte estrutura de diretórios:

/your-application
    /shared/
        /logs
        /uploads
    /releases/
        /20120917120000
        /20120918120000  <-- latest release of your app
            /app
            /config
            /public
            ...etc
    /current --> symlink to latest release

Your Apache document root should be set to /your-application/current/public

O script cria um novo diretório no diretório lançamentos com a data e hora atual. Dentro deste diretório, seu código é atualizado para a tag que você especificou.
Em seguida, o link original é removido e um novo link simbólico é criado, apontando para a versão mais recente.

coisas que precisam ser mantidos entre os lançamentos vai no diretório compartilhado, e links simbólicos são criados para os diretórios compartilhados.

Depende do seu aplicativo e como sólidos os testes são.

Onde eu trabalho tudo é verificado para o repositório para revisão e é então liberado.

Auto atualizar a partir de um repositório não seria inteligente para nós, como às vezes nós apenas o check-in para que outros desenvolvedores podem puxar uma versão posterior e mesclar não muda em.

Para fazer o que você está falando seria necessário algum tipo de verificação secundária dentro e para fora para permitir a colaboração entre desenvolvedores na verificação preliminar na área. Embora eu não sei nada sobre isso ou se o seu mesmo possível.

Há também problemas com ramificação e outro como características que precisam ser tratadas.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow