# data[].attributes.body
O Canary Release é uma estratégia de deploy gradual em que uma nova versão do sistema é liberada primeiro para uma pequena parte dos usuários reais, enquanto o restante continua usando a versão antiga.

A ideia é monitorar o comportamento da nova versão em produção com um grupo real de usuários, antes de expandir para todos. Caso não haja falhas aumenta o grupo de usuários, caso haja falhas é feito o Rollback com facilidade

# 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
Gustavo Tanaka - 11215723

Gabriel Vasconcelos - 12676192

Silmar Pereira - 12623950

# data[].attributes.body
O padrão Staged Release é uma estratégia de implementação de software onde uma nova versão ou funcioinalidade é liberada gradualmente e para grupos pequenos de usuários antes de atingir toda a basede usuários

# data[].attributes.body
Mitigar risco em implantações de novas versões do software.

Evita falhas em larga escala.

# data[].attributes.body
Confiabilidade (Reliability) – detecta falhas precocemente com usuários reais.

Disponibilidade – reduz downtime, já que erros atingem apenas uma pequena parte dos usuários.

Desempenho – permite monitorar o impacto da nova versão sob carga real.

Manutenibilidade – facilita rollback e ajuste rápido caso erros sejam detectados.

Observabilidade – requer infraestrutura com métricas, logs e alertas

# data[].attributes.body
Resolve o problema de riscos associados à implementação de novas versões de software em produção. Ele busca minimizar falhas e impactos ao usuário final ao permitir que a liberação de novas funcionalidades seja feita de forma controlada e progressiva.

# data[].attributes.body
+Segurança no deploy

+ Menor risco de falhas

+Permite rollback rápido

-Maior complexidade de infraestrutura e gerenciamento

-Necessidade de bom monitoramento

-Maior tempo até concluir deploy

# data[].attributes.body
Confiabilidade: reduz o risco de falhas afetarem todos os usuários simultaneamente

Disponibilidade: evita indisponibilidades causadas por erros em novas versões

Manutenibilidade: facilita correções e rollback rápido em caso de falhas

Escalabilidade organizacional: permite testes com usuários reais sem expor toda a base de usuários

# data[].attributes.body
Blue-green deployment consiste na criação de 2 ambientes identicos, um chamado de "blue" e outro de "green", um recebera trafego de usuarios, e o outro irá receber mudanças dos desenvolvedores.

Quando as mudanças estiverem completas e testadas os papéis se alteram e o ambiente com atualizações recebe o trafego de usuarios. Caso algo de errado há o rollback para o trafego ir para o ambiente anterior

# data[].attributes.body
Maior complexidade de gestão: é necessário controlar versões diferentes rodando em paralelo e gerenciar quais usuários estão em qual estágio

Sobrecarga de monitoramento: exige ferramentas para rastrear falhas e coletar métricas por grupo de usuários

Tempo de liberação total mais longo: a liberação completa pode demorar mais, dependendo do número de estágios

# data[].attributes.body
Busca resolver problemas de downtime, o diminiundo durante a release de novas funcionalidades, diminuir o risco de introduzir problemas no ambiente de produção, e se caso ocorrer poder realizar um rollback com bastante agilidade.

# data[].attributes.headline
Onde cada padrão pode ser útil Canary Release

# data[].attributes.subject
Onde cada padrão pode ser útil Canary Release

# data[].attributes.body
Quer testar a nova versão com usuários reais em produção, mas com risco controlado
Tem boas métricas de observabilidade (logs, APM, alertas) para monitorar falhas em tempo real
Precisa de rollback rápido e suave

Exemplos:

Sistemas web com balanceamento de carga

# data[].attributes.body
Você precisa distribuir a nova versão aos poucos ao longo do tempo, para suavizar picos de carga ou evitar sobrecarga em suporte técnico
Publica em lojas de aplicativos (App Store, Google Play), onde o controle da instalação é parcial
O rollback não é simples, mas é possível lançar hotfixes rápidos
Quando quer fazer um rollout por regiões, perfis de usuários ou porcentagens controladas

Exemplos:

Aplicativos mobile

Aplicações desktop

Produtos SaaS com grandes bases de usuários

# data[].attributes.body
Zero downtime é crítico (ex: sistemas financeiros, e-commerce, plataformas de missão crítica)
Você tem ambientes isolados para cada versão e consegue fazer switch rápido entre elas
Precisa de rollback imediato, apenas redirecionando o tráfego para a versão antiga

Exemplos:

Sistemas internos corporativos com janelas de manutenção curtas

Plataformas web com alto SLA

Aplicações onde rollback deve ser imediato e seguro

# data[].attributes.body
Disponibilidade: permite implantar atualizações sem tirar o sistema do ar.

Confiabilidade: facilita a reversão para a versão anterior em caso de falhas.

Segurança: atualizações podem ser testadas em produção com usuários limitados antes da troca definitiva.

Escalabilidade Operacional: melhora o processo de entrega contínua e automação de deploys.

# data[].attributes.body
Custo de infraestrutura: é necessário manter dois ambientes (Blue e Green) completos e sincronizados, o que pode aumentar significativamente o uso de recursos.

Complexidade operacional: exige uma gestão cuidadosa de rotas de tráfego e sincronização de dados (como banco de dados), o que pode aumentar a complexidade da operação.

Latência de atualização de dados: se o banco de dados for compartilhado entre as versões Blue e Green, mudanças no esquema podem causar incompatibilidades.

Tempo de inatividade para banco de dados: alterações no banco podem ainda exigir downtime, mesmo com a troca suave da aplicação.