1. O documento discute a ideia de "trocar rótulos" entre ambientes de produção e homologação para permitir a entrega contínua. 2. Isso permitiria que as equipes de desenvolvimento assumissem mais responsabilidades sobre o ambiente e automatizassem processos como implantação e configuração. 3. A abordagem proposta minimizaria gargalos no lançamento de novos recursos e permitiria uma evolução de tecnologia mais rápida e confiável.

1. Green e Blue label
Switching the Labels
/iuri.andreazza
@iuriandreazza

2. ?
E
U
Q
wisky
certo?

3. ?
E
U
Q
wisky
certo?
NO

4. O que seria isto?
Em Produção
Em um modelo agil de desenvolvimento temos:
plan > code > build > test > release > deploy > operate
Quando se homologa um novo release:
o Pacote é validado!
E o ambiente?
GMUD na cara dura não?
Lembrar de tudo que foi feito? (temos que sempre manter
o histórico não?)
Replicar em PRD, ok, mas sempre temos o erro humano
Meio burro isso não?
As aplicações geralmente são parametrizadas, porque não
o ambiente?
Porque não trabalhar com switchs de ambientes?
Em Homologação

5. O que seria isto?
Se alinhado corretamente o que é executado:
Troca de ambientes
Switch de DNS na entrega de novos ambientes.
Switch de Properties (se a aplicação depende de
algo hardcoded).
Build do Jenkings pode controlar o deploy de
Ambiente
Build do Jenkings pode determinar se algo entra
no ar ou não
Automação ao nivel extremo, ou seja, build OK,
deploy
Controle de máquinas, servers e configurações
no nivel da equipe do produto.
Sem dependencia humana na demanda de

6. O que fazer
Processo de homologação sempre
começa após ultimo SWITCH
Deploy do pacote implica em
Homologação do ambiente
Maior agilidade na troca de tecnologias
e ajustes no ambiente final
O que fazer com o banco?
Como o produto deve ver isto?

7. Como aplicar
Configurações devem ser padronizadas
O switch de labels não deve ocorrer como
troca de cuecas!
Temos um tempo de cooldown de ambiente!
Os labels podem ser aplicados a niveis
diferentes das camadas (webcache, apache,
appserver ...)
Padronização em outras camadas (firewall,
proxy, acessos ...)

8. Como utilizar
Com cuidado, ficar virando ambientes
seguidamente pode ser perigoso.
Ajustes imediados ou emergenciais podem
ser relativamente problemáticos em caso de
descuido
O “chaveamento” de ambientes deve ser
automatizado.
Remoção da ideia de INFRA no produto,
todos os DEVs são responsáveis pelo

9. Como esperamos
Trocas ageis de ambiente
Evolução confiável e agil de tecnologias
Produto pode iniciar processo de deploy
continuo
Equipe de produto que assume
responsabilidade pelo ambiente com seus
DEV-OPS
Minimizar gargalo no release
Maximizar features liberados

10. Como o tester ve!
Ambiente que vive trocando para validar
Melhor qualidade, pois quando ocorre a
homologação de pacote é feito em cima
do ambiente final.
Menos stress para ao final executar a
troca.
Um pouco complexo.
Como fica a base de dados????

11. Como o produto ve!
RELEASE!!!
MAIS RELEASES!!!
MUITOS FEATURES LIBERADOS!
MUITA VELOCIDADE! (VUSHHHHHH)
maior agilidade na evolução
redução de gargalos conhecidos
(problema) possivelmente mais
rapidamente entre bugs em produção.

12. Como a infra ve!
Interessante, mas complicado ...
Como assim trocar servidores?
Não to entendendo direito!
Porque ficar virando ambientes??
E a base de dados?
Não é bem assim subir uma maquina nova.
E o FS como fica?
Ao menos temos alguns processos!
DEV-OPS mexer em ambientes!?

13. Algo mais!
Cara, cade o BANCO?
Switch de Schemas ou mesmo
Instancias de Banco
Area de espaço sempre dimensionada
Scripts de Setup de Aplicações
Congelar DB para homologação.
Espelhos meus amigos, ESPELHOS!

14. Como estamos!
Atualmente:
Fase 1: <== Estamos nessa fase!
Servidores separados
Deploy direto em um stack
Configuração do stack versionado
Fase 2:
Desmanchar Homologação
Subir servers ao nivel de PRD
Padronizar Processos (Scripts, mais Scripts e
Processos)
Fase 3:
Padronizar Labels para controle via:
Puppet/Chef/Ventriloquist

15. Estrutura
Usando Labels Por camada
Usando Labels Por Stack (Pense Fase 3)
BL
BL
Cache
Cache
Cache
Apache Apache
Sess.
Man
App Srv App Srv
Banco 1 Banco 2
Cache
Apache Apache
Sess.
Man
Sess.
Man
App Srv App Srv
Banco 1 Banco 2
Sess.
Man

16. Estrutura Sob Demanda (Utópica)
Usando Labels Por camada
Cache 1 Cache 1 Cache 2
{
BL
Cache
N
Apache Apache Apache Apache
1
2
2
N
OS Mirror
Máquinas Novas - Automated
App Srv App Srv App Srv App Srv
1
2
N
1
Applications SWITCH
Banco 1 Banco 2
Banco
N
Será Removido
Novo Node
Current Node

17. Como?
Switch de Aplicações também é possivel
#Criar aplicação A
sh-3.2# ./configure --prefix=/path/aplicacao_node_A
sh-3.2# make; make install;
#Criar aplicação B
sh-3.2# ./configure --prefix=/path/aplicacao_node_B
sh-3.2# make; make install;
#### Activate A
sh-3.2# ln -sfn /path/aplicacao_node_A /path/aplicacao_final
sh-3.2# /path/aplicacao_final/start_script
#### Activate B (Swith Modes)
sh-3.2# /path/aplicacao_final/stop_script
sh-3.2# ln -sfn /path/aplicacao_node_B /path/aplicacao_final
sh-3.2# /path/aplicacao_final/start_script

18. Perguntas???

19. Green e Blue label
Switching the Labels
/iuri.andreazza
@iuriandreazza