Analisar o ciclo de vida de lançamento
Objetivos de aprendizagem
Após concluir esta unidade, você estará apto a:
- Descrever o ciclo de vida dos lançamentos principais do Marketing Cloud Engagement.
- Conhecer as etapas de versões de patch e de emergência.
Ciclo de vida da versão principal
Vamos falar sobre como nossa equipe de produto faz a mágica de inovação acontecer! Na Salesforce, seguimos um ciclo de vida de desenvolvimento ágil para cada versão principal. Começamos planejando cada lançamento e temos 8 a 10 semanas de desenvolvimento antes do congelamento de recursos. Após essa data, nós nos concentramos na preparação para o lançamento e seguimos um processo de lançamento gradual. Vamos analisar as fases do ciclo de vida mais detalhadamente.
| Fase | O que está acontecendo | Mais informações |
|---|---|---|
|
Planejamento |
As equipes analisam e planejam o que querem concluir na próxima versão principal. Elas analisam suas listas de desejos do produto, ideias sobre o produto no IdeaExchange e problemas conhecidos. |
|
|
Desenvolvimento ágil |
Depois que o plano é estruturado, as equipes organizam o trabalho em sprints para se concentrar na criação e no teste de recursos específicos. O ciclo de desenvolvimento termina com o congelamento de recursos, a data em que todos os recursos inacabados são removidos da próxima versão. |
|
|
Release Readiness |
No congelamento de recursos, somente recursos concluídos que foram testados, validados e aprovados são incluídos na versão. |
|
|
Lançamentos graduais |
Depois de aprovados, o Marketing Cloud Engagement lança novos recursos usando uma abordagem de lançamento gradual. Todos os clientes recebem atualizações de versão durante nosso primeiro (R1) ou segundo lançamento (R2). |
|
Quer saber se você faz parte do R1 ou do R2? Você receberá notificações sobre a data do lançamento, mas, nos bastidores, a versão que você recebe depende da sua pilha e da sua instância de banco de dados. As pilhas 4, 11, 13 e 50 recebem R1. As pilhas 1, 6, 7, 10, 12 e 51 recebem R2.
Procedimentos de lançamento
Como você pode imaginar, nossas equipes ficam ocupadas antes de uma versão principal. Queremos mostrar os bastidores do que acontece logo antes de revelarmos os novos recursos a você.
| Quando | O que está acontecendo |
|---|---|
|
Duas a três semanas antes do lançamento |
Durante as atividades de preparação para o lançamento, nós:
|
|
Um a dois dias antes do lançamento |
Durante as atividades pré-lançamento, nós:
|
|
Data de lançamento |
Para garantir o mínimo de impacto:
|
|
Um dia após o lançamento |
Falamos com:
|
Versões adicionais
Além do foco no aprimoramento do produto e nas atualizações de versões principais, nossas equipes de produto trabalham para corrigir bugs e pesquisar problemas conhecidos. Seguimos um cronograma de lançamento de patches semanal que atualiza regularmente o produto.
| Quando | O que está acontecendo |
|---|---|
|
Contínuo |
Pesquisa e análise de possíveis correções de bugs. Depois que uma correção é identificada e há mudanças no código, ele é testado minuciosamente. |
|
Dois dias antes do lançamento |
As correções aprovadas são dadas como certas para a versão de patch seguinte. As equipes também finalizam os componentes e confirmam o plano de implantação. |
|
Um dia antes do lançamento |
Novo código é implantado em uma instância de produção interna às 14h EST. As equipes rastreiam e monitoram a implantação e fazem testes adicionais. |
|
Data de lançamento (quarta-feira) |
Sem tempo de inatividade*, novo código é implantado em todos os clientes às 20h EST em uma quarta-feira nos EUA. Mais testes de nível de superfície e validações ocorrem após o lançamento. |
*Essa declaração se refere aos lançamentos de código semanais. Examine este artigo do Knowledge sobre janelas de manutenção.
Ciclo de vida da versão de emergência
Algumas correções são simplesmente muito importantes para aguardar um lançamento semanal. Assim, quando um problema é escalado, nós nos concentramos em encontrar uma solução imediatamente. Depois de identificar e testar uma correção, precisamos aprová-la e validá-la antes de agendar a versão de emergência. Depois de planejado, os lançamentos de código de emergência usam uma abordagem de implantação gradual semelhante à de uma versão principal. Isso nos permite focar em uma estratégia de implantação com o mínimo de risco.
Agora que você conhece os tipos de versão/lançamento e ciclo de vida, vamos falar sobre as notificações de lançamento e a preparação na próxima unidade.
Recursos
- Ajuda do Salesforce: Notas de versão do Marketing Cloud Engagement
- Salesforce Trust: Manutenção do Marketing Cloud Engagement
- Salesforce: Problemas conhecidos
- Externo: O que é SQL? A primeira linguagem da análise de dados
- Externo: Teste de nível de superfície
- Salesforce Knowledge: Cronograma de manutenção preferido do Salesforce
