# data[].attributes.body
Cada aluno deverá explicar para seus colegas de grupo o padrão sob sua responsabilidade.

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.

# data[].attributes.headline
Lista de participantes com Num USP e nome

# data[].attributes.subject
Lista de participantes com Num USP e nome

# data[].attributes.body
Paulo Henrique Vedovatto Turquetti - 13750791

Pedro Guilherme Tolvo - 10492012

Pedro Henrique Salmaze - 13783714

# data[].attributes.body
Canary Release é uma forma de deploy onde a nova versão do software é liberada primeiro para uma pequena parte dos usuários. Se tudo funcionar bem, ela é gradualmente expandida até atingir todos.

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

# data[].attributes.body
Staged Release é uma forma de deploy em que a nova versão do software é liberada gradualmente para grupos crescentes de usuários ou servidores, em várias fases. O processo começa com um subconjunto pequeno e, à medida que a estabilidade é confirmada, a atualização é expandida até atingir toda a base.

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.

# data[].attributes.body
Top 3 situações práticas para aplicar Canary Release, de forma direta:

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.

# data[].attributes.body
O Blue-Green Deployment é uma estratégia de implantação de software que tem como

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

# data[].attributes.body
Downtime do sistema ao implementar novas versões e atualizações

# data[].attributes.body
Alta Disponibilidade: o sistema continua funcionando durante a atualização.

Confiabilidade: rollback rápido se a nova versão apresentar problemas.

Testabilidade: permite testar a nova versão com segurança antes de colocá-la no ar.

Escalabilidade: pode funcionar em ambientes de nuvem onde escalar os ambientes é mais simples.

# data[].attributes.body
Vantagens:

Zero downtime

Rollback rápido

Testes seguros

Desvantagens:

Custo maior (dois ambientes)

Maior complexidade de infraestrutura

Sincronização de dados pode ser difícil

# data[].attributes.body
1. Atualização de aplicativos móveis: Liberar uma nova versão para 5% dos usuários, depois 20%, até chegar a todos.

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

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

# data[].attributes.headline
Possíveis situações onde cada padrão poderia ser útil. 

# data[].attributes.subject
Possíveis situações onde cada padrão poderia ser útil. 

# data[].attributes.body
1- Canary Release:

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.