As equipes de desenvolvimento low-code gastam uma quantidade considerável de tempo e energia no escopo e desenvolvimento do próximo conjunto de recursos para seus aplicativos. Desenvolver aplicativos robustos que entreguem os resultados esperados é de suma importância. Mas o processo de move-lo entre os ambientes de desenvolvimento, teste e produção muitas vezes acaba sendo moroso.
Ter um plano bem estabelecido e bem comunicado para lançar um aplicativo é a parte mais importante de um go-live. Aqui estão alguns itens que você deve pensar antes de fazer qualquer lançamento:
-
Quando o lançamento começará e quanto tempo levará?
Trabalhe com as partes interessadas para identificar um momento em que elas serão minimamente impactadas. A duração é difícil de prever — quanto mais você fizer isso, melhor será capaz de estimar. Prometa menos e entregue mais do que o esperado.
-
Como os usuários finais serão impactados durante o lançamento?
Independentemente de quão bem você comunique os lançamentos e as interrupções planejadas com antecedência, é preciso presumir que os usuários estarão no aplicativo, se puderem. Isso pode não ser um problema, mas, caso seja, talvez seja necessário considerar a proibição de acesso ao aplicativo durante o período de manutenção.
-
Quem é responsável por cada etapa do processo de liberação?
Um plano detalhado deve ser compartilhado com a equipe de pessoas que está realizando as etapas. Reserve um tempo para revisar o plano juntos e enfatize que qualquer tipo de pergunta é válida quando se trata de clareza no plano de liberação. Certifique-se de que cada indivíduo tenha o acesso correto para realizar as etapas que lhe foram atribuídas.
-
Quais novos pontos de conexão/integração com aplicativos de terceiros estão sendo introduzidos?
Na primeira vez que uma conexão ou integração for ao ar, haverá um pouco de incerteza na mente da equipe. Uma chave de API incorreta ou tráfego de rede bloqueado pode atrapalhar o plano. Os desenvolvedores devem fazer questão de chamar a atenção da equipe para que a nova conexão possa ser planejada adequadamente.
-
Se a liberação não for bem-sucedida, qual é o plano de retirada?
Este nunca é o resultado esperado ou desejado, mas ter um plano antecipado guiará a equipe durante uma situação estressante.
O sucesso no go-live depende de acertar de primeira. Por isso, é recomendado usar um ambiente de teste ou staging como um ensaio para identificar e corrigir problemas.
Nos lançamentos de aplicativos do Jitterbit App Builder, os desenvolvedores criam uma versão a partir do ambiente de desenvolvimento, baixam o arquivo da versão (chamado de arquivo LP) e o carregam no ambiente de destino para instalação. Há alguns riscos comuns que você deve verificar cuidadosamente antes de criar a versão e instalá-la em produção:
-
Opções de instalação da tabela:
Na maioria das vezes, seus lançamentos incluirão tabelas físicas. Cada tabela possui uma configuração de opção de instalação que define como os dados armazenados nela serão tratados ao criar o lançamento e, posteriormente, ao instalá-lo no ambiente de destino. Essa é uma funcionalidade poderosa, mas deve ser usada com cautela. Certamente, você não vai querer substituir dados de produção de qualidade pelos dados criados pelos desenvolvedores. Você pode saber mais sobre essas opções em nosso página sobre como criar um pacote de lançamento..
-
Funções:
O acesso a uma página, bem como os recursos nativos de criação/edição/exclusão de dados mostrados a um usuário em uma página, são controlados granularmente na camada lógica. Sempre que um desenvolvedor modifica as funções de uma regra de negócios ou introduz uma nova regra em uma página, isso pode ter um efeito não intencional na capacidade de um grupo de usuários específico de chegar à página. Criar um usuário de teste para cada grupo de usuários e testes de regressão para funções é uma ótima prática antes de qualquer lançamento em produção. Isso ajudará você a evitar o temido e-mail "Não consigo mais acessar esta página" do seu usuário final no dia seguinte a um lançamento. Confira esta página de documentação para mais informações sobre privilégios e permissões.
Sempre que for disponibilizar um aplicativo criado no Jitterbit App Builder, examine o modelo de lançamento. Você deve disponibilizar apenas os componentes do aplicativo que foram alterados e que deseja liberar para produção.
No seu modelo de lançamento, você pode escolher esses diferentes componentes. É possível disponibilizar um aplicativo inteiro que incluirá todas as fontes de dados, lógica e páginas. Ou se sua alteração foi em uma escala menor, você pode lançar apenas uma única página ou regra de negócios e lançar esses componentes menores para produção, deixando o restante do aplicativo como está. Essa flexibilidade no processo de liberação permite que sua equipe de desenvolvimento responda mais facilmente a quaisquer problemas críticos que surjam ao trabalhar em solicitações maiores.
O recurso do componente de aplicativo aumenta a flexibilidade, a velocidade e o controle sobre o processo de implantação de software, tornando-o uma ferramenta poderosa em ambientes que exigem atualizações frequentes e tempo de inatividade mínimo. Os principais benefícios para suas equipes de desenvolvimento são:
-
Atualizações modulares:
Permite que componentes específicos de um aplicativo sejam atualizados de forma independente, reduzindo dependências de código.
-
Tempo de inatividade minimizado:
Somente os componentes alterados são atualizados, permitindo atualizações mais suaves.
-
Maior agilidade de desenvolvimento:
As equipes podem lançar atualizações ou patches rapidamente para componentes individuais, aumentando o tempo de resposta.
Saiba mais sobre o Jitterbit App Builder, ou o poderoso conjunto de recursos de IA que serão disponibilizados em breve no Jitterbit App Builder 4.0.
