Zugangsdaten für externe Dienste haben die unangenehme Eigenschaft, sich zu verteilen: der Firebase-Schlüssel bei einem Kollegen, die SMTP-Daten in einer alten Konfigurationsdatei, und wer Zugriff auf das Store-Konto hat, weiß man erst, wenn ein Release ansteht. Dazu kommt, dass Fehler bei der Eingabe oft erst spät auffallen: Ein falsch kopierter Schlüssel wird gespeichert, alles sieht in Ordnung aus, und die Fehlermeldung kommt beim ersten Build — im schlechtesten Fall Wochen später.
Seit dem 3. August ist der Bereich Anbindungen überarbeitet. Er sammelt die Verbindungen zu externen Diensten an einer Stelle und prüft die Zugangsdaten, bevor sie gespeichert werden.
Ein Kachelraster statt einer Liste
Die Auswahl der Dienste zeigt ein Kachelraster mit Marken-Icons — du erkennst am Bild, ob du Firebase, Mailtrap oder Sentry vor dir hast, statt eine Zeile Text zu lesen. Bereits eingerichtete Anbindungen erscheinen als Karten, jede mit Typ und zugehörigem Konto — bei mehreren Firebase-Konten in unterschiedlichen Projekten ist damit auf einen Blick klar, welches Konto wo hängt.
Firebase per OAuth oder Service-Account
Für Firebase gibt es zwei Wege: per OAuth verbinden oder eine Service-Account-JSON hinterlegen. Ersteres ist schneller, Letzteres passt besser zu Automatisierung und Konten ohne Personenbindung. Neue Firebase-Projekte legst du direkt beim Anbinden an, inklusive Ordner und Abrechnungskonto — der Umweg über die Google-Konsole entfällt.
Mailtrap und Sentry
Mailtrap ist als neuer Anbindungstyp dazugekommen. Die Ansicht zeigt die Auslastung deiner Domains und die Grenzen deines Tarifs, Demo-Domains sind gekennzeichnet, damit niemand versehentlich eine Testdomain für den Produktivversand einplant.
Sentry lässt sich im Host-Modus einrichten und bringt Single Sign-on über Authentik mit — dein Team meldet sich mit dem Plattform-Login an, ohne separate Konten. Eingerichtet wird Sentry nur, wenn eine eigene Anbindung hinterlegt ist.
Zugangsdaten werden vorher geprüft
Für Firebase, SMTP und Mailtrap werden die Zugangsdaten geprüft, bevor sie gespeichert werden — stimmt etwas nicht, erfährst du es im Formular, nicht beim nächsten Deployment.
Bei Store-Zugangsdaten geht die Prüfung weiter: Sie werden gegen App Store und Play Store geprüft. Beim Verknüpfen werden die vorhandenen Apps geladen, sodass du Bundle-ID und Paketname aus einer Liste auswählst — ein Tippfehler kostet sonst leicht einen halben Release-Tag.
Neu für Windows und auf Organisationsebene
Für Windows sind zwei Anbindungen dazugekommen: Microsoft Store und Azure Artifact Signing, mit denen sich Windows-Anwendungen signieren und veröffentlichen lassen.
Anbindungen kannst du außerdem auf Organisationsebene per OAuth verknüpfen und in deinen Projekten nutzen — die Verbindung wird einmal hergestellt, nicht in jedem Projekt neu. Für Agenturen ist das der Regelfall: viele Projekte, unterschiedliche Kunden, teils eigene und teils vom Kunden gestellte Konten. Wie die Plattform das abbildet, steht auf der Seite für Agenturen.
Verwandte Themen
Anbindungen sind die Voraussetzung für vieles, was danach ohne dein Zutun läuft. Store-Konten und Signaturschlüssel braucht die Plattform für die Veröffentlichung mobiler Apps, nachzulesen unter App-Store-Automatisierung.
Der praktische Nutzen: weniger Fehlkonfiguration, schnelleres Onboarding, und Zugangsdaten an einem Ort statt verteilt über Dateien und Chats.
