Vous êtes ici :
Meilleures pratiques du projet DevOps Center
Suivez les meilleures pratiques ci-dessous pour planifier votre projet DevOps Center. Project est un espace de travail centralisé qui permet de gérer et de déployer une collection distincte d'éléments de travail associés.
Éditions requises
| Disponible avec : Lightning Experience dans les éditions Professionnel (accès API requis), Entreprise, Performance, Unlimited et Developer |
| Pas disponible avec : Government Cloud Plus. Pour plus de détails, contactez votre chargé de compte Salesforce. |
| Pas disponible avec : La zone EU Operating. La zone EU Operating est une offre payante spéciale qui fournit un niveau d'engagement de résidence des données avancé. Le Centre DevOps est pris en charge dans les organisations de l'Union Européenne qui ne font pas partie de la Zone opérationnelle de l’Union européenne, selon les conditions et les termes de produit standard. |
Détermination du nombre de projets
Utilisez un projet unique et un référentiel unique lorsque :
- Les équipes travaillent sur des métadonnées et des données de configuration identiques ou dépendantes.
- Toutes les modifications sont déployées dans la même organisation de production.
- Vous avez besoin d'une visibilité unifiée sur l'ensemble du travail.
- Le développement implique des objets et des fonctionnalités interconnectés.
Créez des projets séparés lorsque :
- Les équipes travaillent sur des métadonnées et des données indépendantes sans dépendance.
- Les modifications sont déployées dans différentes organisations de production.
- Les projets suivent des calendriers de publication et une gouvernance séparés.
- Vous avez besoin de pipelines de correctifs isolés pour contourner les cadences de publication standard.
- Les équipes ont besoin d'un isolement opérationnel ou préfèrent restreindre la visibilité sur le travail actif et les changements d'une autre équipe.
Sélection de votre stratégie de cycle de vie de projet
Choisissez un cycle de vie de projet basé sur vos processus de gestion des versions et votre cadence.
Projets en cours : Utilisez le même projet à travers plusieurs sprints et versions. C'est l'approche recommandée pour les équipes qui développent en permanence des fonctionnalités et des métadonnées et une étendue de données stables. Ces projets sont plus faciles à gérer. Par exemple, les projets de longue durée sont idéaux pour une équipe qui publie toutes les deux semaines et utilise un pipeline, quel que soit le sprint. Vous pouvez suivre les performances d'un projet en utilisant les métriques et l'historique DORA dans Historique des activités.
Projets par version : Créez un projet pour chaque version majeure. Cette approche est plus efficace pour les équipes qui ont des initiatives discrètes et limitées dans le temps ou des versions majeures. Cela nécessite un travail de configuration supplémentaire pour chaque version. Nous recommandons d'archiver les projets après la publication.
Projets de correctifs : Pour les problèmes critiques de production, utilisez un projet de correctif séparé afin d'accélérer l'exécution.
- Créez un projet et connectez-vous à un pipeline qui contient au moins un environnement de développement, une étape de test et une organisation de production.
- Après avoir résolu le problème, déplacez toutes les modifications dans votre pipeline de projet standard et gardez tous les environnements synchronisés.
- Toujours synchroniser les modifications de votre projet principal afin d'éviter les divergences de branche.
Gestion des projets inactifs
Vous ne pouvez pas supprimer un projet dans DevOps Center Ajoutez un préfixe z_ à votre projet inactif. Par exemple, z_MyOldProject. Cela place le projet en bas de la liste.
Configuration du fichier .forceignore
Le fichier .forceignore détermine les modifications que DevOps Center exclut lors de l'engagement et du déploiement. Configurez le fichier .forceignore dans la branche principale avant d'élaborer votre pipeline afin de le propager à toutes les branches de fonctionnalité. Pour modifier un fichier .forceignore, appliquez les modifications dans la branche de fonctionnalité des éléments de travail. Les modifications se propagent dans votre pipeline à mesure que vous faites la promotion de l'élément de travail. Consultez Exclusion de métadonnées avec un fichier .forceignore.
Recommandations de stratégie de projet DevOps Center
| SCÉNARIO | Recommandation | Exemple |
|---|---|---|
| Même organisation de production avec des métadonnées et des données superposées. | Un projet, une structure de référentiel | Une équipe de plate-forme personnalise les objets interconnectés. Votre équipe développe des fonctionnalités Sales Cloud, dans lesquelles les développeurs personnalisent l'objet Opportunité pendant que d'autres travaillent sur des Campagnes. Les deux fonctionnalités utilisent des objets personnalisés partagés. Utilisez un seul projet, car les métadonnées se chevauchent. |
| Même organisation de production avec des métadonnées et des données indépendantes. | Une structure de projet (préféré) | Suivis de travail parallèles où une équipe Apex et une équipe de connecteur Marketing Cloud se déploient dans un environnement partagé. |
| Organisations de production géographiquement ou opérationnellement distinctes. | Projets séparés | Déploiements indépendants dans des organisations de production séparées en Europe et aux États-Unis en raison des exigences de résidence des données. Les organisations contiennent des applications similaires, mais se déploient indépendamment. Créez deux projets, un pour chaque organisation de production. |
| Urgent, chemin du pipeline correctif requis. | Projet de correctif séparé | Correctifs critiques qui nécessitent un parcours isolé pour contourner le cycle de publication standard. |
