Como transferir arquivos para produção?

9

Somos um grupo que começou a trabalhar em um site bastante grande com uma base de código existente. Temos um servidor de teste e produção.

Nossa idéia é ter um repositório de teste com vários desenvolvedores com acesso por push; e um repositório abençoado para o qual apenas alguns podem avançar. O repo abençoado deve ser sempre estável e representar a versão de produção mais recente.

Como automatizar o processo de transferência dos arquivos para produção? É ruim ter os arquivos de produção sob controle de versão? Dessa forma, empurrar para o repositório abençoado significaria implantação. Mas, o que acontece quando há conflitos de mesclagem? O servidor de produção será interrompido até que seja resolvido?

Tamás Szelei
fonte

Respostas:

7

Para simplificar:
o processo de envio por si só deve ser totalmente automático. Se você tem algum script personalizado ou simplesmente puxa do repositório "abençoado" para o ambiente de produção. Isso depende de você. Você deve ter apenas algo automatizado, porque os processos automatizados podem ser confiáveis ​​(em vez de fazer upload de arquivos manualmente).

No entanto, o processo de envio deve ser acionado manualmente. Você envia suas atualizações por push e, quando se sentir confiante, identifica-as como candidatas a lançamento e as direciona para seu ambiente de teste (o ideal seria o mais semelhante possível ao seu ambiente de produção). Depois que o RC é testado, o envio pode ser iniciado.
A partir de hoje, nada mais pode lhe dar, o que os testadores humanos podem.

Isso parece um pouco lento, no sentido de que o loop de feedback é relativamente grande. Porém, para testes adequados, é importante tirar um instantâneo fixo, que é examinado por 24 a 48h (ou talvez mais, dependendo do tamanho do projeto). O oposto é um cenário, no qual você encontra muitos bugs logo após pressionar e tenta corrigi-lo com algumas correções rápidas que introduzem novos bugs.
É melhor fazer uma liberação com erros conhecidos (de gravidade aceitável), do que com erros desconhecidos (de gravidade desconhecida).

back2dos
fonte
Portanto, ter um repo no servidor de produção é bom? Quando eu disse automação, quis dizer que, caso não houvesse repositório no servidor de produção (em outras palavras, haveria testes e repositórios abençoados , mas não produção ). Claro, o teste em humanos não pode ser automatizado, não é o que eu estou procurando.
Tamás Szelei
11
@ Tamás: Pode ser bom ter uma verificação local do repo abençoado em seu servidor, se é isso que você quer dizer (apache (ou qualquer outro servidor web decente) facilita tornar os arquivos relacionados ao git inacessíveis do lado de fora). No entanto, você pode facilmente fazer uma "exportação" dele. Não há nenhum ponto em ter arquivos em seu webroot, que não pertencem a ele.
back2dos
Err -... Então, como você saberia exatamente quais são os erros desconhecidos de gravidade desconhecida se eles são ... desconhecidos ?
Spoike
@Spoike Acho que o back2dos está simplesmente defendendo os testes completamente, usando versões fixas que não têm correções "rápidas e sujas" que não foram testadas.
Max
@ Spike: Em 24-48h você pode transformar muitos bugs desconhecidos em bugs conhecidos. Também em 5 minutos, você pode transformar um bug conhecido em muitos erros desconhecidos. Isso é chamado de solução rápida.
back2dos
2

Eu aprendi muito sobre implantação observando como o Capistrano opera. Eu estava trabalhando com o RoR na época, por isso foi uma escolha lógica e, embora nunca tenha conseguido se comportar no projeto em que estava trabalhando, a maneira como ele realiza atualizações automatizadas foi muito útil.

Você pode estar em uma situação em que pode usá-lo diretamente, mesmo - não está necessariamente vinculado ao Rails - mas, se não, o modo como ele se comporta certamente é útil.

glenatron
fonte
1

Dependendo da plataforma que você está usando, existem muitas ferramentas disponíveis que podem fazer sentido para você automatizar versões de produção. Como trabalho em uma loja .NET, estamos usando o NAnt (embora o MSBuild seja uma opção melhor hoje em dia). Java tem Ant, e possivelmente outras coisas. Ruby tem coisas como Rake. Existem plataformas de integração contínua, como TeamCity e Hudson, que também podem ser usadas para gerenciar lançamentos.

Eu nunca vi ou ouvi falar de ter o código prod diretamente em um repositório de controle de origem separado, mas isso certamente poderia funcionar. Como o back2dos disse, a chave é automatizar. Temos nossos scripts de compilação projetados para fazer check-out do controle de origem, compilação e envio ao ambiente de teste para teste. Então, quando gostamos do funcionamento da preparação, os scripts são copiados do controle de qualidade para o Prod.

Minha recomendação é examinar as ferramentas disponíveis, escolher uma e, em seguida, projetar um processo que funcione bem com a ferramenta selecionada. Não tente reinventar demais a roda - este é um problema muito resolvido.

RationalGeek
fonte