Skip to content

Comment le déploiement des métadonnées d’ensemble d’autorisations change-t-il dans Summer ’17 (API 40.0) ?

Solution:

En récupérant entièrement toutes les autorisations à tout moment, cela évitera les diverses mauvaises choses qui se produisent lorsque vous ne récupérez qu’un package partiel. Cela conduirait à fausser le fichier XML à devenir très grand/petit simplement en fonction de la façon dont l’outil que vous utilisez a décidé de récupérer les métadonnées de votre organisation (par exemple, une récupération partielle entraînerait un ensemble d’autorisations partiel, provoquant des changements artificiels que vous auriez pour continuellement revenir en arrière, fusionner, résoudre des conflits, etc.). En d’autres termes, votre système de contrôle de source sera heureux, les fusions seront heureuses, les déploiements seront heureux (au moins, en théorie).

Cela fait partie d’un changement plus important qui a fait l’objet de rumeurs, où nous pourrons éventuellement pointer une arborescence de contrôle de source vers une organisation et dire “faire de cette organisation exactement comme spécifié à partir de ce contrôle de source.” Plus de surprises inattendues, puisque nous pourrons littéralement recréer une organisation telle qu’elle existait à n’importe quel point du système de contrôle de source, potentiellement même au point de supprimer des classes, des pages, des champs, des objets, etc. Bien entendu, tout cela fait partie de la nouvelle expérience Salesforce DX. Salesforce souhaite que les développeurs, en particulier les éditeurs de logiciels indépendants, disposent de capacités de déploiement modernes, et un déploiement cohérent fait partie de cette vision.

Il est possible de récupérer à partir de la version 40 et de déployer en tant que version inférieure, mais la récupération en tant que version inférieure (par exemple 39) et le déploiement en tant que 40 peuvent supprimer les autorisations précédemment définies en dehors du contrôle de source. C’est une bonne chose, car nous n’aimons pas les autorisations inattendues, mais cela signifie que vous devez d’abord obtenir une récupération propre. Ne déployez un fichier utilisant 40 ou plus que si vous êtes certain qu’il a été récupéré à partir de 40 ou plus. Votre package.xml indique la version avec laquelle l’API s’exécute. De manière réaliste, il s’agit d’un changement de contrôle unique par source que les développeurs devront effectuer.

L’IDE Force.com capturera automatiquement les nouveaux ensembles d’autorisations dans le cadre de l’assistant de mise à niveau qui apparaît avec chaque nouvelle version, il y a donc peu de risque que quelque chose se passe mal. Les développeurs utilisant d’autres systèmes, comme la boîte à outils de migration, doivent s’assurer que la première chose qu’ils font après le passage à la version 40 est une actualisation complète avant d’effectuer des déploiements basés sur des ensembles d’autorisations.

Voici ce que je déduis de l’e-mail et de mon expérience avec l’API de métadonnées Salesforce

L’ensemble d’autorisations n’a pas de version d’API liée dans le fichier XML de métadonnées. Ainsi, la question de savoir comment déterminer la version de l’ensemble d’autorisations ? C’est la version de package.xml que nous devons connaître.

Alors répondons aux questions

1.Comment pouvez-vous déterminer la version API de n’importe quel outil pour voir lequel des deux comportements sera appliqué ?

C’est à partir de la version package.xml .

<version>37.0</version>

2. Que se passera-t-il si vous récupérez des métadonnées sur les ensembles d’autorisations à partir de la version 39.0, puis déployez ces métadonnées avec la version 40.0 ?

Étant donné que vous déployez avec la v40.0 alors que vous avez récupéré en utilisant 39.0, aucun remplacement ne devrait se produire. pourrait potentiellement écraser .

3.Comment cela bénéficiera-t-il au stockage des métadonnées de l’ensemble d’autorisations dans le contrôle de source ?

La dépendance est également maintenue automatiquement dans votre contrôle de source sans que vous ayez à vous soucier manuellement d’ajouter des métadonnées de dépendance au contrôle de source.

Pour tester cela dès que j’aurai l’organisation v40.0, l’organisation pré-publiée de l’été 17, vous devrez créer un package non géré avec un ensemble d’autorisations ajouté et cliquer sur ajouter des dépendances devrait ajouter toutes les métadonnées dépendantes liées à l’ensemble d’autorisations automatiquement ou je suppose que salesforce ajoutera automatiquement toutes les métadonnées dépendantes pour nous. C’est une cohérence pour moi quelle plate-forme manquait depuis longtemps.



Articles Similaires

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.