Estratégias de upgrade de produção para Jitterbit App Builder

Introdução

Fazer upgrade do App Builder significa instalar uma nova versão da plataforma no seu ambiente App Builder, incluindo todas as atualizações necessárias do banco de dados Vinyl (o banco de dados subjacente do App Builder). Como um upgrade altera o runtime da sua aplicação e o schema do banco de dados simultaneamente, planejar com cuidado ajuda a identificar problemas de compatibilidade cedo e manter o tempo de inatividade previsível.

A melhor abordagem é validar uma versão da plataforma em um ambiente que não seja produção primeiro. Mantenha pelo menos uma topologia de dois ambientes (desenvolvimento e produção) ou uma topologia de três ambientes (desenvolvimento, QA e produção) seguindo a abordagem em 3 camadas, para que você possa testar versões da plataforma, migrações de schema do banco de dados e lógica de aplicação customizada antes que cheguem à produção. Executar um único ambiente apenas de produção é fortemente desaconselhado, pois não deixa nenhum ambiente para identificar problemas antes que afetem os usuários.

Esta página lista os pré-requisitos para fazer upgrade e depois detalha o processo em três etapas:

1. Etapa 1: Fazer upgrade e validar desenvolvimento e QA
   Faça upgrade da versão da plataforma nos seus ambientes de desenvolvimento e QA e valide-a lá.

2. Etapa 2: Fazer upgrade de produção
   Escolha uma estratégia para fazer upgrade do ambiente de produção: um upgrade in-place ou uma implantação Blue/Green.

3. Etapa 3: Verificar o upgrade
   Garanta que o upgrade foi bem-sucedido.

Se você mantém apenas um ambiente de produção, consulte Implantações em ambiente único (apenas produção) para orientação sobre como adaptar as etapas abaixo.

Pré-requisitos

Antes de executar um upgrade de plataforma em qualquer ambiente, complete o seguinte, em ordem:

1. Congelamento de código: Institua um congelamento de código em todos os ambientes. Não inicie novo desenvolvimento de recursos de aplicação até que o upgrade de plataforma esteja completo em todos os ambientes.

2. Sincronização de schema do banco de dados: Garanta que os schemas de banco de dados customizados (tabelas, colunas, views e stored procedures) estejam sincronizados entre desenvolvimento, QA e produção. Desvio de schema entre ambientes pode causar falhas imprevisíveis no upgrade de plataforma ou na lógica de aplicação. Consulte Gerenciamento de release para saber como o App Builder rastreia e reproduz mudanças de schema entre ambientes.

3. Verificação de requisitos do sistema: Verifique que o ambiente host atende aos requisitos do sistema para a versão alvo, em sistemas operacionais, runtimes de container e engines de banco de dados.

4. Backups de banco de dados, arquivo e pasta: Imediatamente antes de iniciar a manutenção, faça o seguinte:

   • Faça backup do banco de dados Vinyl (obrigatório) e de qualquer banco de dados de aplicação sofrendo mudanças físicas ou de schema (altamente recomendado).

   • Mantenha uma cópia do arquivo de release anterior (.tar.gz ou .zip), ou a pasta de aplicação anterior em si, no host. Qualquer um permite que você faça rollback rapidamente: re-extraia o arquivo ou troque a pasta antiga de volta para o lugar.

   • Preserve o seguinte conteúdo do diretório de aplicação App Builder ao substituir binários de aplicação ou fazer upgrade de diretórios:

     • appsettings.json: Retém as configurações de configuração no nível da aplicação.

     • Connection.xml: Retém as strings de conexão e parâmetros do banco de dados backend.

     • data: Contém arquivos de aplicação armazenados localmente, como PDFs gerados, uploads de arquivo e outros anexos de documento armazenados no diretório App Builder.

     • keys: Contém as chaves de criptografia de dados usadas para descriptografar credenciais armazenadas, strings de conexão e dados de aplicação. Perder esta pasta torna dados criptografados permanentemente ilegíveis.

     • Arquivo de licença (vinyl.lic): Evita erros de licenciamento na inicialização.

5. logs: Retém logs de eventos do sistema, logs de diagnóstico e trilhas de auditoria.

Após atender a esses pré-requisitos, prossiga para Etapa 1: Atualizar e validar desenvolvimento e QA.

Etapa 1: Atualizar e validar desenvolvimento e QA

Antes de atualizar a produção em qualquer uma das estratégias, atualize a versão da plataforma em desenvolvimento e QA e valide-a lá. Isso permite que desenvolvedores e usuários de negócios identifiquem problemas de compatibilidade enquanto a alteração ainda não atingiu a produção, independentemente de qual estratégia você escolher posteriormente para a atualização de produção.

Atualizar o banco de dados de desenvolvimento ou QA (opcional)

Como precaução adicional, restaure uma cópia atualizada do banco de dados de produção em desenvolvimento ou QA antes de atualizar esses ambientes:

• Restaurar para desenvolvimento para uma execução de teste de migração: Isso permite que desenvolvedores testem atualizações de esquema em dados reais de produção, identifiquem conflitos específicos de dados antecipadamente e meçam o tempo de execução para planejar a janela de tempo de inatividade de produção.

• Restaurar para QA para Teste de Aceitação do Usuário (UAT) realista: Isso garante que usuários de negócios realizem UAT em cenários autênticos de dados de produção.

Atualizar o ambiente de desenvolvimento e realizar teste de fumaça

Atualizar o ambiente de desenvolvimento primeiro permite que desenvolvedores validem a nova versão da plataforma em relação à lógica real da aplicação e corrijam problemas de compatibilidade antes que eles atinjam QA ou produção.

1. (Opcional) Atualize o banco de dados de desenvolvimento, seguindo as orientações acima.

2. Atualize o runtime e o banco de dados do App Builder em desenvolvimento.

3. Realize teste de fumaça na instância atualizada, focando nas seguintes áreas:

   • Processos de negócios principais: A lógica de negócios geralmente depende de funções em nível de banco de dados, geração dinâmica de SQL ou procedimentos armazenados. Uma atualização de versão pode alterar como as consultas de banco de dados são executadas, portanto valide seus caminhos principais.

   • Conexões de fonte de dados e integrações: As atualizações de plataforma geralmente incluem drivers de banco de dados atualizados, conectores Open Database Connectivity (ODBC) ou Java Database Connectivity (JDBC), ou requisitos de autenticação revisados. Verifique se todas as fontes de dados remotas se conectam e consultam corretamente.

   • Elementos de UI e UX (temas, HTML, CSS, layouts): As atualizações de plataforma podem alterar estruturas internas do Document Object Model (DOM) ou seletores de elementos padrão. Estilos personalizados e substituições podem quebrar se classes estruturais ou seletores mudarem.

   • Código personalizado (widgets de UI, plugins, JavaScript personalizado): O código personalizado apresenta o maior risco durante uma atualização, pois o QA do Jitterbit não pode testar código escrito fora da plataforma principal. Teste todos os componentes de UI interativos para confirmar que suas APIs ou destinos de DOM não mudaram.

   • Segurança, funções e permissões em nível de linha: As versões da plataforma às vezes atualizam a lógica de avaliação de segurança ou filtros de segurança em nível de linha. Verifique se as funções de usuário, regras de representação e políticas de acesso a dados se comportam conforme esperado.

   • Eventos agendados, trabalhos em segundo plano e filas: Confirme que tarefas automatizadas são disparadas e executadas até a conclusão, pois alterações na configuração do serviço em segundo plano podem afetá-las.

   • Notas de versão da plataforma: Revise as notas de versão do App Builder para descontinuações, alterações significativas e quaisquer etapas pós-atualização necessárias.

4. Se desenvolvedores encontrarem problemas de compatibilidade durante o teste de fumaça, faça as correções necessárias em desenvolvimento e, em seguida, crie um pacote de versão para implantar as correções em QA e produção.

Atualizar QA e conduzir UAT

Com o ambiente de desenvolvimento validado, esta etapa traz o QA para a mesma versão da plataforma, implanta as correções realizadas durante o desenvolvimento e oferece aos usuários de negócios a oportunidade de aprovar antes de tocar na produção.

1. (Opcional) Atualize o banco de dados de QA, seguindo as orientações acima.

2. Atualize o runtime do App Builder e o banco de dados em QA.

3. Implante o pacote de versão contendo as correções exportadas do desenvolvimento. A instalação de um pacote de versão requer um breve tempo de inatividade adicional para os aplicativos afetados.

4. Conduza UAT completo para validar a funcionalidade do aplicativo e obter aprovação de implantação.

Após atualizar e validar o desenvolvimento e o QA, prossiga para Etapa 2: Atualizar produção.

Etapa 2: Atualizar produção

Com o desenvolvimento e o QA atualizados e validados, e seu pacote de versão pronto, escolha uma das seguintes estratégias para a atualização de produção:

• Atualização in-place: Aplica a atualização da plataforma diretamente à produção durante uma janela de manutenção. Recomendado para topologias padrão de desenvolvimento, QA e produção.

• Implantação Blue/Green: Atualiza uma cópia paralela da produção (Green) enquanto o ambiente ativo (Blue) continua servindo usuários, depois alterna o tráfego após verificar o Green. Recomendado para ambientes críticos que exigem tempo de inatividade mínimo.

A tabela a seguir compara as duas estratégias:

Atualização in-place

Recomendado para topologias padrão de desenvolvimento, QA e produção usando uma janela de manutenção agendada. Esta estratégia aplica a atualização da plataforma diretamente à infraestrutura ativa da produção, após a versão já ter sido atualizada e validada em desenvolvimento e QA.

Para começar, aplique a atualização da plataforma e as correções validadas em desenvolvimento e QA à produção durante sua janela de manutenção agendada. Siga estas etapas:

1. Interrompa os Serviços de Informações da Internet (IIS), serviços de aplicativo ou contêineres em produção para parar o tráfego de entrada.

2. Faça backup dos bancos de dados de produção e preserve os arquivos principais listados em Pré-requisitos.

3. Atualize o runtime do aplicativo para seu ambiente:

   • AWS: Implante o novo pacote de aplicativo ou atualize a tag de imagem de destino, seguindo Instalar App Builder na AWS.

   • Azure: Atualize a tag de imagem do contêiner ou pacote de aplicativo, seguindo Instalar App Builder no Microsoft Azure.

   • Docker: Atualize a tag de imagem em docker-compose.yml, mantendo os mounts de volume que persistem keys, logs, data, Connection.xml e appsettings.json, depois puxe e reinicie os contêineres. Consulte Atualizar para App Builder no Docker.

4. Google Cloud Platform (GCP): Implante a nova tag de imagem de container no Cloud Run, Google Kubernetes Engine (GKE) ou Compute Engine.

5. Windows/IIS: Siga Upgrade App Builder on Microsoft Windows, que aborda a restauração de Connection.xml, appsettings.json e da pasta keys, além de conceder ao pool de aplicativos do IIS identidade com Controle Total sobre os diretórios data, logs e keys.

6. Inicie os serviços para colocar a plataforma atualizada online.

7. Implante o pacote de versão contendo as correções validadas em desenvolvimento e QA. Leve em conta o breve tempo de inatividade adicional que isso requer.

8. Conclua as verificações em Step 3: Verify the upgrade, limpe os caches da aplicação e reabra o ambiente para os usuários.

Reverter uma atualização in-place

Se a atualização de produção falhar ou introduzir problemas críticos, siga estas etapas para reverter a produção ao seu estado anterior à atualização.

1. Interrompa os serviços da aplicação, IIS ou containers.

2. Restaure o banco de dados Vinyl e os bancos de dados da aplicação a partir dos backups anteriores à atualização.

   Aviso

   Restaurar backups de banco de dados reverte qualquer atividade do usuário ou transações registradas após a atualização.

3. Reverta o runtime da aplicação:

   • Windows/IIS: Substitua o diretório da aplicação pela pasta de backup preservada ou extraia novamente o arquivo de versão anterior, mantendo keys, logs, data, Connection.xml, appsettings.json e o arquivo de licença intactos.

   • Docker ou containers em nuvem (AWS, GCP, Azure): Reverta para a tag de versão anterior no seu arquivo compose, Cloud Run, GKE ou configuração do App Service e reimplante.

4. Inicie os serviços e execute verificações básicas antes de reabrir o ambiente.

Implantação Blue/Green

Recomendada para ambientes de produção críticos que exigem alta disponibilidade e janelas de manutenção mínimas.

Blue/Green é uma estratégia de implantação para a fase de produção do seu ciclo de vida. Ela não substitui os testes em não-produção: conclua os pré-requisitos e Step 1: Upgrade and validate development and QA antes de iniciar uma transição Blue/Green em produção. (Isso não se aplica se você está adaptando Blue/Green para uma implantação em ambiente único.)

Esta estratégia atualiza Green enquanto Blue permanece online e depois faz a transição após Green ser verificado. Espere tempo de inatividade mínimo, limitado à sincronização final do banco de dados e à transição de DNS ou load balancer.

Para começar, provisione o ambiente Green. Green precisa existir como um ambiente independente, configurado como Blue mas ainda não servindo tráfego ao vivo, antes que você possa atualizar e validar a nova versão nele. Siga estas etapas:

1. Em Blue, antes de clonar, adicione uma entrada de site para Green para que Green não herde o redirecionamento de Blue. Selecione Security Providers > More > Sites, clique em + Site e crie uma entrada com a URL de Green, deixando Default e Redirect desmarcados. Após Green ser clonado de Blue, as requisições para a própria URL de Green correspondem a esta entrada em vez de recorrer à entrada padrão de Blue com redirecionamento ativado. (Veja Sites and aliases para mais informações sobre este recurso.)

2. Provisione Green como um clone completo de Blue, incluindo seu banco de dados Vinyl naquele momento (com suas chaves de criptografia atuais, histórico de workflow, histórico de jobs e logs).

3. Atualize Connection.xml, appsettings.json e variáveis de ambiente de Green para apontar para a instância de banco de dados Green durante o staging, não para o banco de dados Blue ao vivo.

{
  "Site": {
    "Url": "https://localhost:5001",
    "Default": true,
    "Redirect": false,
    "Aliases": [
      {
        "Url": "https://localhost:5000"
      }
    ]
  }
}

Em seguida, aplique a atualização para Green e valide-a contra dados de produção. Neste ponto, os usuários que Blue continua atendendo ainda não serão impactados. Siga estas etapas:

1. Clone os bancos de dados de produção para Green.

2. Aplique a atualização da plataforma, atualizações de container e migrações de banco de dados em Green.

3. Implante o pacote de lançamento contendo as correções validadas em desenvolvimento e QA.

4. Se suas aplicações executam trabalhos em segundo plano que enviam notificações por email, desabilite esses trabalhos ou ajuste as configurações do servidor SMTP em Green durante a validação, para evitar que emails duplicados sejam enviados aos usuários enquanto Blue permanece ativo.

5. Conclua a validação e verificações de integridade em Green enquanto Blue continua a lidar com o tráfego ativo.

Agora que Green foi totalmente validado, é hora de sincronizar as últimas alterações de produção e alternar o tráfego ativo de Blue para Green:

1. Pause as operações de escrita em Blue ou interrompa brevemente os serviços da aplicação Blue.

2. Faça um backup final dos bancos de dados de usuário (aplicação) de Blue e restaure-o em Green para atingir paridade completa de dados. A Jitterbit recomenda um backup e restauração completos. Um backup diferencial é recomendado apenas quando o volume de dados torna um backup completo impraticável.

3. Sincronize as chaves de criptografia entre Blue e Green:

   • Se as chaves são armazenadas em um local externo, como um bucket S3, Blue e Green já as compartilham, e nenhuma ação é necessária.

   • Se as chaves são armazenadas no sistema de arquivos (o padrão), copie as Chaves de Criptografia de Chaves (KEKs) de Blue para Green agora.

   • Para cada fonte de dados, abra a aba Fontes de dados, selecione a linha da fonte de dados e, em seguida, selecione Chaves de Criptografia em Camada de Lógica de Negócios para verificar se há registros de Chave de Criptografia de Dados (DEK) criados desde que Green foi provisionado:

     

     Para qualquer novo registro, peça a um administrador que se conecte diretamente ao banco de dados Vinyl de Blue, exporte a chave da tabela Se_DataEncryptionKey e importe-a no banco de dados Vinyl de Green.

   Aviso

   Um ambiente de produção em execução deve reter todas as chaves de criptografia geradas ao longo de sua vida útil, caso contrário, os dados que criptografa se tornam permanentemente ilegíveis.

4. Reabilite ou restaure as configurações de SMTP ou trabalhos em segundo plano que você ajustou em Green durante o staging.

5. Aquça os pools de aplicação ou containers em Green.

6. Reaponte os registros DNS, balanceadores de carga ou proxies reversos de Blue para Green.

7. Conclua as verificações em Etapa 3: Verifique a atualização, monitore o tráfego em Green e descomissione ou desligue Blue após a estabilidade ser verificada.

8. Após Blue ser descomissionado, remova ou atualize a entrada de site que Green herdou de Blue (aquela com Padrão e Redirecionamento habilitados).

   Nota

   Se deixada em vigor, essa entrada redireciona qualquer solicitação que não corresponda à entrada de site própria de Green para o Blue agora descomissionado.

Reverter um cutover Blue/Green

Se testes em Green revelarem problemas, ou um problema crítico aparecer logo após o cutover, você pode precisar voltar para Blue. Como Blue permanece intocado durante testes e staging, reverter é direto, independentemente de quando o problema aparecer:

• Antes do cutover: Se testes em Green revelarem problemas, encerre Green. Blue não sofre impacto ou tempo de inatividade.

• Após o cutover: Se problemas críticos ocorrerem imediatamente após alternar DNS ou roteamento, reaponte DNS ou balanceadores de carga de volta para Blue. Reconcilie manualmente qualquer transação de escrita registrada em Green após o cutover de volta para Blue antes de reverter.

Implantações em ambiente único (somente produção)

Se você tem uma implantação em ambiente único (somente produção), a estratégia de atualização é um pouco diferente. Para começar, conclua os itens 1, 3 e 4 dos pré-requisitos: o congelamento de código, a verificação de requisitos do sistema e os backups, pois todos se aplicam a uma implantação em ambiente único. O item 2 (a sincronização do esquema de banco de dados) não se aplica, pois não há outro ambiente para sincronizar. Como uma implantação em ambiente único não tem ambiente de desenvolvimento ou QA, você também deve pular Etapa 1: Atualize e valide desenvolvimento e QA. Em vez disso, escolha uma das seguintes abordagens:

Atualização in-place em um único ambiente

Esta abordagem segue as mesmas etapas de atualização de runtime da atualização in-place: parar os serviços, fazer backup, atualizar o runtime da aplicação e iniciar os serviços novamente. Pule a etapa que implanta um pacote de release compilado em desenvolvimento e QA, já que nenhum dos dois existe em uma implantação de ambiente único. Em vez disso, como o teste de funcionalidade básica ocorre diretamente em produção após a atualização, os desenvolvedores que encontram problemas na aplicação devem corrigi-los no ambiente ativo enquanto os usuários estão conectados. Se a atualização em si falhar, use as mesmas etapas de reversão da atualização in-place.

Para evitar que os usuários encontrem erros ou fluxos de trabalho corrompidos enquanto os desenvolvedores aplicam correções, use o fluxo de trabalho orientado Maintenance para bloquear aplicações afetadas e redirecionar o tráfego de não-administradores para uma página de manutenção até que os testes e correções sejam concluídos.

Blue/Green em um único ambiente

Se você usar uma estratégia Blue/Green em uma configuração de ambiente único, o ambiente Green atua como um playground de testes temporário. Os desenvolvedores executam a atualização da plataforma, concluem testes completos de funcionalidade básica e aplicam as correções necessárias na aplicação no Green enquanto o Blue permanece ativo e gerencia o tráfego normal de usuários.

Após o Green ser totalmente testado e verificado, sincronize as alterações finais do banco de dados e mude o tráfego, seguindo a implantação Blue/Green. Os usuários não experimentam estados de aplicação quebrados nem veem janelas de manutenção durante o ciclo de correção.

Após concluir a atualização usando qualquer uma das abordagens, prossiga para a Etapa 3: Verificar a atualização.

Etapa 3: Verificar a atualização

Antes de encerrar a janela de manutenção (se você usou a atualização in-place) ou desativar o Blue (se você usou a implantação Blue/Green), confirme o seguinte:

• A licença do App Builder permanece válida e ativa na release atualizada.

• Os trabalhos agendados em segundo plano, filas e workers do pool de threads estão em estado de execução ou ocioso e não falharam na inicialização.

• A pasta logs não mostra exceções não tratadas, erros de Mapeamento Objeto-Relacional (ORM) ou tempos limite de conexão com o banco de dados.

• A versão do App Builder exibida no rodapé da aplicação ou na página de diagnóstico corresponde à release de destino.