Consultation des notes de publication

Planification

Les équipes examinent et planifient ce qu’elles souhaitent effectuer dans le cadre de la prochaine version majeure. Elles passent en revue les listes de souhaits en matière de produits, les idées de produit sur IdeaExchange et les problèmes connus.

• Vous avez une bonne idée concernant une fonctionnalité pour un produit ? Accédez à la section Marketing sur IdeaExchange pour nous en parler.
  
• Vérifiez le statut des problèmes connus sur le site des problèmes connus de Salesforce.
  

Développement agile

Une fois qu’un plan est en place, les équipes organisent le travail en sprints au cours desquels elles se concentrent sur des fonctionnalités spécifiques à créer et à tester. Le cycle de développement prend fin au gel des fonctionnalités, date à laquelle toutes les fonctionnalités incomplètes sont supprimées de la version à venir.

• Créez, testez, puis repartez ! Toutes les fonctionnalités sont soumises à une série de tests unitaires, fonctionnels et de performances avant d’être ajoutées à une version.
  
• Après le gel des fonctionnalités, les équipes recommencent le processus pour le développement de la prochaine version.
  

Release Readiness

Lors du gel des fonctionnalités, seules les fonctionnalités terminées qui ont été testées, validées et approuvées sont incluses dans la version.

• Des tests supplémentaires sont effectués, notamment des tests de rétrocompatibilité, des tests d’intégration, des tests fonctionnels, la validation de la base de données et du script de déploiement, ainsi que la validation du cas d’utilisation client.
  
• Plusieurs équipes doivent approuver les mises à jour.
  

Publication échelonnée des versions

Une fois approuvées, les nouvelles fonctionnalités de Marketing Cloud Engagement sont publiées de façon échelonnée. Tous les clients reçoivent les mises à jour de version au cours de la première publication de version (P1) ou de la seconde publication de version (P2).

• Avant de lancer la P1, nous disposons d’une version interne (P0) pour permettre aux équipes internes dotées de comptes Salesforce Marketing Cloud Engagement d’effectuer encore plus de tests.
  
• Environ 25 % des clients sont inclus dans la P1 en fonction de leur instance de base de données.
  
• Les 75 % de clients restants sont inclus dans la P2.
  

2 à 3 semaines avant la publication de la version

Pendant les activités de préparation à la publication de version :

• Nous rencontrons les dirigeants pour examiner les guides de test et de préparation.
  
• Nous obtenons les approbations des dirigeants pour les versions.
  
• Nous résolvons tous les problèmes fonctionnels en attente.
  
• Nous finalisons les composants de déploiement.
  

1 à 2 jours avant la publication de la version

Pendant les activités en amont de la publication de la version :

• Nous effectuons des mises à jour de schéma SQL rétrocompatibles (ce qui signifie essentiellement que nous nous préparons au pire, en veillant à ce qu’il existe une option de restauration en cas de problème).
  
• Nous nous préparons à ne subir aucun temps d’arrêt ni aucune perturbation.
  

Jour de la publication de la version

Pour garantir une incidence minimale :

• Nous déployons les mises à jour de base de données et de code à 12 h 00 EST le jour de la publication de la version (qui a toujours lieu un samedi aux États-Unis). Ce jour et cette heure ont été sélectionnés, car ils présentent le plus faible trafic client.
  
• Nous effectuons des validations de données automatiques et manuelles juste après la publication de la version à des fins d’assurance qualité.
  

1 jour après la publication de la version

Nous effectuons des vérifications concernant :

• La fiabilité du site, le support, la gestion des versions et l’ingénierie pour vérifier la présence de problèmes ouverts liés à la version.
  

Nous utilisons :

• Des outils de surveillance pour identifier et résoudre de manière proactive les problèmes avant que les clients ne soient touchés.
  

Continu

Les bugs font l’objet de recherche et d’un examen pour détecter d’éventuelles corrections. Une fois qu’une correction a été identifiée et que les modifications de code ont été apportées, celles-ci sont testées minutieusement.

2 jours avant la publication de la version

Les correctifs approuvés sont verrouillés pour la prochaine version corrective. Les équipes finalisent également les composants de déploiement et valident leur plan de déploiement.

1 jour avant la publication de la version

Le nouveau code est déployé sur une instance de production interne à 14 h 00 EST. Les équipes suivent et surveillent le déploiement et effectuent des tests supplémentaires.

Jour de publication de la version (mercredi)

Le nouveau code est déployé sans temps d’arrêt* pour tous les clients à 20 h 00 EST le mercredi aux États-Unis. Des smoke tests et des validations supplémentaires ont lieu après la publication de la version.