Adobe Campaign fait l'objet de mises à jour régulières. Si vous connaissez les notes de mise à jour que nous publions, vous savez probablement déjà que nous proposons en moyenne deux à trois versions mineures par an contenant de nouvelles fonctionnalités, des améliorations et des correctifs. En outre, nous publions périodiquement des builds avec des correctifs cumulatifs uniquement. Cette cadence régulière de mises à jour vise à vous proposer les fonctionnalités les plus appropriées et les plus récentes, en préservant la sécurité de votre environnement et en améliorant votre expérience avec notre produit.
C'est pourquoi il est essentiel que nos clients exécutent la version la plus récente d'Adobe Campaign. Nous pouvons ainsi vous aider plus efficacement si vous rencontrez des problèmes ; l'identification, la reproduction et la résolution d'un problème sur un ancien build prend généralement plus de temps, sans compter que vos éventuels problèmes peuvent avoir été corrigés dans un build récent.
En tant qu’utilisateur hébergé, vous bénéficiez automatiquement de la mise à niveau annuelle de Campaign avec la dernière version stable, et n’avez aucune action à effectuer. Les clients On-premise et hybrides peuvent également bénéficier de cette version. Si vous migrez depuis un ancien build, nous vous recommandons d’effectuer d’abord la mise à niveau vers cette version. En savoir plus.
Un upgrade de build, c'est lorsque le logiciel Adobe Campaign Classic est mis à jour vers le numéro de build sécurisé le plus récent, tout en restant au même niveau de build majeur/mineur. Par exemple : Campaign Classic v7 build 9026 vers Campaign v7 build 9032.
En savoir plus dans cette section.
La version la plus récente de Campaign Classic, y compris les nouvelles fonctionnalités et la documentation, est présentée dans les dernières notes de mise à jour.
Déterminez votre version dans le menu Aide > A propos… de la console cliente Adobe Campaign. La boîte de dialogue A propos contient des informations détaillées sur la version et le build que vous exécutez sur la console et le serveur.
En savoir plus dans cette section.
Depuis Campaign Classic 19.2, un statut est associé à chaque build.
En savoir plus dans cette section.
Non. Une mise à niveau de build est une mise à jour incrémentale au sein d’une version majeure donnée, tandis que mise à niveau de version correspond au passage d’une version majeure à une autre. Les mises à niveau de build sont simples, car ils n’impliquent généralement aucun changement majeur du point de vue technique, architectural ou des modèle de données.
En revanche, les mises à niveau de version s’accompagnent souvent de changements techniques importants et, selon le niveau de configuration d’un client donné, peuvent nécessiter des changements notables de la configuration et/ou une nouvelle implémentation partielle.
Par exemple, si l'on reprend les informations de serveur figurant dans la capture d'écran de la section précédente :
Une mise à niveau de build signifierait passer de la build 9342 à n’importe quelle build supérieure à 9342. Par exemple, de v7.1 build 9342 à v7.1 build 9342.
Une mise à niveau de version signifierait passer de la version 6 à n’importe quelle version plus récente. Par exemple, de v6.1.1 build 8666 à v7.1 build 9342.
Adobe réalisera une sauvegarde de votre système avant tout changement. Toutefois, si votre système hors production (serveurs de développement ou de test) a fait l’objet de personnalisations critiques, nous vous RECOMMANDONS FORTEMENT d’exporter ces personnalisations sous la forme d’un package avant toute mise à niveau.
Les clients pourront effectuer un choix parmi plusieurs dates. Les changements des systèmes de production ne sont pas effectués les jours fériés.
Les upgrades de build peuvent être réalisés du lundi au jeudi, le vendredi étant réservé aux instances hors production.
La durée de l'upgrade de build dépend de plusieurs facteurs :
L'upgrade de build est un processus en deux étapes :
Préparation du système à l'upgrade : tenant compte des spécificités de votre environnement, cette phase conduit essentiellement à un upgrade complet sur un environnement hors production. Une fois l'environnement mis à niveau validé du point de vue technique et fonctionnel, il est possible de passer à la phase 2. En fonction des facteurs mentionnés ci-dessus, la première phase peut prendre entre plusieurs jours et deux semaines.
L'upgrade lui-même : l’environnement de production est mis à niveau. Cette phase prend généralement quelques heures. Dans le cas d'environnements très complexes, vous devez prévoir un temps d’arrêt plus long. En cas de problème, une stratégie de restauration est définie et peut être exécutée.
Pour plus d'informations, voir ce document.
L'upgrade de build requiert les ressources suivantes :
Dans vos systèmes de développement et d’évaluation, exportez tous les travaux critiques et qui doivent être préservés.
Rafraîchissez vos connaissances des workflows de chemin critique et des diffusions développées dans vos runbooks (ou par votre équipe/partenaire consultant) en consultant la documentation fournie à votre équipe au terme de l'implémentation.
Identifiez les heures de faible volume ou trafic qui seraient idéales pour les fenêtres de maintenance, car elles auront le plus faible impact sur l’entreprise.
Consultez notre liste de contrôle d'upgrade de build ci-dessous et vos plans de test, et vérifiez que les ressources qui peuvent réaliser ces tests sont disponibles dans les 24/48 heures suivant un upgrade.
Pour plus d’informations, consultez cette section.
Les upgrades peuvent être réalisés en dehors des heures de bureau. Nous recommandons toujours d'effectuer un upgrade de l'environnement en dehors des heures de bureau lorsqu'aucun utilisateur d’entreprise n'est connecté à l'instance.
L'installation de l'upgrade de build n’engendre aucun coût pour les clients hébergés. Si le système comprend des développements personnalisés, le client devra identifier les ressources nécessaires pour les tester après l'upgrade et corriger les éventuels problèmes associés.
Non. Le serveur est arrêté au cours d'un upgrade de façon à assurer l'intégrité des données lors de cette opération. Une fois l'upgrade terminé, il est redémarré et tous les services reprennent.
Lorsque l'upgrade s’applique à Message Center (RT), celui-ci n'enverra pas d'emails à partir de l'instance. Notez que tout processus arrêté lors de l'arrêt d'un système Campaign est repris automatiquement au redémarrage du système. Cela comprend les diffusions actives ou planifiées, le suivi ainsi que les calculs des mesures pour les diffusions envoyées précédemment.
Non. Au cours de l'upgrade de build, les services de workflow et de messagerie sont arrêtés. Cela signifie que les workflows ne s'exécuteront pas et que les diffusions ne sont pas envoyées. Ils reprendront une fois le système redémarré. Cependant, Adobe vous conseille fortement de vérifier les workflows de chemin critique après un upgrade pour vous assurer qu'ils s'exécutent correctement.
Les liens de tracking présents dans les e-mails déjà envoyés ne fonctionneront pas pendant la mise à niveau, car tous les serveurs sont arrêtés. Ils seront à nouveau opérationnels une fois la mise à niveau terminée et les serveurs redémarrés.
Oui. Les clients doivent indiquer à Adobe un point de contact disponible au cours de l'upgrade ou immédiatement après l'upgrade de leur instance de production. Adobe contactera cette personne par email en l’absence d’autres arrangements. Cela assurera une transition fluide et une validation immédiate des tâches critiques. Adobe contactera le client une fois l'upgrade de build terminé pour confirmation.
Oui. La console cliente doit présenter le même build que l'instance de serveur. Une fois l'upgrade réalisé, votre console cliente doit vous inviter à effectuer un upgrade vers le build le plus récent afin de vous assurer qu'elle reste alignée sur le build du serveur.
Le plan de restauration consiste à restaurer le système avec la sauvegarde la plus récente disponible. Les sauvegardes sont stockées pendant 7 jours pour les clients du centre de données et pendant 14 jours pour les clients sur Amazone Web Service (AWS).
Elle dépend de la taille de sauvegarde de la base de données. La durée moyenne est de 4 heures.
Reportez-vous à la liste de contrôle d’upgrade de build ci-dessous.
Les environnements de développement et de test sont mis à niveau en séquence ou ensemble, mais une signature est nécessaire avant l'upgrade de l'instance de production. Chaque client peut ainsi réaliser des tests avant de valider tout changement pour son passage en production.
Reportez-vous à la liste de contrôle d'upgrade de build ci-dessous. Les clients doivent exécuter des tests similaires ainsi que d'autres qui peuvent être nécessaires pour l'environnement.
Pour assurer un niveau optimal de performances, de disponibilité et de sécurité du système, Adobe collaborera avec les clients en vue d'assurer que les systèmes sont mis à niveau au moins une fois par an.
Oui. Le serveur est arrêté au cours d'un upgrade de façon à assurer l'intégrité des données lors de cette opération. Une fois l'upgrade terminé, le serveur est redémarré et tous les services reprennent.
Si vous rencontrez des problèmes après un upgrade de build, contactez l'assistance clientèle d'Adobe. Cette équipe planifie les dates de build et ouvre les tickets correspondants.
En savoir plus dans Options d'aide et de support pour Campaign Classic
Est-il possible de se connecter au serveur ? Vérifier que la console cliente Campaign fonctionne sans erreur/message d'avertissement.
Veiller à utiliser la même version de console que la version de build après l'upgrade.
Des applications web insèrent-elles des données dans la base de données Campaign ? Si tel est le cas, les exécuter et vérifier qu'elles peuvent insérer de nouveaux enregistrements via l'API.
Est-il possible d'envoyer un email de test ? Créer une diffusion à l'aide d'un modèle connu, l'envoyer à un destinataire de test et vérifier que la personnalisation, le lien de désabonnement et la page miroir fonctionnent.
Tous vos workflows de chemin critique sont-ils exécutés ? Vérifier les workflows, ouvrir un journal de workflow et vérifier qu'il n'y a pas d'erreur.
Tous vos dossiers sont-ils présents, visibles et accessibles ? Accéder aux différents dossiers et vérifier que l'ensemble
du contenu est présent et s'affiche.
Toutes vos diffusions sont-elles effectuées dans le fuseau horaire approprié ?
Voir aussi