5 conseils pour des mises en production plus efficaces

Par Tim Bond, Chef de produit

Les équipes de développement low-code consacrent un temps et une énergie considérables à la définition du périmètre et au développement du prochain ensemble de fonctionnalités pour 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 transfert de l'application d'un environnement de développement vers un environnement de test, puis vers un environnement de production ou de mise en service, est trop souvent relégué au second plan.

Avoir un plan bien établi et bien communiqué pour le déploiement d'une application en environnement de production est l'élément le plus important d'un lancement. Voici quelques points sur lesquels vous devriez réfléchir avant de procéder à tout déploiement :

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

  Travaillez avec les parties prenantes pour identifier un moment où elles seront le moins touchées. La durée est difficile à prévoir — plus vous le ferez, mieux vous parviendrez à l'estimer. Promettez moins et dépassez les attentes sur votre estimation.

• Comment les utilisateurs finaux vont-ils être impactés lors du déploiement ?

  Peu importe la qualité de votre communication concernant les versions et les temps d'arrêt planifiés à l'avance, vous devez supposer qu'un utilisateur sera dans l'application s'il le peut. Ce n'est peut-être pas un problème, mais si c'est le cas, vous pourriez 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 partagé avec l'équipe de personnes qui exécutent les étapes. Prenez le temps d'examiner le plan ensemble et soulignez qu'il n'y a pas de question stupide lorsqu'il s'agit de clarifier le plan de déploiement. Assurez-vous que chaque personne dispose des accès corrects pour exécuter les étapes qui lui sont assignées.

• Quelles nouvelles connexions ou points d'intégration avec des applications tierces sont introduits ?

  La première fois qu'une connexion ou une intégration est mise en service, il y a toujours un peu d'incertitude dans l'esprit de l'équipe. Une clé API incorrecte ou un trafic réseau bloqué pourrait perturber le plan. Les développeurs doivent veiller à le signaler à l'équipe afin que la nouvelle connexion puisse être planifiée en conséquence.

• Si la mise en production échoue, quel est le plan de repli ?

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

Vous n'avez qu'une seule chance de réussir un lancement du premier coup. Je suggère d'utiliser une version de test ou de staging comme répétition générale pour la production afin de résoudre tout problème.

En ce qui concerne les versions de l'application Jitterbit App Builder, vos développeurs créent une version à partir de l'environnement de développement, téléchargent le fichier de version (que nous appelons « fichier LP ») et le transfèrent vers l'environnement cible pour qu'il y soit installé. Il existe quelques risques courants que vous devez vérifier attentivement avant de créer la version et de l'installer en production :

• Options d'installation de la table :

  Le plus souvent, vous aurez des tables physiques incluses dans votre version. Chaque table dispose d'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 lors de la création de la version, puis de son installation dans un environnement cible. Il s'agit d'une fonctionnalité puissante, mais qui doit être utilisée avec précaution. Vous ne voulez certainement pas remplacer des 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 pour le package de publication.

• Rôles :

  L'accès à une page, ainsi que les fonctionnalités natives de création, de modification et de suppression des données présentées à un utilisateur sur une page, est contrôlé 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 sur une page, cela peut avoir un effet imprévu 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 les tests de régression pour les rôles constituent une excellente pratique avant toute mise en production. Cela vous évitera le fameux e-mail “ Je n'arrive plus à accéder à cette page ” de la part de votre utilisateur final le lendemain d'une mise en production. Consultez cette page de documentation pour plus d'informations sur les privilèges et les autorisations.

Chaque fois que vous vous apprêtez à mettre en production votre application Jitterbit App Builder, examinez attentivement le modèle de mise en production. Vous ne devez mettre en production que les composants de l'application qui ont été modifiés et que vous souhaitez déployer en production.

Dans votre modèle de version, 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 est de plus petite envergure, vous pouvez publier une seule page ou une seule règle métier et déployer ces composants plus petits en production, en laissant le reste de l'application tel quel. Cette flexibilité dans la processus de publication permet à votre équipe de développement de répondre plus facilement aux problèmes critiques qui surviennent lors du traitement 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 de logiciels, ce qui en fait un outil puissant dans les environnements qui nécessitent des mises à jour fréquentes et un temps d'arrêt minimal. Les principaux avantages pour vos équipes de développement sont :

• Mises à jour modulaires :

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

• Temps d'arrêt minimisé :

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

• Une plus grande agilité de développement :

  Les équipes peuvent déployer rapidement des mises à jour ou des correctifs pour des composants individuels, ce qui améliore le temps de réponse.

En savoir plus sur Jitterbit App Builder, ou le Une suite complète de fonctionnalités d'IA sera bientôt disponible dans la version App Builder 4.0.