Andrew Hanna

Mis à jour il y a 4 mois

Packages Salesforce managés vs non managés

Introduction

En tant qu’ingénieur ou consultant Salesforce, choisir entre créer des packages managés ou non managés est une décision stratégique qui peut fortement influencer vos workflows et le cycle de vie de vos applications sur Salesforce. Ce guide approfondit chaque type de package et présente leurs cas d’usage, avantages et points d’attention pour vous aider à faire un choix éclairé selon vos besoins.

Que sont les packages managés et non managés ?

Les packages managés sont généralement créés par des partenaires Salesforce et disponibles via Salesforce AppExchange. Ils incluent un namespace qui les isole complètement de votre org et des autres packages, évitant les conflits de nommage entre orgs Salesforce, mais avec ses propres limites.

Les packages non managés sont souvent utilisés pour distribuer des projets open source ou des modèles que les développeurs peuvent personnaliser. Ils n’incluent pas de namespace, ce qui les rend entièrement modifiables, mais aussi plus exposés aux conflits de nommage. Les packages non managés sont un bon moyen de versionner la personnalisation et le développement de votre org tout en les gardant ouverts, ce qui permet aussi de référencer des métadonnées et du code déjà présents dans votre org cible.

Chez Tekunda, nous avons simplifié les processus de gestion et de release des packages managés et non managés avec Tekunda Serpent. Notre outil rend la gestion des métadonnées et des packages fluide, afin que vous puissiez vous concentrer sur l’innovation plutôt que sur l’administration. Prêt à rationaliser votre expérience de développement Salesforce ?

Commencer gratuitement - sans carte bancaire maintenant et faites partie des premiers à transformer votre workflow avec Tekunda Serpent !

Comparaison détaillée

Configuration et personnalisation

Packages managés
- Cas d’usage : Idéals pour des applications comme les intégrations tierces ou l’extension de Salesforce avec un package autonome. Par exemple, créer ou installer un outil prêt à l’emploi d’automatisation marketing ou une application de service client.
- Avantages : Ils sont verrouillés, ce qui signifie que les composants principaux ne peuvent pas être modifiés, garantissant l’intégrité et le support du fournisseur.
- Points d’attention : Une personnalisation limitée peut ne pas convenir à tous les besoins propres à l’entreprise.
Packages non managés
- Cas d’usage : À privilégier lorsqu’une solution très adaptée est nécessaire, comme le développement d’une application propre à vos processus métier ou la création de modèles modifiables pour différents environnements clients.
- Avantages : L’accès complet au code permet aux développeurs de modifier n’importe quel aspect du package pour répondre précisément à leurs exigences.
- Points d’attention : Ils exigent une connaissance plus poussée du développement Salesforce et peuvent entraîner des délais de déploiement plus longs.

Support et maintenance

Packages managés
- Ils fournissent le support du fournisseur, des mises à jour régulières et des garanties de compatibilité avec les nouvelles releases Salesforce, réduisant la charge administrative pour le client ou l’utilisateur.
Packages non managés
- La maintenance et les mises à jour relèvent du client ou de l’utilisateur, ce qui peut accroître la charge de l’équipe IT et les rend adaptés aux projets internes ou de conseil.

Déploiement et mises à jour

Packages managés
- Ils sont rapides à déployer car préconfigurés. Les mises à jour sont gérées par le fournisseur et déployées sans friction dans l’environnement du client ou de l’utilisateur.
Packages non managés
- Ils exigent une intégration et des tests soigneux, surtout lors des mises à jour, pour éviter toute interférence avec les personnalisations existantes.

Choisir le bon package pour vos besoins

Lorsque vous choisissez entre packages managés et non managés, considérez :

Complexité du projet et besoins de personnalisation : Si votre projet exige une personnalisation poussée, le non managé peut être préférable. Pour les projets autonomes, les packages managés peuvent faire gagner du temps et des efforts.
Disponibilité des ressources : Disposez-vous des personnes qualifiées pour gérer les complexités potentielles liées aux packages non managés ?
Contraintes budgétaires : Les packages managés peuvent sembler plus chers au départ, mais il faut considérer le coût total de possession, y compris la maintenance et les futures mises à niveau.
Délai de mise sur le marché : Les packages managés permettent un déploiement plus rapide, ce qui peut être crucial pour les projets urgents.

Implications CI/CD pour les packages managés et non managés

L’intégration continue et le déploiement continu CI/CD sont des composants critiques du développement logiciel moderne, surtout dans des environnements dynamiques comme Salesforce. Le choix entre packages managés et non managés peut avoir des implications importantes sur vos stratégies CI/CD.

CI/CD dans le développement de packages managés

Les packages managés sont généralement créés par des développeurs qui souhaitent distribuer leurs applications sur Salesforce AppExchange, souvent avec une logique commerciale. Voici les principaux points d’attention pour le CI/CD :

Contrôle de version et gestion des releases : Les packages managés doivent respecter les processus Salesforce de mise à niveau et de gestion des releases, plus structurés pour garantir la compatibilité et le support. Les développeurs doivent gérer le versioning avec précision, car les versions de package sont immuables une fois publiées.
Préfixe de namespace : Chaque package managé possède un préfixe de namespace qui l’identifie de façon unique dans toutes les orgs Salesforce. Ce namespace doit être géré avec soin dans le contrôle de source pour assurer la cohérence entre les environnements de développement et de production.
Tests bêta et versions de patch : Les pipelines CI/CD pour les packages managés incluent souvent la création de versions bêta pour les tests et de versions de patch pour corriger les problèmes après release. L’automatisation de ces processus aide à maintenir la stabilité du package.
Gestion des licences : L’intégration de cadres de licence est essentielle pour les packages managés, surtout s’ils sont commerciaux. Votre processus CI/CD peut devoir inclure des étapes de mise à jour des mécanismes de licence dans le pipeline de déploiement.

CI/CD dans le développement de packages non managés

Les packages non managés sont plus flexibles et souvent utilisés pour des projets personnalisés au sein d’une org spécifique ou pour distribuer des projets open source où le développeur ne conserve aucun contrôle propriétaire. Les points d’attention CI/CD incluent :

Contrôle complet du code : Les développeurs ont un contrôle complet du code source, ce qui facilite la mise en place de pratiques CI/CD comme les tests automatisés, les contrôles de style et les évaluations de qualité du code sans restriction.
Flexibilité des mises à jour : Les packages non managés permettent aux développeurs d’appliquer directement des mises à jour et des changements à tout moment, en soutenant les pratiques agiles. Des outils d’automatisation peuvent fluidifier le déploiement de nouvelles fonctionnalités et corrections.
Aucune gestion de namespace : L’absence de namespace dans les packages non managés simplifie certains aspects du versioning et de la gestion du code source, réduisant la charge liée à ces éléments dans les pipelines CI/CD.
Scripts de déploiement personnalisés : Les développeurs peuvent créer des scripts personnalisés et utiliser des outils CI/CD comme Jenkins, CircleCI ou GitHub Actions pour automatiser les processus de build et de déploiement selon les besoins propres à leur organisation.

Choisir la bonne stratégie

Le choix entre développer un package managé ou non managé dépend souvent du cas d’usage visé et de la stratégie de distribution :

Distribution commerciale : Si vous prévoyez de vendre votre application sur AppExchange, un package managé est nécessaire. Vos pipelines CI/CD doivent prendre en charge des tests stricts et des contrôles de conformité pour respecter les standards Salesforce.
Usage interne ou open source : Pour les packages destinés à un usage interne ou à une distribution open source sans intention commerciale, les packages non managés offrent plus de flexibilité et une intégration plus simple dans des workflows CI/CD personnalisés.
Évaluer la complexité : Tenez compte de la complexité de votre environnement Salesforce. Un environnement simple peut bien fonctionner avec des packages managés, tandis qu’un environnement complexe et fortement personnalisé peut mieux tirer parti des packages non managés.
Évaluer les compétences de l’équipe : Assurez-vous que votre équipe possède les compétences nécessaires pour gérer le type de package choisi dans les pipelines CI/CD. Les packages non managés exigent de solides compétences DevOps pour exploiter pleinement leur flexibilité.
Considérer la maintenance à long terme : Évaluez l’impact de chaque option sur la maintenance et la scalabilité à long terme. Les packages managés réduisent la charge de maintenance au prix d’une flexibilité moindre, tandis que les packages non managés offrent de la flexibilité mais exigent un effort de maintenance continu.

Conclusion

Les packages managés et non managés offrent chacun des avantages distincts aux administrateurs et développeurs Salesforce. En évaluant soigneusement vos besoins organisationnels, vos ressources disponibles et votre stratégie long terme, vous pouvez choisir un package qui répond à vos besoins immédiats tout en soutenant la croissance et l’évolution de votre environnement Salesforce.

Faire un choix éclairé permettra à votre équipe d’exploiter Salesforce plus efficacement, de maximiser les bénéfices de la plateforme et de rester alignée sur vos objectifs métier.

FAQ

Quelle différence entre packages managés et non managés ?

Un package managé porte un namespace qui l'isole du reste de l'org, et ses composants centraux sont verrouillés. Un package non managé n'a pas de namespace, reste entièrement modifiable après installation et peut créer des conflits de noms.

Peut-on modifier le code d'un package managé ?

Non. Ce verrouillage est précisément ce qui permet à l'éditeur de garantir l'intégrité et de livrer des mises à jour sans risque. S'il vous faut modifier chaque partie du code, choisissez un package non managé.

Quel type de package faut-il pour vendre sur AppExchange ?

Un package managé. La distribution commerciale s'appuie sur le namespace et sur le processus de release Salesforce, alors prévoyez une CI/CD capable d'absorber des tests et des contrôles de conformité plus stricts.

Quand choisir un package non managé ?

Pour du travail qui reste dans une seule org, pour des livrables de conseil et pour des modèles ou projets open source destinés à être adaptés. Vous gardez la source complète, et la maintenance avec.