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 :)