(des) vantagens de preparar a dev-> produção usando 'drush rsync' vs 'git'?

9

Eu montei um site Drupal sob controle git para o trabalho de desenvolvimento.

Ele é criado em um mestre, repositório simples do GIT e, à medida que as alterações são feitas nos meus vários clones git do trabalho de projeto e empurrado de volta para o mestre, um gancho pós-atualização envia imediatamente as alterações para um único site de teste ao vivo (http: / /staging.loc.). Nada de especial, funciona como esperado.

Eu também fiz alias do site "@STAGING". Ocasionalmente, quero promover minhas alterações do site Staging para um servidor de produção.

Dois métodos relativamente simples vêm à mente:

(1) No momento em que o site de armazenamento temporário parecer estável, crie o site de produção como um checkout git no repositório mestre,

(2) use drush rsync+ drush sql-syncdo site intermediário para o local de produção.

Ambos podem ser feitos para funcionar. Além do fato de que (2) parece mais centrado no Drupal / consciente por natureza - o drush é, afinal, um conjunto de ferramentas específicas do Drupal - quais são os méritos relativos das duas abordagens?

Existe alguma razão específica para considerar (1) sobre (2)?

Nos dois casos, "Tudo" está sob pelo menos uma instância de controle de revisão ...

drush version-control staging

— Clive
fonte

3

Eu usei as duas técnicas. Ambos podem ser usados para garantir que os mesmos arquivos testados no @stage acabem no @live. A vantagem do rsync é que você não acaba com arquivos extras (por exemplo, ".git" e associados) em seu servidor de produção. Eu costumo rsync para um vps e uso o git em uma caixa que possuo (por exemplo, sites da intranet).

— greg_1_anderson
fonte

Obrigado pelo ponto. Eu estava apenas olhando as opções de exclusão. Isso ajuda a manter as coisas limpas. Ou seja, eu preciso especificar o que excluir "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:',"no arquivo .rc, embora ainda não tenha certeza se preciso disso nos alias dos alias de origem e de destino ou apenas em um ou outro.

O .git deve ser ignorado por padrão. Execute 'drush --simulate rsync [options] @a @b' para ver o comando exato do rsync que o Drush executará. Use --include-vcs se desejar que o drush rsync inclua .git e outros arquivos relacionados ao vcs.

— greg_1_anderson

Eu preciso ler com mais detalhes; Não percebi que o .git foi excluído. Obrigado pela dica simular também. Re: o OP, acho que vou ficar com o 'drush rsync', pois ele é projetado para ser um método de implantação de drupal e obras. git pode trabalhar, claro, mas Ive agora se deparar com comentários suficientes que está notdesigned para implantar ...

1

O problema com o uso do drush rsync é que se você tiver várias pessoas enviando alterações para o servidor.

Seu exemplo mostra apenas uma pessoa pressionando alterações.

Se você tiver o desenvolvedor A pressionando as alterações e depois o desenvolvedor B pressionando as alterações, deseja que o git elimine os conflitos ou faça o desenvolvedor B elimine os conflitos.

— Micheas Herman
fonte

1

Na verdade, eu uso os dois. svn / git e rsync servem a dois propósitos diferentes. O svn / git é para controle de origem rsynce sql-syncpara sincronização de teste e prod de maneira eficiente. drush rsync @staging @prodé muito difícil de superar em termos de simplicidade e é terrivelmente fácil de integrar na maioria dos continuous Integrationambientes, caso você queira mergulhar ainda mais profundamente nas loucuras / metodologias de qualidade de código.

— stefgosselin
fonte

1

Pessoalmente, uso o Git para controle de versão, implantação e sincronização de várias bases de código do servidor e, em seguida, rsync para mover / sincronizar os arquivos dos usuários (ignorados pela adição de certos caminhos ao arquivo .gitignore).

— danbohea
fonte