Após as apresentações, o grupo deverá elaborar um quadro comparativo entre os padrões da categoria destacando:

• o problema que ele resolve

• requisitos de arquitetura (ex. atributos de qualidade) que esse padrão foca

• os trade-offs do padrão

Discutir no grupo e fazer um resumo de possíveis situações onde cada padrão poderia ser útil.

Problemas que resolve:

• Reduz riscos de falhas em produção

• Permite identificar bugs e quedas de performance com impacto limitado

• Facilita rollback rápido

• Possibilita testes reais em produção

Requisitos de arquitetura:

• Roteamento de tráfego por versão (ex: load balancer ou service mesh)

• Monitoramento e alertas em tempo real

• Suporte a múltiplas versões rodando simultaneamente

• Automação de deploy e rollback

• Capacidade de segmentar usuários

Trade-offs:

• Aumenta a complexidade da infraestrutura

• Pode gerar inconsistências entre usuários

• Requer monitoramento robusto

• Rollback parcial pode ser mais trabalhoso

• Não substitui testes automatizados

Problemas que resolve:

- Reduz riscos de falhas em produção.

- Permite identificar bugs e quedas de performance com impacto limitado.

- Facilita rollback rápido, pois é possível pausar ou reverter a atualização em qualquer fase.

- Possibilita testes reais em produção, validando a nova versão com usuários reais em diferentes contextos.

Requisitos de arquitetura:

• Confiabilidade: Garante funcionamento correto e consistente, mesmo diante de falhas ou condições inesperadas.

• Disponibilidade: Assegura que o sistema esteja acessível e operacional pelo maior tempo possível, minimizando downtime.

• Resiliência: Capacidade de detectar, isolar e recuperar-se rapidamente de falhas, mantendo o serviço ativo.

Trade-offs:

• Aumenta a complexidade da infraestrutura e dos processos de DevOps.

• Pode gerar inconsistências temporárias entre usuários em diferentes versões.

• Requer monitoramento robusto e coleta de métricas para tomada de decisão entre fases.

• Rollback parcial pode ser mais trabalhoso do que em estratégias de troca total.

• Não substitui a necessidade de testes automatizados e de qualidade.

1. Lançamento de funcionalidade crítica – Ex.: checkout, pagamento, login. Reduz risco de erro para toda a base.

2. Mudanças de performance ou infraestrutura – Testa alterações como novas queries, caches ou serviços sem afetar todos.

3. Migração tecnológica ou integrações externas – Valida novas tecnologias ou APIs de terceiros com um grupo pequeno antes do rollout completo.

objetivo trocar a versão de um sistema sem causar indisponibilidade para os usuários. Ele

funciona mantendo dois ambientes de produção separados, chamados de blue (azul) e

green (verde).

Supondo que o servidor azul contém a versão atual do software, que está sendo acessada

pelos usuários. Quando uma nova versão estiver pronta, abrangendo as atualizações e

novas features desenvolvidas, ela será disponibilizada no servidor verde. Gradualmente, os

usuários vão sendo alocados ao servidor verde, até que o servidor azul esteja em total

desuso.

Caso seja detectado algum problema na nova versão (servidor verde), o servidor azul,

contendo a versão anterior funcional, estará a disposição, fazendo com que seja possível

fazer essa troca de versões sem deixar o serviço indisponível. Por fim, agora que verde

contém a versão atual, as novas atualizações serão feitas no servidor azul, repetindo o

processo

• Zero downtime

• Rollback rápido

• Testes seguros

Desvantagens:

• Custo maior (dois ambientes)

• Maior complexidade de infraestrutura

• Sincronização de dados pode ser difícil

• Lançamento de funcionalidade crítica – Ex.: checkout, pagamento, login. Reduz risco de erro para toda a base.

• Mudanças de performance ou infraestrutura – Testa alterações como novas queries, caches ou serviços sem afetar todos.

• Migração tecnológica ou integrações externas – Valida novas tecnologias ou APIs de terceiros com um grupo pequeno antes do rollout completo.

2- Blue-Green Deployment:

• Padrão ideal para sistemas que exigem alta disponibilidade e segurança na atualização.

• Apesar dos custos e complexidade, é muito usado em ambientes críticos (bancos, e-commerce, etc).

• Ajuda a evitar erros visíveis pelos usuários e garante uma melhor experiência.

3- Staged Release:

• Atualização de aplicativos móveis: Liberar uma nova versão para 5% dos usuários, depois 20%, até chegar a todos.

• Lançamento de funcionalidades críticas: Ativar uma nova função apenas para grupos específicos antes de expandir para toda a base.

• Mudanças em sistemas bancários: Atualizar servidores por etapas para evitar indisponibilidade total em caso de falha.