• Accueil / Salesforce / Découvrez comment Salesforce.Org…
, Découvrez comment Salesforce.Org utilise DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Découvrez comment Salesforce.Org utilise DevOps1 minutes de lecture


Notre invité d’aujourd’hui est David Reed, membre principal du personnel technique, ingénierie des versions chez Salesforce.org. Il est très actif en tant que modérateur avec certaines des meilleures réponses que j’ai vues sur Échange de pile Salesforce et a de nombreuses conférences et publications que vous pouvez trouver ici.

Je travaille en tant que développeur Salesforce chez EMPAUA et un modérateur à SFXD. En tant qu’administrateur autodidacte devenu développeur, ma mission est d’interviewer les meilleures personnes de notre secteur qui m’ont aidé et inspiré au fil des ans et de partager ce que j’ai appris tout en poursuivant mon parcours dans l’écosystème Salesforce. Vous pouvez retrouver mes interviews et articles précédents ici. Vous pouvez aussi me retrouver sur LinkedIn et Twitter.

, Découvrez comment Salesforce.Org utilise DevOps<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Lire la suite: Les secrets du succès des développeurs – Entretien avec un architecte technique Salesforce chez Google

Atlas : Salut David, merci d’être avec nous aujourd’hui. Pour commencer, pouvez-vous nous parler de vous et de vos débuts dans l’écosystème Salesforce ?

David: Je travaille dans l’écosystème Salesforce depuis environ six ans maintenant. J’ai commencé ma carrière en tant qu’administrateur qui porte plusieurs chapeaux dans le domaine de la collecte de fonds à but non lucratif, en dirigeant Salesforce plus des campagnes de publipostage, en gérant des événements et en traitant des cadeaux. Mais j’écris du code depuis que je suis très jeune – ma grand-mère m’a appris le BASIC quand j’avais environ 9 ans, sur une TI 99/4A qui était probablement plus âgée que moi – puis j’ai rapidement appris Apex moi-même et je suis passé au développement. J’ai travaillé en tant que développeur, consultant et architecte dans les secteurs à but non lucratif et des services financiers avant de rejoindre Salesforce.org en 2019. J’aime prétendre (la langue un peu dans la joue) être le MVP Salesforce le plus court de tous les temps, lorsque j’ai rejoint Salesforce en même temps que son élection.

Avant de commencer à apprendre Salesforce, j’étais toujours cette personne dans une équipe non informatique pour écrire des outils pour automatiser mon travail. J’avais écrit un outil pour générer des catalogues imprimables tout en travaillant comme superviseur de bibliothèque de nuit, et sur Raiser’s Edge, j’ai construit un chargeur et un déduplicateur de données primitifs. L’une des choses qui m’ont tellement enthousiasmé par le passage à Salesforce était l’API ouverte et l’écosystème ouvert – la promesse de pouvoir pousser ce type d’outils beaucoup plus loin.

Mon travail aujourd’hui est à bien des égards mon travail de rêve. Je peux concevoir, créer et appliquer des outils plus sophistiqués, en Python, pour améliorer le développement sur la plate-forme Salesforce.

Je vis à Denver, Colorado, États-Unis. Mes intérêts non technologiques incluent le grec ancien (ma formation universitaire), les jardins botaniques, le curling et la science-fiction.

Outils open source développés par Salesforce.org

Atlas : J’ai assisté aux excellents webinaires que vous et votre équipe avez organisés, où une suite d’outils open source développée par Salesforce.org et la communauté est facilement accessible. disponible pour nous d’utiliser. Pouvez-vous nous parler un peu de ces outils ?

David: CumulusCI est la base de notre suite. Il s’agit d’un cadre permettant de définir l’automatisation au-dessus de Salesforce DX, qui facilite la création de recettes pour les organisations et les workflows Salesforce complexes. Les développeurs travaillent généralement avec CumulusCI via le
cci
interface de ligne de commande, qui vous permet d’exécuter l’automatisation pour créer, configurer et utiliser des organisations Salesforce.

Nous construisons trois applications Web sur le framework CumulusCI. MetaCI est notre harnais d’intégration continue personnalisé qui facilite l’exécution de l’automatisation CumulusCI dans CI. (CumulusCI fonctionne avec GitHub Actions, CircleCI et d’autres également ; MetaCI aide à faire évoluer et à rationaliser l’ensemble du processus). MetaDeploy est notre plate-forme de livraison client – elle alimente install.salesforce.org, ainsi que les programmes d’installation de certains autres produits intéressants (dont je ne peux pas encore vous parler de tous !). Les clients amènent leurs organisations sur MetaDeploy pour installer nos produits et profiter de notre automatisation de la configuration pour un démarrage rapide.

Metecho est notre nouvelle application qui permet aux administrateurs Salesforce et aux développeurs déclaratifs de travailler facilement dans un cycle de vie de développement moderne basé sur des organisations scratch et le contrôle de version, sans jamais toucher à une ligne de commande. Metecho est un acteur clé du programme Salesforce.org Community Sprint, où il est testé et perfectionné.

Snowfakery est un outil qui fonctionne avec CumulusCI, pour créer des données de test à grande échelle. C’est incroyable pour amorcer des environnements de développement et de test avec des données complexes et réalistes qui ne risquent jamais d’informations personnellement identifiables ou de secrets de production, et il s’adapte facilement à des centaines de millions d’enregistrements pour les tests de gros volumes de données.

Ce que j’aime le plus dans le travail sur cette suite d’outils, c’est qu’il s’agit d’un logiciel 100% gratuit et open source. Nous construisons nos outils en collaboration et avec la contribution de la communauté, y compris nos équipes de produits internes, les éditeurs de logiciels indépendants, les partenaires SI et les personnes incroyables et généreuses qui participent au Open Source Commons et Community Sprint programmes. Cette genèse montre dans les retours que nous entendons : que ces outils sont prêts à construire de vrais produits, dans toute leur complexité.

Qu’est-ce qui rend CumulusCI unique ?

Atlas : Pouvez-vous nous dire ce qui rend CumulusCI unique parmi tous les outils disponibles dans l’industrie ? Comment est-ce arrivé et est-ce vraiment gratuit ? Que pensez-vous de l’état du DevOps dans l’écosystème ?

David: Je pense que nous sommes au début d’un âge d’or dans Salesforce DevOps. Avec autant d’offres sur le marché et autant de connaissances croissantes dans la communauté, il n’y a plus d’excuse pour ne pas avoir une stratégie DevOps et ne pas travailler dans le monde moderne du contrôle de source et des tests automatisés. Et c’est une bonne chose pour tout le monde, même si cela peut être un peu un ajustement par rapport aux anciens modes de travail, car à la base, DevOps est une question de confiance des utilisateurs : s’assurer de fournir un logiciel de haute qualité qui respecte nos engagements.

CumulusCI est très différent des autres outils que vous trouverez, dans la mesure où je ne le vois vraiment pas comme un concurrent des principaux packages commerciaux. Un différenciateur clé, bien sûr, est qu’il s’agit d’un logiciel libre, à la fois dans le sens où il n’y a aucun coût et qu’il est disponible sous la licence open source BSD permissive.

À certains égards, CumulusCI est opiniâtre. Bien que vous puissiez utiliser les outils avec des bacs à sable, nous vous encourageons fortement à utiliser des organisations de travail. Le contrôle de source n’est pas facultatif : nous ne proposons pas de moyen de déplacer les métadonnées directement entre les organisations. Nous avons intégré les meilleures pratiques et recommandations modernes, mais nous travaillons également dur pour les activer et multiplier leur valeur.

À d’autres égards, cependant, CumulusCI concerne vos choix et les besoins spécifiques de votre processus de développement. Vous pouvez utiliser CumulusCI pour créer des organisations répondant à presque tous les besoins : installer une suite de 11 packages gérés, déployer quelques personnalisations, puis effectuer un chargement de données complexe ? C’est très bien. Configurer simplement un paramètre d’organisation et exécuter un déploiement ? C’est bien aussi. Vous souhaitez utiliser notre processus pour gérer vos branches et publier des versions de package ? Génial! Mais sinon, vous n’êtes pas obligé. Vous avez la liberté de remixer et d’assembler les outils que nous avons construits, ou d’utiliser les meilleures pratiques que nous expédions prêtes à l’emploi.

Nous sommes également très déterminés à construire pour l’ensemble du cycle de vie. Nous voulons qu’un projet CumulusCI offre une automatisation qui fonctionne pour les développeurs, pour les testeurs, pour les chefs de produits, pour les ingénieurs de version, et pour les clients et partenaires. Nous savons que ce modèle fonctionne parce que nous le pratiquons nous-mêmes, à l’air libre et à grande échelle, où toute la communauté peut observer.

Le « Cumulus » dans CumulusCI vient du nom de code du Nonprofit Success Pack (également fièrement open source), qui a été la première application à grande échelle de nos outils.

Atlas : Pouvez-vous nous dire comment CumulusCI s’intègre dans le modèle de développement de packages et le modèle de développement d’organisation ?

David: Nous, c’est-à-dire Salesforce.org, sommes ce que nous appelons un « ISV interne ». Nous faisons partie de Salesforce, mais nous créons et publions des packages gérés comme le font les autres éditeurs de logiciels indépendants, et nous le faisons à grande échelle. La dernière fois que j’ai compté, nous avions plus de 40 packages gérés actifs et nous envoyons de nouvelles versions de package toutes les deux semaines à l’ensemble de notre clientèle.

Certains de nos produits sont très complexes. Le Nonprofit Success Pack, par exemple, comprend six packages gérés, des métadonnées supplémentaires non emballées et une automatisation de la configuration. D’autres produits, tels que Salesforce Advisor Link ou Grants Management, sont livrés avec une automatisation de la configuration qui effectue une implémentation complète du produit ou crée et configure une communauté pour le client, pliant ce qui serait normalement un guide de configuration de plus de cent pages dans le produit lui-même.

Ce à quoi je veux en venir, c’est que nous avons dû aller au-dessus du modèle de développement de packages dans notre façon de penser nos produits, jusqu’à ce que nous appelons le modèle de livraison de produits. Le modèle de livraison de produit centre la notion de produit tel qu’il est expédié à un client, quelle que soit sa complexité. Nous utilisons CumulusCI pour mettre en œuvre le modèle de livraison de produit en construisant une automatisation qui construit et fournit le entier produit : tous ses packages, tous ses composants non gérés et la configuration automatisée nécessaire pour le rendre utilisable et efficace dès la sortie de la boîte. C’est ce qu’est notre produit – pas un seul package géré, mais tout ce qui entre dans cette première expérience client.

Capacités de base de CumulusCI

Atlas : Quelles sont les principales capacités de CumulusCI ? Comment cela se compare-t-il à la gestion efficace des métadonnées par rapport aux outils standard ?

David: CumulusCI n’est pas en concurrence avec Salesforce DX, il complète DX. CumulusCI est en concurrence avec deux adversaires principaux :

  • Scripts d’orchestration Bash et Node personnalisés qui exécutent une série d’étapes SFDX ou Ant ou API.
  • Documents remplis d’étapes de configuration que les utilisateurs doivent exécuter pour obtenir une organisation fonctionnelle.

Nous pensons que CumulusCI offre une meilleure alternative car il permet de composer facilement une automatisation claire et fiable à partir d’une bibliothèque massive de fonctionnalités intégrées. Il fait abstraction des détails de bas niveau et, pour la plupart des projets, ne nécessite aucun code.

J’aime décrire CumulusCI comme offrant trois grands ensembles de fonctionnalités….

  1. Il vous donne des outils pour créer des environnements dans lesquels travailler. Il gère les dépendances sans effort ; il installe les métadonnées, y compris les situations où vous pouvez avoir des métadonnées différentes pour différents types d’organisations ou de flux de travail ; il charge des données relationnelles complexes ; il configure les paramètres de l’organisation.
  2. Il vous donne des outils pour travailler dans votre environnement. Pour les développeurs, cela facilite la récupération des métadonnées et la gestion des organisations scratch, et il dispose d’un lanceur de test Apex intelligent qui peut réessayer les problèmes courants tels que les verrous de ligne. Pour les testeurs, il offre une implémentation étonnante de Robot Framework pour les tests d’automatisation de navigateur et facilite la création d’une organisation de test avec un ensemble complet de données. Pour les ingénieurs de version, il offre un échafaudage pour les versions de test automatisées et facilite le téléchargement des versions de package.
  3. Il offre des outils pour gérer l’ensemble du cycle de vie des applications. CumulusCI peut aider à automatiser ce que nous appelons CumulusCI Flow, une stratégie de gestion des succursales dans les projets Salesforce ; il peut automatiser la création de versions bêta et publiées de packages, ainsi que les déploiements vers des organisations sandbox et de production ; il peut créer des versions dans GitHub et générer automatiquement des notes de version. Et lorsqu’il est associé à MetaDeploy, il peut également fournir le produit directement aux clients.

L’automatisation CumulusCI est intégrée au balisage YAML. Pour la plupart des projets, aucun code n’est requis, bien que la possibilité de créer vos propres tâches en Python soit toujours disponible.

Exécuter des scénarios d’assurance qualité, de développement et de test pour différents groupes d’utilisateurs

Atlas : Une chose que j’ai remarquée en parcourant la nouvelle publication Documentation pour CumulusCI, c’est que vous pouvez exécuter l’automatisation pour différents ensembles d’utilisateurs et de personnalités rapidement avec divers scénarios d’assurance qualité, de développement et de test. Pouvez-vous nous dire comment nous pouvons faire cela?

David: Je suis heureux que vous ayez pu utiliser notre nouvelle documentation – c’était un projet majeur dont nous sommes vraiment fiers !

« Tout automatiser » est l’un de nos principes fondamentaux, et cela se reflète dans la façon dont nous avons construit CumulusCI. Dans de nombreuses configurations traditionnelles, l’automatisation s’exécute en CI, mais elle n’a pas d’impact direct sur les flux de travail des utilisateurs. Nous voulons que CumulusCI prenne en charge et offre une automatisation prête à l’emploi qui permet non seulement aux développeurs, mais aussi aux testeurs, aux chefs de produit, au personnel de support, aux ingénieurs de démonstration, aux partenaires et aux membres de la communauté.

Nous appelons l’automatisation construite avec CumulusCI « automatisation portable » car elle peut être utilisée dans de nombreux contextes différents. Ainsi, par exemple, vous pouvez définir une séquence d’étapes qui configure une organisation pour votre produit. Ensuite, vous pouvez inclure cette automatisation dans des flux qui ciblent différentes personnalités, comme les développeurs et les testeurs – vous généralisez votre automatisation de base pour servir tout le monde.

Ensuite, vous pouvez vous spécialiser davantage. Chacun de ces flux (
dev_org
pour les développeurs,
qa_org
pour les testeurs, etc.) peut avoir unique étapes ajoutées qui ciblent les besoins d’un personnage spécifique. Un testeur peut commencer par une version bêta de l’application, puis exécuter un chargement de données pour préparer l’organisation à son évaluation. Un responsable de produit peut configurer une organisation pour exécuter une démo, adaptée à l’histoire que vous racontez à propos de vos clients. L’ajout d’un élément à un flux peut se résumer à deux lignes de balisage.

Ce qui est essentiel, c’est que toutes ces histoires, ces flux, sont construits à partir des mêmes blocs de construction d’automatisation, et ils sont faciles à étendre, remixer et recibler à mesure que les besoins du produit évoluent.

Atlas : Est-il possible d’utiliser CumulusCI avec des bacs à sable et un modèle de développement basé sur une organisation ? Comment cela se compare-t-il à l’utilisation du modèle de livraison de produit ? Pouvons-nous commencer à utiliser CumulusCI dans une organisation déjà existante basée sur un modèle de développement basé sur une organisation et le transférer vers le modèle que vous avez décrit ?

David: C’est une excellente question et une question que j’entends beaucoup de la part des gens de la communauté. Je pense que cela représente un désir de trouver ce point où vous obtenez le maximum d’impact avec un minimum d’effort appliqué à votre infrastructure. Dans cette optique, je veux offrir deux réponses.

Tout d’abord : oui, vous pouvez utiliser CumulusCI avec un modèle de développement basé sur une organisation et avec des sandbox. En fait, le dernier module de notre Trail, Créer des applications avec CumulusCI, explique comment démarrer une implémentation d’organisation basée sur le Nonprofit Success Pack. Un cycle de vie de développement basé sur CumulusCI se termine généralement par une organisation persistante — qu’il s’agisse de packaging, pour un ISV utilisant des packages de première génération, ou d’une organisation Salesforce de production, pour une implémentation d’organisation — mais il est également possible d’intégrer l’automatisation dans le processus de déploiement contre environnements sandbox plus tôt dans le cycle de vie. CumulusCI gère automatiquement le déploiement des métadonnées, installe les nouvelles versions des packages gérés et gère la suppression des composants pour vous dans les organisations persistantes.

Mais je veux aussi plaider en faveur de la stratégie de la « grande rupture ». Bien que CumulusCI puisse apporter beaucoup de valeur à ces workflows de développement basés sur les organisations, je pense vraiment que la plus grande valeur est obtenue par les équipes qui investissent le plus dans l’automatisation et réduisent le rôle du bac à sable, en particulier le persistant bac à sable, qui est rarement ou jamais actualisé – autant que possible. Être capable de créer un environnement complètement nouveau à un coût négligeable est transformateur.

Fonctionnalités ETL de métadonnées de CumulusCI

Atlas : Une fonctionnalité que j’étais vraiment ravie de voir était les fonctionnalités ETL de métadonnées de CumulusCI. Pouvez-vous nous en parler ?

David: L’ETL des métadonnées est aussi quelque chose qui m’excite vraiment. Nous avons parlé un peu plus tôt du modèle de livraison de produit, qui englobe la livraison de produits volumineux et complexes aux clients qui incluent parfois des composants et des personnalisations non emballés. La pratique du modèle de livraison de produit nous amène à réfléchir profondément à la manière d’offrir aux clients la possibilité de nous laisser apporter des modifications à leurs organisations sans encombre, pour créer une expérience produit complète et intégrée avec une configuration manuelle minimale.

Laissez-moi vous donner un exemple concret. Un package peut avoir des dépendances sur des valeurs spécifiques dans la liste de sélection standard Case Reason. Vous ne pouvez pas fournir de modifications de liste de sélection standard dans un package géré. Par conséquent, vous aviez historiquement deux options pour diffuser ce package :

  1. Demandez au client de mettre à jour manuellement la liste de sélection Case Reason dans chaque organisation dans laquelle il souhaite effectuer l’installation. Ce n’est pas une grande expérience.
  2. Fournissez les modifications sous la forme d’un déploiement de métadonnées non packagé et risquez d’écraser d’autres personnalisations effectuées par le client. C’est une violation de confiance potentielle !

Ce que nous faisons avec Metadata ETL, c’est extraire les métadonnées existantes qui doivent être personnalisées, apporter une modification ciblée à ces métadonnées – comme l’ajout d’une nouvelle valeur de liste de sélection spécifique – tout en laissant les personnalisations existantes inchangées, puis en redéployant l’intégralité du composant.

C’est un excellent moyen d’apporter des modifications chirurgicales aux métadonnées telles que les mises en page, les ensembles de valeurs globales et même les valeurs par défaut à l’échelle de l’organisation pour obtenir en toute sécurité une configuration complexe dans une organisation qui peut déjà être fortement personnalisée.

J’ai utilisé un langage spécifique aux éditeurs de logiciels ici, mais je dois également souligner que les mêmes paradigmes s’appliquent également bien, par exemple, les besoins des départements qui gèrent plusieurs organisations Salesforce ou des cabinets de conseil livrant à leurs clients. L’ETL de métadonnées permet de fournir de nouvelles personnalisations de manière plus sûre dans toutes les situations où vous ne contrôlez pas l’état de l’organisation cible.

Atlas : Une autre caractéristique intéressante qui se démarque est que nous pouvons sélectionner et modifier les flux et l’automatisation existants qui existent dans CumulusCI et les adapter à des scénarios de cas d’utilisation spécifiques. Pouvez-vous nous dire ce qui est nécessaire pour accomplir cela?

David: Absolument! CumulusCI est livré avec de nombreux flux prêts à l’emploi pour créer différents types d’organisations, comme un
dev_org
pour les développeurs et un
qa_org
pour les testeurs. Les projets peuvent choisir d’utiliser ces flux sans modification, de créer leurs propres flux ou de personnaliser en profondeur les flux prêts à l’emploi en fonction de leurs cas d’utilisation spécifiques.

Voici un exemple avec un peu de complexité. Supposons que vous soyez un testeur de produits et que vous travaillez sur un projet qui utilise Experience Cloud. Pour faire votre travail efficacement, vous avez besoin non seulement du projet sur lequel vous travaillez dans une organisation, mais aussi d’une expérience construite et d’un utilisateur avec lequel vous pouvez vous connecter pour évaluer le comportement du projet. Et idéalement, vous n’auriez pas besoin de passer une demi-heure à ajouter toutes les données pour rendre l’organisation réaliste.

Donc, ce que vous pourriez faire, en travaillant avec votre équipe produit, est d’ajouter plusieurs nouvelles étapes au flux
config_qa
, qui configure un
qa_org
. Une étape créerait une expérience (c’est une tâche prête à l’emploi), une autre créerait un utilisateur (en consommant une commande SFDX ou peut-être en exécutant un script Apex), puis une troisième chargerait un ensemble de données qui aide à dire au histoire de l’application que vous testez (qui est également prête à l’emploi). C’est peut-être 10 lignes de balisage, au total – pas de code – et ensuite vous avez un énorme coup de pouce dans vos processus d’assurance qualité parce que vous n’avez rien à configurer à la main avant de commencer votre travail dans un nouvel environnement. En fait, cela est représentatif d’une véritable automatisation que nous avons mise en œuvre en partenariat avec les équipes de développement et d’assurance qualité pour plusieurs projets.

Qu’est-ce que vraiment cool, c’est ce qui se passe lorsque le reste de l’équipe remarque cette automatisation brillante, puis vous passez à l’étape suivante pour intégrer cette configuration dans un flux que vous pouvez utiliser de différentes manières : créer des démos de produits pour les parties prenantes de l’entreprise, soutenir les développeurs ou peut-être même fournir la configuration du produit aux clients via MetaDeploy.

Ce que vous devez savoir avant d’utiliser les outils DevOps

Atlas : Il peut être difficile pour les équipes d’adopter n’importe quel outil et de l’utiliser efficacement. À quoi devons-nous penser avant d’utiliser un outil DevOps ?

David : La mise en garde clé dans mon esprit est très simple : il n’y a pas d’outil qui résout 100 % de votre problème immédiatement. (« Quiconque dit différemment vend quelque chose »). Il n’y a pas d’outil ni de processus qui, à long terme, vous évitera d’investir dans l’infrastructure ou l’expertise ou les deux, et c’est généralement les deux. Vous devrez toujours peser les investissements en outillage, les investissements en personnel et les investissements en processus ensemble.

Un autre facteur clé à prendre en compte est que l’adoption réussie de DevOps vous obligera probablement à faire face à des faiblesses non reconnues, et peut-être à mettre des vaches sacrées au pâturage. Les organisations qui essaient de passer à des pratiques basées sur DevOps tout en s’accrochant à la façon dont leurs processus actuels fonctionnent peuvent se gêner : elles choisissent de ne pas tirer le meilleur parti des meilleurs outils et innovations de processus, car elles ne remettent pas en question et ne dépassent pas les hypothèses obsolètes. Si vous êtes assis sur une montagne de dettes techniques non remboursées ou non reconnues, cela peut également être un obstacle important (bien qu’une fois que vous avez effectué le changement, vous constaterez peut-être qu’un programme DevOps sérieux vous aide à éviter d’accumuler autant de dettes technologiques et vous aide à justifier de payer ce que vous avez).

Communautés en ligne

Atlas : David, je sais que vous êtes très actif parmi les communautés en ligne et vos réponses sur StackExchange m’aident encore à ce jour. Pour un professionnel quel que soit son niveau de compétence, pouvez-vous nous parler de l’importance d’y participer, notamment pendant la COVID ?

Je sais aussi que tu as rejoint SFXD – L’échange Discord de Salesforce récemment, comment s’est passée votre expérience ?

David: Je suis un grand fan de ce que les communautés Salesforce en ligne peuvent créer – à tout moment, mais d’autant plus pendant COVID, car nous sommes séparés de nos autres communautés et points de vente pour la connexion sociale, le réseautage professionnel et le partage d’expertise.

Toutes les communautés (Salesforce Échange de pile, SFXD, la communauté Slacks, Salesforce Twitter, et je suis sûr que d’autres que je ne connais pas encore) ont des tons, des objectifs et une valeur différents à offrir, il y a donc vraiment un créneau pour tout le monde.

L’une des choses les plus difficiles dans la construction d’une communauté est de définir des objectifs, des structures et des attentes, et je pense que c’est quelque chose que SFXD et SFSE font bien (sinon pas du tout de la même manière). SFXD est une discussion fluide et permanente avec une vaste expertise. SFSE, où je suis modérateur, est une base de connaissances communautaire axée sur la création de solutions découvrables et rigoureusement structurées. Je pense que c’est un excellent un-deux; elles servent à des fins différentes et sont toutes deux des communautés exceptionnelles.

Au terme de mon engagement auprès de toutes ces communautés, s’il y a un conseil que je peux offrir aux ingénieurs de tous niveaux, c’est celui-ci : apprenez à poser une bonne question. Soyez conscient et réfléchissez à partager les bons détails et à définir le bon contexte pour amener quelqu’un à relever le défi auquel vous êtes confronté afin qu’il puisse vous aider. Non seulement cette compétence fait de vous un atout pour toute communauté en ligne que vous choisissez de rejoindre et vous amène à votre solution plus rapidement, mais elle vous aide également à apprendre à réfléchir efficacement à un problème et fait de vous un coéquipier plus fort.

C’est tout pour l’épisode d’aujourd’hui! Merci de vous être connecté, vous pouvez me trouver et David Reed à SFXD – Échange de communauté Discord Salesforce et restez à l’écoute pour plus!

Ressources:

Créer des applications avec CumulusCI sur Trailhead

Documentation CumulusCI

CumulusCI sur la communauté des pionniers

Projet Open Source CumulusCI

github.com/SalesforceFoundation/NPSP

github.com/SalesforceFoundation/EDA

github.com/SFDO-Communauté

Twitter d’Atlas Can

Twitter de David Reed





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer