Chaining Git Repos para Desenvolvimento e Produção de Website?

Question

Gostaria de saber se é prático, ou até sensato, colocar cadeias de repositórios juntos. A situação em que estou pensando é onde eu tenho o git repos em um servidor web remoto onde o branch master é aquele que aponta para uma estrutura webroot de desenvolvimento separada que todos os meus desenvolvedores web podem enviar seus arquivos para testes. Depois que tudo for verificado e o site ainda funcionar como esperado no desenvolvimento, um gerente revisará as alterações e usará o git de dentro da estrutura de desenvolvimento para confirmar as alterações em um repositório de produção, no mesmo servidor, tornando as alterações ativas.

O problema que estou tentando resolver é que os desenvolvedores atualmente têm acesso ao site ao vivo e promovem mudanças simples nele. Ocasionalmente, essas alterações interrompem o site, especialmente se as alterações nunca forem testadas. Eu gostaria de forçar tudo para ser canalizado através do ramo de desenvolvimento, forçá-lo a fazer o teste, e só então comprometê-lo com a versão de produção do site. Eu não espero que isso conserte totalmente meu problema, mas estou esperançoso de que isso diminuiria significativamente a quantidade de erros bobos que chegam à produção.

Eu também não quero inserir uma camada extra de complexidade que é desnecessária, assim, minha pergunta sobre se é até sensato fazer isso. Atualmente, todos os desenvolvedores usam o sftp para enviar arquivos, então usar o git pode ser encontrado com alguma resistência, mas eu realmente adoro a idéia de versionar e reverter para estados bons conhecidos se algo passar.

Então estou procurando conselhos sobre como usar o git dessa maneira ou métodos alternativos de como os outros lidam com esse cenário.

    

Answer 1

Como @EEAA mencionou em um comentário, você quase certamente quer um sistema de CI / CD, não uma cadeia de git repos. Eu tenho investigado mais recentemente o go.cd , e ele tem um bom suporte para o tipo de implantações "baseadas em aprovação" que você está descrevendo, via uma interface web, em vez de precisar de pessoas para puxar / empurrar o código.

Eu sou um crente strong (como alguém que faz gerenciamento técnico) na ideia de que um gerente deve confiar em seus devs para não fazer coisas estúpidas, e se os desenvolvedores fizerem coisas estúpidas, o gerente é culpado - ou porque as expectativas apropriadas não foram postas em prática, ou porque as pessoas erradas foram contratadas. Se os desenvolvedores estão forçando o código quebrado ao vivo, o gerente precisa descobrir por que os desenvolvedores estão fazendo isso, e resolver o problema, e não impedir que os desenvolvedores possam enviar o código ao vivo.