SalesforceDX I: Der erste Push und fast ein Pull

Christian Szandor Knapp | | Lesezeit: 3 Min.

Die alte Welt werde ich nicht vermissen. Mittels CumulusCI (Salesforce Foundation), dem Force CLI und CircleCI habe ich mich in letzter Zeit in die 'alte Welt' vertieft. Dabei viel Neues über Deployments, Namespaces und unterschiedliche Developer Org Arten gelernt. Ich habe mindestens eine Packaging Org zerschossen, zwei Namespaces verbraten und bin seither mit dem Salesforce Support beschäftigt, die neue Packaging Org zu zähmen. Die guten Nachrichten: Es funktioniert und zwar ziemlich gut - dank gilt hier dem KnowHow von Jason Lantz, dem Kopf hinter CumulusCI.

Mit diesen Erfahrungen frisch im Kopf, nimmt sich SalesforceDX aus wie der Heilige Gral bei Monty Python.

Vorgeplänkel

  • Ich hab ein Managed Package mit einigen, kleinen Lightning Components, einer App, einer Utility Bar, Custom Object, etc. gebaut. Repository findet sich hier.

  • CircleCI + CumulusCI kümmern sich um das Deployen und den Release einer neuen Version, sobald ein Commit in den Master auf Github stattfindet.

  • Da ich auch heroku cli nutze, hab ich sfdx einfach zusätzlich installiert. Die Installation via heroku plugin:install salesforcedx hat mir nicht getaugt. --help hat nicht funktioniert und die Länge der Kommandos war unterträglich.

  • Sobald SalesforceDX öffentlich zugänglich ist, gibt es hier einen Link.

  • Ich gehe hier davon aus, daß Euer workspace bereits soweit eingerichtet ist. Meiner sieht so aus:

{
  "PackageDirectories" : [
            { "Path" : "lwb", "Default": true}
  ],
  "Namespace": "szLWB",
  "SfdcLoginUrl": "https://login.salesforce.com",
  "SourceApiVersion": "39.0",
  "EnableTokenEncryption": false
}

Dummer Fehler Nummer 1: In den PackageDirectories auch meinen Metadaten Ordner ./src, in dem auch die package.xml wohnt, eingetragen. Das führte zu folgendem Rätsel:

Unexpected File pacakge.xml

Kurzum: Zu den Packages gehören keine klassischen Metadaten.

Vorgehen:

  • drauf los, --help ist mein beständiger Begleiter.

  • Klappe halten :-) - zum Philosophieren über DX ist noch genug Zeit

Schritt 1 - Von Metadaten und Package.xml zu SalesforceDX Source Files

  • in ./src liegen alle Metadaten und die explizite package.xml

  • Ich habe mit sfdx force:alias und sfdx force:configalles eingerichtet, daß ich's lesen und verstehen kann:

Config Setup

  • sfdx force:mdapi:convert --rootdir ./src - es rödelt und dann sind meine Metadaten in das neue DX Format konvertiert und im Ordner ./lwb zu finden. Dieses neue Format unterscheidet sich nicht groß vom Original im Moment.

mdapi convert

  • Nächster Schritt: Ich will meine App ausprobieren und in eine neue Org kleben.

  • Ab hier dann byebye, alte Welt. Statt mir eine neue Dev Org zu holen, anzumelden, Account einzurichten, Features zu enablen oder gar Salesforce Support dafür kontaktieren zu müssen, habe ich hier eine Definition Datei, die recht einleuchtend ist: Lightning aktiv und Chatter enabled.

{
  "Company": "LWB",
  "Country": "US",
  "LastName": "Sz",
  "Email": "sz@appero.com",
  "Edition": "Developer",
  "OrgPreferences" : {
    "S1DesktopEnabled" : true,
    "ChatterEnabled" : true
  }
}

DX Superstars: Scratch Orgs

Anhand dieser Konfiguration wird eine sogenannte Scratch Org erstellt - oder viele. Meistens dauert das weniger als eine Minute. So eine Org ist eine richtige Salesforce Org, lebt aber nur für eine Woche. Dann wird sie automatisch gelöscht.

Der Gral: Was in der Org konfiguriert wird, wird automatisch erkannt - es findet Versionierung statt. Wie bei Github synce ich die Unterschiede und muß mich unter Umständen darum kümmern, Konflikte zu beheben.

Der Clou: Genau dieses Synchron Halten zwischen Org und lokalem Kopie war eine zentrale Herausforderung der 'alten Welt'. Mit DX geht das so:

  1. Code in die Scratch Org pushen: sfdx force:source:push
  2. sfdx force:org:open und in meinem Browser geht die neue Org auf ohne Login. Und zwar genau die richtige. Und ich kann auch steuern, wie und wo!
  3. Konfigurieren - in meinem Fall hab ich die App den Profilen StandardUser und System Administrator zugeordnet, damit die die App sehen können, und ein Custom Object gelöscht.
  4. Änderungen nachvollziehen sfdx force:source:status (wie git status)

sfdx status

und dann abholen sfdx force:source:pull

sfdx pull

Dummer Fehler Nummer 2 Weiß ich nicht. Aktuell hab ich keine Ahnung, was mir der Fehler sagen soll. Der Full Name macht mich bei den Permission Sets stutzig. Ich kann mir vorstellen, daß Profiländerungen in DX vielleicht als Permissions abgehandelt werden. Aber mit so kryptischem Namen?

In Teil II werde ich es hoffentlich herausgefunden haben.

Share:
Kommentare anzeigen