hotspot green and blue label - switching the labels!

Green e Blue labelSwitching the Labels

@iuriandreazza/iuri.andreazza

QUE? wiskycerto?

QUE? wiskycerto?

NO

O que seria isto?

Em Produção

Em Homologação

Em um modelo agil de desenvolvimento temos:plan > code > build > test > release > deploy > operateQuando 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 humanoMeio burro isso não?As aplicações geralmente são parametrizadas, porque não o ambiente?Porque não trabalhar com switchs de ambientes?

O que seria isto?

Se alinhado corretamente o que é executado:Troca de ambientesSwitch 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 AmbienteBuild do Jenkings pode determinar se algo entra no ar ou nãoAutomação ao nivel extremo, ou seja, build OK, deployControle de máquinas, servers e configurações no nivel da equipe do produto.Sem dependencia humana na demanda de upgrade de tech.Controle total do setup de AplicaçõesAgilidade e rapidez no deploy de novas versões.

O que fazerProcesso 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?

Como aplicarConfiguraçõ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 ...)

Como utilizarCom 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

ambiente final.

Como esperamosTrocas 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

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????

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.

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!?

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!

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

Estrutura

App App SrvSrv

Banco Banco 11

ApachApachee

CacheCache

Sess. Sess. ManMan

App App SrvSrv

Banco Banco 22

ApachApachee

CacheCache

Sess. Sess. ManMan

Usando Labels Por camada

App App SrvSrv

Banco Banco 11

ApachApachee

CacheCache

Sess. Sess. ManMan

App App SrvSrv

Banco Banco 22

ApachApachee

CacheCache

Sess. Sess. ManMan

Usando Labels Por Stack (Pense Fase 3)

BLBL BLBL

Cache Cache 11

Estrutura Sob Demanda (Utópica)

App App Srv 1Srv 1

Banco Banco 11

ApachApache 1e 1

Cache Cache 11

App App Srv 2Srv 2

Banco Banco 22

ApachApache 2e 2

Cache Cache 22

Usando Labels Por camada

BLBL

Banco Banco NN

App App Srv NSrv N

ApachApache Ne N

Cache Cache NN

ApachApache 2e 2

App App Srv 1Srv 1

{

Máquinas Novas - Automated

Será RemovidoNovo NodeCurrent Node

OS Mirror

Applications SWITCH

Como?Switch de Aplicações também é possivel

#Criar aplicação Ash-3.2# ./configure --prefix=/path/aplicacao_node_Ash-3.2# make; make install;#Criar aplicação Bsh-3.2# ./configure --prefix=/path/aplicacao_node_Bsh-3.2# make; make install;

#### Activate Ash-3.2# ln -sfn /path/aplicacao_node_A /path/aplicacao_finalsh-3.2# /path/aplicacao_final/start_script

#### Activate B (Swith Modes)sh-3.2# /path/aplicacao_final/stop_scriptsh-3.2# ln -sfn /path/aplicacao_node_B /path/aplicacao_finalsh-3.2# /path/aplicacao_final/start_script

Perguntas???

Green e Blue labelSwitching the Labels

@iuriandreazza/iuri.andreazza