Você está lendo a Parte 3 sobre “A Busca pelo deploy contínuo” eu recomendo você a começar pela Parte 1 e depois ler a Parte 2 se você já o fez, continue ;)
Agora um exemplo de arquitetura para facilitar o uso do deploy continuo usando um Load Balancer.
Você não precisa de applicances milionários para fazer isso o github, serve 2500 conexões TCP por SEGUNDO usando o ldirectord em uma máquina Xen com 128mb.
Com um Load Balance, você consegue testar funcionalidades novas no site para uma pequena porção dos usuários do site e usar os gráficos ( que você já tem lógico ) para ver se ela é boa ou não.
Como fazer isso? faça o deploy para apenas 1 das ‘n’ máquinas que você tem atrás do Load Balancer e redirecione, 5% ~ 10% das suas conexões dos seus usuários para essa máquina, o resto os gráficos que você preparou da sua aplicação irão te dizer ;)
Falando um pouco mais de arquitetura, e especificamente de Perl, eu gosto bastante de usar o Nginx + Starman a comunicação é feita via Unix Socket o Starman foi baseado no Unicorn do Ruby, ele funciona muito bem e…
“It’s a unix system I known this!” arquiteturas unix, forks, sockets e afins funcionam muito bem :)
O seu deploy consistiria em copiar os arquivos novos e mandar um sinal de reset para o pid do Starman:
$ kill -s USR2 1337
Ele vai recarregar o código, e vai reiniciar todos os seus fork assim que eles forem ficando sem conexões ou seja para seus usuários a percepção de downtime será ZERO!
Bom, basicamente é isso se tiver alguma duvida pergunte nos comentários :)
Bibliografia
Alguns slides foram copiados dessa palestra da etsy:
Put a Button on It: Removing Barriers to Going Fast View more presentations from OSCON
E outros foram copiados dessa palestra da AOE Media
Continuous deployment View more presentations from Daniel
Obrigado :)