5 conseils pour des versions d'applications plus efficaces

Par Tim Bond, Gestionnaire de produit

Les équipes de développement low-code consacrent beaucoup de temps et d’énergie à définir et à développer le prochain ensemble de fonctionnalités de leurs applications low-code. Développer des applications robustes qui produisent les résultats escomptés est de la plus haute importance. Mais le processus de déplacement de l’application d’un environnement de développement à un environnement de test, puis à un environnement de production ou de production est trop souvent une réflexion de dernière minute.

Disposer d'un plan bien établi et bien communiqué pour la publication d'une application dans un environnement de production est la partie la plus importante d'une mise en service. Voici quelques éléments auxquels vous devez réfléchir avant de procéder à une publication :

• Quand la sortie va-t-elle commencer et combien de temps cela prendra-t-il ?

  Travaillez avec les parties prenantes pour identifier le moment où elles seront le moins impactées. La durée est difficile à prévoir : plus vous le faites, mieux vous serez en mesure de l'estimer. Faites des promesses en moins et dépassez vos attentes.

• Comment les utilisateurs finaux seront-ils impactés lors de la sortie ?

  Quelle que soit la qualité de votre communication sur les mises à jour et les temps d'arrêt planifiés à l'avance, vous devez partir du principe qu'un utilisateur sera présent dans l'application s'il le peut. Cela ne pose peut-être pas de problème, mais si c'est le cas, vous pouvez envisager d'interdire l'accès à l'application pendant la période de maintenance.

• Qui est responsable de chaque étape du processus de publication ?

  Un plan détaillé doit être présenté à l'équipe de personnes qui exécutent les étapes. Prenez le temps de revoir le plan ensemble et insistez sur le fait qu'il n'y a pas de questions idiotes lorsqu'il s'agit de clarifier le plan de publication. Assurez-vous que chaque individu dispose des droits d'accès appropriés pour exécuter les étapes qui lui sont assignées.

• Quels nouveaux points de connexion/d’intégration aux applications tierces sont introduits ?

  La première fois qu'une connexion ou une intégration est mise en service, une certaine incertitude planera sur l'esprit de l'équipe. Une clé API incorrecte ou un trafic réseau bloqué pourraient faire dérailler le plan. Les développeurs doivent s'assurer de le signaler à l'équipe afin que la nouvelle connexion puisse être planifiée de manière appropriée.

• Si la sortie n'est pas réussie, quel est le plan de secours ?

  Ce n’est jamais le résultat attendu ni souhaité, mais avoir un plan à l’avance guidera l’équipe pendant une situation stressante.

Vous n'avez qu'une seule chance de réussir votre mise en service dès le premier essai. Je vous suggère d'utiliser une version de test ou de préparation comme essai de production pour résoudre les éventuels problèmes.

En ce qui concerne le Jitterbit App Builder Lors des versions d'applications, vos développeurs créent une version à partir de l'environnement de développement, téléchargent le fichier de version (nous l'appelons un fichier LP) et le chargent dans l'environnement cible pour l'installer. Il existe quelques risques courants que vous devez vérifier avant de créer la version et de l'installer en production :

• Options d'installation du tableau :

  Le plus souvent, vous aurez des tables physiques incluses dans votre version. Chaque table possède un paramètre d'option d'installation qui détermine la manière dont les données stockées dans la table sont traitées lorsque la version est créée, puis installée, dans un environnement cible. Il s'agit d'une fonctionnalité puissante, mais elle doit être utilisée avec prudence. Vous ne souhaitez certainement pas remplacer les données de production de qualité par toutes les données créées par les développeurs. Vous pouvez en savoir plus sur ces options sur notre Créer une page de documentation de package de version.

• Les rôles:

  L'accès à une page, ainsi que les capacités natives de création/modification/suppression des données présentées à un utilisateur sur une page, sont contrôlés de manière granulaire dans la couche logique. Chaque fois qu'un développeur modifie les rôles d'une règle métier ou introduit une nouvelle règle métier dans une page, cela peut avoir un effet inattendu sur la capacité d'un groupe d'utilisateurs particulier à accéder à la page. La création d'un utilisateur de test pour chaque groupe d'utilisateurs et le test de régression pour les rôles sont une excellente pratique avant toute mise en production. Cela vous aidera à éviter le redoutable e-mail « Je ne peux plus accéder à cette page » de votre utilisateur final le lendemain d'une mise en production. cette page de documentation pour plus d'informations sur les privilèges et les autorisations.

Chaque fois que vous allez libérer votre Jitterbit App Builder application, examinez attentivement le modèle de publication. Vous ne devez publier que les composants de l'application qui ont changé et que vous souhaitez publier en production.

Dans votre modèle de publication, vous pouvez choisir ces différents composants. Vous pouvez bien sûr publier une application entière qui inclura toutes les sources de données, la logique et les pages. Ou si votre modification était à plus petite échelle, vous pourriez publier une seule page ou une seule règle métier et publier ces composants plus petits en production, laissant le reste de l'application tel quel. Cette flexibilité dans la processus de libération permet à votre équipe de développement de répondre plus facilement à tous les problèmes critiques qui surviennent lors du travail sur des demandes plus importantes.

La fonctionnalité de composant d'application améliore la flexibilité, la rapidité et le contrôle du processus de déploiement du logiciel, ce qui en fait un outil puissant dans les environnements qui nécessitent des mises à jour fréquentes et des temps d'arrêt minimes. Les principaux avantages pour vos équipes de développement sont les suivants :

• Mises à jour modulaires :

  Permet de mettre à jour indépendamment des composants spécifiques d'une application, réduisant ainsi les dépendances de code.

• Temps d'arrêt minimisé :

  Seuls les composants modifiés sont mis à jour, permettant des mises à niveau plus fluides.

• Une plus grande agilité de développement :

  Les équipes peuvent publier rapidement des mises à jour ou des correctifs pour des composants individuels, augmentant ainsi le temps de réponse.

En savoir plus sur le Jitterbit App Builderou de la une puissante suite de fonctionnalités d'IA bientôt disponible sur App Builder 4.0.