Desenvolvimento de uma nova versão de um aplicativo¶

Teste completo de um aplicativo antes de iniciar a verificação de segurança automatizada¶

As ações a seguir podem iniciar a verificação de segurança automatizada:

• Defina a propriedade DISTRIBUTION do pacote do aplicativo como EXTERNAL se houver uma versão do aplicativo

• Adicione uma nova versão ou patch a um pacote do aplicativo que tenha a propriedade DISTRIBUTION definida como EXTERNAL

A Snowflake recomenda que você teste completamente uma nova versão ou patch do seu aplicativo localmente antes de iniciar a verificação de segurança para evitar atrasos e várias iterações da varredura em caso de falha.

Garantia de compatibilidade entre as versões¶

Os provedores devem garantir que uma nova versão seja compatível com a versão anterior de um aplicativo. Por exemplo, se um aplicativo tiver as versões v1 e v2, a v2 deverá ser compatível com a v1. Quando a versão v3 for adicionada, ela deverá ser compatível com a versão v2. No entanto, como só podem existir duas versões de um aplicativo ao mesmo tempo, a versão v3 não precisa ser compatível com a versão v1.

O código executado na versão anterior deve lidar com as alterações de estado introduzidas na nova versão. Para lidar com objetos sem estado, os provedores devem usar esquemas com versão para garantir que as atualizações sejam tratadas corretamente. Consulte Como usar o esquema com versão para gerenciar objetos de aplicativos entre versões para obter mais informações.

Minimização das alterações de estado nos patches¶

Os provedores devem garantir que os novos patches não introduzam alterações de estado que sejam diferentes dos patches anteriores da mesma versão. Os provedores devem minimizar as alterações de estado, como adicionar ou alterar tabelas ou colunas ao desenvolver um patch. As tabelas e colunas devem permanecer compatíveis em todas as versões e patches. Os patches devem se concentrar em correções de bugs ou acréscimos de recursos menores, sem envolver modificações de estado.

As alterações de estado só devem ser feitas ao atualizar a versão de um aplicativo.

Uso de práticas seguras ao criar objetos a partir do script de configuração¶

Ao criar objetos a partir do script de configuração, considere as seguintes práticas recomendadas:

• Use CREATE IF NOT EXISTS:

  Você deve sempre usar CREATE OR REPLACE, CREATE IF NOT EXISTS ou CREATE OR ALTER, o que for aplicável, ao criar objetos de banco de dados, como tabelas, exibições, funções ou procedimentos. Isso evita erros ao tentar criar objetos que já existem durante o upgrade.

  A Snowflake recomenda o uso do CREATE OR REPLACE somente para objetos sem estado, como funções ou procedimentos, mas não para objetos com estado, como tabelas.

• Como garantir que o script de configuração de cada aplicativo seja autônomo

  Cada versão do aplicativo deve ser completa e independente. Por exemplo, se uma tabela foi criada na versão v2.0 usando a instrução CREATE TABLE IF NOT EXISTS a(int c) e a versão v3.0 inclui ALTER TABLE A(…), certifique-se de que as instruções CREATE TABLE e ALTER TABLE estejam presentes na versão v3.0. Isso garante que os usuários que instalam o aplicativo a partir de uma versão posterior tenham todos os esquemas e objetos necessários.

• Uso de apenas alterações idempotentes no script de configuração

  Estruture os comandos CREATE e ALTER para serem idempotentes, de modo que possam ser executados várias vezes sem erros ou efeitos colaterais indesejados. Se o script de configuração falhar durante a instalação, o Snowflake executará novamente o script de configuração desde o início. Se um esquema com controle de versão já tiver sido criado para essa versão, ele não será recriado ou excluído. Por esse motivo, os provedores devem usar a versão CREATE IF NOT EXISTS dos comandos CREATE.

  Por exemplo:

  • Use ALTER TABLE ADD COLUMN IF NOT EXISTS para garantir que as colunas sejam adicionadas somente se ainda não existirem.

  • Ao inserir linhas, implemente proteções para evitar a duplicação de linhas, caso não seja intencional, pois as atualizações podem ser repetidas várias vezes.

Tenha cuidado ao criar ou descartar funções de aplicativos¶

Tenha cuidado ao criar ou descartar funções de aplicativo em uma versão ou patch. As funções de aplicativo não têm versão. O descarte de uma função de aplicativo ou a revogação de uma concessão em um objeto de uma versão para outra pode fazer com que o aplicativo pare de funcionar ou impedir que os consumidores acessem o aplicativo.

Evite usar CREATE OR REPLACE APPLICATION ROLE. Em vez disso, use CREATE APPLICATION ROLE IF NOT EXISTS. A cláusula OR REPLACE descartará e recriará funções, causando problemas de permissão, pois as funções no nível da conta concedidas à função do aplicativo em versões anteriores precisariam ser concedidas novamente.

Pausa na execução do script de configuração¶

Para minimizar o tempo de inatividade e garantir que os serviços estejam prontos, use a função de sistema SYSTEM$WAIT_FOR_SERVICES no script de configuração após criar ou alterar um serviço:

SELECT SYSTEM$WAIT_FOR_SERVICES(600, 'services.web_ui', 'services.worker', 'services.aggregation');

Este comando faz com que o script de configuração seja pausado até que uma das seguintes situações ocorra:

• Todos os serviços nomeados passados para a função do sistema têm o status READY.

• Qualquer um dos serviços nomeados tem o status FAILED.

• 600 segundos se passaram.

Essa função do sistema garante que a instalação ou atualização do aplicativo aguarde até que o serviço esteja disponível ou até que ocorra uma falha, garantindo que o estado do serviço esteja em sincronia com a atualização da versão.

Considerações sobre a atualização de serviços¶

O Snowflake Native App Framework fornece a função de retorno de chamada do inicializador de versão que permite que os provedores sincronizem os serviços de atualização com o restante do procedimento de atualização.

Durante a atualização de um aplicativo básico, o script de configuração atualiza para a nova versão do aplicativo modificando objetos dentro de um esquema com versão. Se ocorrer um erro durante a atualização, os objetos dentro do esquema versionado retornarão à versão anterior do aplicativo.

No caso de um aplicativo com contêineres, os serviços que são criados ou modificados pela execução dos comandos CREATE SERVICE ou ALTER SERVICE no script de configuração usam um arquivo de especificação de serviço para a nova versão.

Como os serviços não são criados em esquemas com versão, um serviço é atualizado assim que o comando CREATE SERVICE ou ALTER SERVICE é executado com êxito. Se houver uma falha posteriormente no script de configuração, por exemplo, os objetos nos esquemas com controle de versão serão revertidos para a versão anterior, mas os serviços modificados serão os serviços da nova versão.

Uso de um inicializador de versão para gerenciar as atualizações de serviço¶

O Snowflake Native App Framework fornece um inicializador de versão usado para iniciar ou atualizar serviços ou outros processos relacionados, por exemplo, tarefas. O inicializador de versão é um procedimento armazenado de retorno de chamada especificado no arquivo de manifesto.

O inicializador de versão é chamado nos seguintes contextos:

• Durante a instalação, o inicializador de versão é chamado assim que o script de configuração do aplicativo termina sem erros.

• Durante a atualização, há dois cenários possíveis em que o inicializador de versão é chamado:

  • Se o script de configuração da nova versão for bem-sucedido, o inicializador de versão da nova versão do aplicativo será chamado.

  • Se o script de configuração ou o inicializador de versão da nova versão falhar, o inicializador de versão da versão anterior do aplicativo será chamado. Isso permite que o inicializador da versão anterior use o ALTER SERVICE para reverter os serviços para a versão anterior.

Como adicionar o inicializador de versão a um aplicativo¶

Para especificar o procedimento armazenado usado como inicializador de versão, adicione o seguinte ao arquivo manifest.yml:

lifecycle_callback:
  version_initializer: callback.version_init

Neste exemplo, a propriedade version_initializer é definida como um procedimento armazenado denominado version_init dentro de um esquema denominado callback.

No script de configuração, um provedor pode definir esse procedimento dentro de um esquema com versão, conforme mostrado no exemplo a seguir:

CREATE OR ALTER VERSIONED SCHEMA callback;

CREATE OR REPLACE PROCEDURE callback.version_init()
  ...
  -- body of the version_init() procedure
  ...