Le packaging de deuxième génération (2GP) de Salesforce, expliqué

TL;DR : Le packaging de deuxième génération (2GP) est la manière moderne et pilotée par la source de Salesforce de construire et distribuer des packages managed et unlocked depuis le contrôle de version, au lieu d'une org de packaging. Il remplace le packaging de première génération (1GP) par des packages modulaires, des namespaces flexibles, des dépendances explicites et un workflow via la Salesforce CLI. Salesforce recommande désormais le 2GP pour tout nouveau développement de package managed.

Qu'est-ce que le packaging de deuxième génération (2GP) de Salesforce ?

Un package 2GP est un conteneur pour les métadonnées, le code et le schéma que vous distribuez comme une app - aux clients AppExchange (managed) ou sur votre propre parc d'orgs (unlocked). L'idée centrale est que le package est construit depuis la source dans Git, pas depuis une org de packaging à état. Salesforce précise que le managed 2GP "n'est pas simplement la version 2.0" du 1GP ; c'est un modèle de développement différent et favorable à l'automatisation, et c'est la voie recommandée pour tous les nouveaux packages.

En quoi le 2GP diffère-t-il du packaging de première génération (1GP) ?

En bref : le 1GP vit dans une org de packaging, le 2GP vit dans votre dépôt. Ce seul changement débloque le reste :

• Piloté par la source. La version du package est créée à partir de la source de votre projet, donc Git est la source de vérité.
• Modulaire. Vous pouvez répartir les fonctionnalités sur plusieurs packages au lieu d'un monolithe.
• Flexibilité des namespaces. Le même namespace peut être partagé entre plusieurs packages 2GP, même si chaque package se lie à un namespace qui ne peut pas changer après la création.
• Dépendances explicites. Les dépendances du package sont déclarées dans sfdx-project.json, pas découvertes à l'installation.
• Compatible contrôle de version et CI. Tout le flux passe par la Salesforce CLI, il s'intègre donc dans un pipeline.

Managed ou unlocked : de quel 2GP avez-vous besoin ?

Les deux sont des packages de deuxième génération construits de la même façon. Le choix concerne le public :

• Managed 2GP - pour les ISV qui distribuent sur AppExchange. Le code est protégé (IP) et le package porte un namespace enregistré.
• Unlocked packages - pour les équipes internes qui organisent les métadonnées d'une org en unités versionnées et déployables. Le code reste lisible.

Comment créer un package 2GP ? (étape par étape)

Il vous faut une org Dev Hub avec Unlocked Packages and Second-Generation Managed Packages activé, et la permission Create and Update Second-Generation Packages. Ensuite :

1. Créez la définition du package. sf package create --name MyApp --package-type Managed --path force-app --target-dev-hub DevHub
2. Créez une version depuis votre source, avec une clé d'installation et la couverture de code. sf package version create --package MyApp --installation-key test1234 --code-coverage --wait 10
3. Testez l'installation dans une org scratch ou sandbox. sf package install --package 04t... --wait 10
4. Promouvez en released une fois qu'elle passe. La promotion exige d'atteindre la couverture de code. sf package version promote --package [email protected]

Une version managed promue est celle que vous soumettez à la security review AppExchange avant que les clients puissent l'installer.

Quels sont les pièges courants du 2GP ?

• Le namespace est permanent. Choisissez-le délibérément ; un package 2GP ne peut pas changer de namespace ensuite.
• La couverture de code conditionne la promotion. Vous ne pouvez pas promouvoir une version en released sans atteindre les exigences de couverture Apex.
• Les dépendances doivent être explicites. Les dépendances non déclarées échouent à l'installation, pas au build.
• Tous les types de métadonnées 1GP ne sont pas pris en charge. Vérifiez la couverture avant de migrer un ancien package.

Comme tout le flux est CLI-first, il s'intègre dans un pipeline DevOps - là même où des outils comme Copado, Gearset, Salto, AutoRABIT, Flosum ou Blue Canvas orchestrent le contrôle de version et les tests. Pour d'autres playbooks de build et de release, voyez nos SF Guides.

FAQ

Le 2GP remplace-t-il le 1GP ?

Salesforce recommande le 2GP pour tous les nouveaux packages managed, même si les packages 1GP existants fonctionnent encore et peuvent être migrés.

Ai-je besoin d'un Dev Hub pour le 2GP ?

Oui. Activez le Dev Hub et le packaging de deuxième génération, et accordez la permission de création/mise à jour des packages avant de commencer.

Deux packages 2GP peuvent-ils partager un namespace ?

Oui. Plusieurs packages managed 2GP peuvent utiliser un même namespace, mais chaque package se lie à un namespace unique qui ne peut pas changer après la création.

Quelle est la différence entre packages managed et unlocked ?

Le managed 2GP sert à la distribution AppExchange avec protection de la propriété intellectuelle ; les unlocked packages organisent les métadonnées de votre org en unités versionnées et déployables.