Das Problem

Ich habe mir immer gewünscht, dass Zwangsversteigerung Bereitstellungen waren einfacher. Als Entwickler habe ich gesehen, wie viele Tage aufgrund des langwierigen und fehleranfälligen Bereitstellungsprozesses verschwendet wurden.

Eine typische Salesforce-Bereitstellung sieht ungefähr so aus:

1. Ändern Sie den Code.
2. Notieren Sie, welche Dateien Sie gelöscht, hinzugefügt und geändert haben.
3. Melden Sie sich bei einer Sandbox an, in der der Code gespeichert ist.
4. Erstellen Sie einen Änderungssatz.
5. Wählen Sie jede Komponente, die Sie bereitstellen möchten, manuell aus.
6. Wählen Sie das Ziel aus, auf dem Sie den Änderungssatz bereitstellen möchten.
7. Melden Sie sich bei der Zielorganisation an, an die Sie Ihren Änderungssatz gesendet haben.
8. Suchen Sie Ihren Änderungssatz.
9. Klicken Sie auf „Bereitstellen“.

Wie Sie sehen, ist dies eine ziemlich lange Liste. Jeder Schritt muss manuell ausgeführt werden und der gesamte Prozess ist fehleranfällig. Wenn Sie in mehreren Umgebungen bereitstellen möchten, müssen Sie diesen gesamten Prozess für jede Umgebung wiederholen.

Bei diesem Vorgang sind mir viele Probleme begegnet, darunter:

1. Änderungssätze mit fehlenden Komponenten. Die Notwendigkeit, jede geänderte Datei manuell zu verfolgen, kann zu unvollständigen Änderungssätzen führen, die neu erstellt und erneut auf die Zielorganisation angewendet werden müssen.
2. Die Zielorganisation muss über die richtigen Berechtigungen und die richtige Konfiguration verfügen, um Änderungssätze zu akzeptieren.
3. Da der Code in Salesforce existiert, getestet und „bereitgestellt“ wird, kann er außerhalb der Versionskontrolle existieren. Wenn Sie also in einer veralteten Sandbox arbeiten, können Sie die Arbeit anderer ganz einfach überschreiben.
4. Es dauert eine Weile, bis die Änderungssätze an die Zielorganisationen weitergegeben werden. Daher verbringen Sie letztendlich viel Zeit damit, darauf zu warten, dass Salesforce seine Arbeit erledigt.

Die Lösung

Ich wollte dasselbe Bereitstellungssystem verwenden, das wir für alles andere bei PagerDuty verwenden. Wir verwenden ein internes Bereitstellungssystem namens Igor, das über unsere Lita Bot hat angerufen OffizierURL (kurz URL). Mit der URL können wir unseren Code mit einem einzigen Befehl in Slack bereitstellen.

 !Salesforce bereitstellen<branch:default is master> Zu<environment> 

Um beispielsweise den Master-Zweig unseres Salesforce-Codes in der Produktion bereitzustellen, geben wir Folgendes ein:

 ! Salesforce in der Produktion einsetzen 

Der Bot teilt uns dann mit, ob der Vorgang erfolgreich war oder fehlgeschlagen ist. Außerdem stellt er uns eine Verbindung zu den Bereitstellungsprotokollen in Igor her.

Hier ist ein Screenshot einer tatsächlichen Salesforce-Bereitstellung, die ich kürzlich durchgeführt habe:

Es ist wirklich so einfach.

Die Einrichtung

Auf hohem Niveau macht unser Bot/Deployer-Duo Folgendes:

1. Checkt das GitHub-Repository des Projekts aus.
2. Wechselt zum angegebenen Zweig.
3. Führt ein Bereitstellungsskript im ausgecheckten Repository aus und stellt ihm das Bereitstellungsziel zur Verfügung.
4. Benachrichtigt uns über den Erfolg oder Misserfolg der Bereitstellung basierend auf dem Exitcode des Skripts.

Das Tool, das diesen Workflow ermöglicht hat, ist https://github.com/neowit/tooling-force.com .

Ein großer Vorteil dieses Tools besteht darin, dass es Bereitstellungen ermöglicht, die Komponenten in Salesforce entfernen, die nicht mehr im Arbeitsverzeichnis vorhanden sind. Tatsächlich sorgt es dafür, dass die Salesforce-Kopie des Projekts so weit wie möglich mit Ihrem Arbeitsverzeichnis übereinstimmt. Die meisten anderen Tools stellen nur die Dateien im Arbeitsverzeichnis bereit; sie entfernen keine Komponenten in Salesforce, die lokal nicht mehr vorhanden sind. Dies kann dazu führen, dass Code in Salesforce aktiv bleibt, obwohl er vollständig hätte entfernt werden sollen.

Der folgende Befehl wird ausgeführt, wenn Sie die Bereitstellung über den Chat durchführen:

 java -jar Pfad.zu.jar --action=deployAllDestructive --config=Pfad.zu.Eigenschaften --projectPath=. --responseFilePath=/dev/stdout --maxPollRequests=200 --specificTypes=./src/package.xml --typesFileFormat=packageXml | tee deploy.stdout grep 'ERGEBNIS=ERFOLGREICH' deploy.stdout 

Sie können eine JAR-Datei des Tools herunterladen unter https://github.com/neowit/tooling-force.com/releases .

Beachten Sie, dass path.to.properties eine Variable hat, die die Umgebung darstellt, in der die Bereitstellung erfolgen soll, sodass wir die Bereitstellung in mehreren Umgebungen durchführen können.

Die Eigenschaftendatei:

 sf.username=Benutzername sf.password=Passwort sf.serverurl=https://login.salesforce.com oder https://test.salesforce.com 

Die Datei package.xml wird in Git eingecheckt und gibt an, welche Komponenten bereitgestellt werden sollen. Ich verwende:

 <?xml version="1.0" encoding="UTF-8"?><Package xmlns="http://soap.sforce.com/2006/04/metadata"><types><members> *</members><name> Apex-Klasse</name></types><types><members> *</members><name> Apex-Komponente</name></types><types><members> *</members><name> ApexSeite</name></types><types><members> *</members><name> ApexTrigger</name></types><types><members> *</members><name> Statische Ressource</name></types><version> 34,0</version></Package> 

Credits

Ohne unser großartiges DevTools-Team wäre die Implementierung schwieriger gewesen. Sie pflegen den Bot, der allgemeine Funktionen wie die Handhabung des Git-Checkouts, Statusbenachrichtigungen und die Protokollierung beim Ausführen eines Bereitstellungsskripts bereitstellt.

Vielen Dank auch an Andrey Gavrikov ( neowit auf GitHub ) für die Bereitstellung der Befehlszeilen-Anwendung tooling-force.com, die eine einfache Salesforce-Bereitstellung aus einem Ordner ermöglicht.