Directives générales pour la planification du processus de mise à jour
Une rubrique de référence qui contient des directives générales pour créer un processus standard de déplacement des personnalisations d’une instance à l’autre.
-
Utilisez un chemin d’accès standard pour les ensembles de mises à jour : migrez du développement vers le test, puis du test vers la production. Évitez de déplacer le même ensemble de mises à jour à partir de plusieurs sources.
- Vérifiez que les deux instances sont sur la même version. Bien qu’il soit possible de déplacer un ensemble de mises à jour d’une instance d’une ancienne version vers une instance d’une version plus récente, cela augmente la probabilité de problèmes. Les personnalisations peuvent ne pas fonctionner si elles reposent sur du code qui a changé entre les versions.
- Modifiez un ensemble de mises à jour unique pour chaque petite ou moyenne tâche. Les ensembles de mises à jour volumineux avec des changements de schéma ou des révisions majeures du workflow sont plus difficiles à examiner, plus lents à traiter, plus sujets aux conflits et plus longs à prévisualiser ou à valider.
-
Assurez-vous que tous les enregistrements du système de base ont des champs sys_id cohérents. Certains enregistrements du système de base peuvent être générés sur une instance après la mise en service, ce qui entraîne des différences entre les instances et des complications potentielles avec les ensembles de mises à jour.
-
Planifiez des validations d’ensembles de mises à jour en dehors des heures ouvrables pour éviter de ralentir l’instance de production. Toute performance réduite est brève.
- Utilisez des noms d’ensembles de mises à jour clairs et établissez une convention de nommage pour coordonner les changements des développeurs et rationaliser le référencement lors des validations.
- Si des ensembles de mises à jour sont générés en tant que correctifs de problèmes, envisagez d’inclure le ticket de problème dans le nom. Par exemple, PR10005 : correction de problèmes d’e-mails en double.
- Si vous avez besoin de plusieurs ensembles de mises à jour pour résoudre un problème, incluez un numéro de séquence dans la convention de dénomination. Les conventions de dénomination séquencée confirment que les ensembles de mises à jour sont appliqués dans l’ordre dans lequel ils ont été créés. Par exemple, PR10005 : correction des problèmes d’e-mail en double et PR10005.2 : correction des problèmes d’e-mail en double.