Zum Inhalt springen

Prüfung und Bereitstellung

Auf Canvas bauen Sie im Browser, gemeinsam mit der KI. Ist eine Änderung fertig, geht sie nicht von allein live. Zuerst wird sie geprüft und freigegeben, dann bereitgestellt und schließlich über Staging in die Produktion befördert. Wie viel Prüfung eine Änderung braucht, hängt davon ab, wie riskant sie ist, und Ihr IT-Manager legt die Regeln fest. Diese Anleitung geht den ganzen Weg durch.

Vom Bauen zur Live-App auf Canvas: in Entwicklung bauen, dann prüfen und zusammenführen mit risikobasierter Freigabe, dann bereitstellen durch Bauen und Ausrollen eines Container-Images, dann in Staging vom Team testen, dann in die Produktion befördern.

Wenn Sie eine Änderung abschließen, bewertet der Builder-Agent, wie riskant sie ist: wie viel sie berührt und ob sie sensible Teile Ihrer App betrifft. Auf dieser Grundlage leitet Canvas sie vor dem Zusammenführen auf eine von drei Prüfungsstufen.

  • Selbstprüfung. Bei risikoarmen Änderungen geben Sie Ihre eigene Arbeit frei und führen sie zusammen.
  • Team-Prüfung. Ein anderer Builder prüft die Änderung, für ein zweites Paar Augen und Abstimmung.
  • Regulierte Prüfung. Bei riskanten Änderungen muss ein IT-Manager oder Platform Engineer freigeben. Das betrifft alles, was sensiblen Boden berührt, etwa die Authentifizierung oder das zentrale Datenschema, auf dem Ihre Datensätze beruhen.

Der Bildschirm Prüfen und Zusammenführen für eine Änderung, mit Reitern für Selbst-, Team- und regulierte Prüfung, einer Zusammenfassung in Klartext und automatischen Prüfungen für Guardrails, Tests und den Build.

Bevor jemand freigibt, führt Canvas automatische Prüfungen aus und zeigt das Ergebnis: eingebaute Guardrails, Ihre Tests und ein erfolgreicher Image-Build müssen alle bestehen. Daneben erhalten Sie eine Zusammenfassung in Klartext, was die Änderung tatsächlich ausliefert, damit eine prüfende Person nicht jede Zeile lesen muss, um sie zu verstehen.

Wenn Sie die Änderung öffnen, geschieht die Prüfung auf einer Oberfläche für jede Größe von Änderung. Sie sehen die Dateien nach Bereich gruppiert, die Unterschiede in jeder und einen laufenden Zähler dessen, was Sie angesehen und markiert haben. Dieselbe Ansicht bewältigt wenige Dateien oder einige hundert. Sie hinterlassen Kommentare, und wenn Sie zufrieden sind, geben Sie frei und schließen die Prüfung ab.

Die Prüfungsoberfläche für eine Änderung: nach Bereich gruppierte Dateien mit Änderungszählern je Datei, die Unterschiede inline dargestellt und eine Aktion zum Freigeben und Abschließen der Prüfung.

Die Prüfungsstufen sind nicht von uns vorgegeben. Ihr IT-Manager konfiguriert sie, auf zwei Ebenen:

  • Auf Organisationsebene, als Standardrichtlinie für alle.
  • Pro App, denn Apps unterscheiden sich im Risiko. Ein internes Werkzeug kann mit leichterer Prüfung auskommen, während eine kundenseitige oder regulierte App für weit mehr ihrer Änderungen Team- oder regulierte Prüfung verlangen kann.

So kann dieselbe Art von Änderung in einer risikoarmen App eine Selbstprüfung und in einer riskanten App eine regulierte Prüfung erfordern. Die Richtlinie liegt in Ihrer Hand. Siehe Identität und Zugriff für die beteiligten Rollen und die Sicherheits- und Vertrauensübersicht, wie dies in das weitere Kontrollmodell passt.

Sobald eine Änderung freigegeben und zusammengeführt ist, stellen Sie sie bereit. Canvas baut Ihre App in einem isolierten Build zu einem Container-Image und rollt dieses Image dann in die gewählte Umgebung aus. Sie verfolgen den Status dabei: Build läuft, dann in Betrieb, oder, falls etwas fehlschlägt, der genaue Fehler, damit Sie ihn beheben können. Jede Bereitstellung wird festgehalten.

Der Bereitstellungs-Bildschirm: eine App, die die Umgebungsleiter hinaufbefördert wird, mit laufendem Build und Ausrollen sowie den Zuständen In-Betrieb und Rollback je Umgebung.

Jede App hat drei Umgebungen, und eine Änderung steigt sie der Reihe nach hinauf:

  • Entwicklung ist, wo Sie bauen. Sie bietet eine Live-Vorschau, die nur Ihr Team sieht, und wird von Suchmaschinen ferngehalten.
  • Staging ist passwortgeschützt, damit Ihr Team eine Änderung so testet, wie sie in der Produktion aussehen wird. Auch sie wird von Suchmaschinen ferngehalten.
  • Produktion ist die Live-App: öffentlich oder auf Ihrer eigenen Domain.

Sie befördern eine Änderung, indem Sie sie in die nächste Umgebung bereitstellen, wenn sie bereit ist. Wer bereitstellen darf, ist auf die von Ihnen gewählten Rollen beschränkt, sodass der Schritt in die Produktion bewusst erfolgt und nicht versehentlich.

Alles, was Sie bauen, ist echter Code unter Versionskontrolle, und er gehört Ihnen.

  • Jede Änderung liegt auf einem eigenen Branch, und jeder Commit wird in Ihrem Namen festgehalten.
  • Prüfung und Zusammenführung geschehen in der Plattform. Es gibt nichts zu installieren und keine lokale Einrichtung; die oben beschriebene Prüfung erzeugt eine echte Zusammenführung in Ihren Hauptzweig.
  • Ihre vollständige Git-Historie gehört Ihnen. Sie können sie jederzeit exportieren. Siehe Datenexport und Portabilität, wie.

Aktualisierungen rollen schrittweise aus, sodass Ihre App für ihre Nutzer verfügbar bleibt, während eine neue Version übernimmt. Da jede Bereitstellung in der Historie erhalten bleibt, stecken Sie nie auf einer fehlerhaften fest: Sie können per Rollback eine frühere Version erneut bereitstellen, und Ihre App kehrt in diesen bekannten, funktionierenden Zustand zurück.

Die Produktion kann auf einem von Canvas verwalteten Hostnamen oder auf Ihrer eigenen Domain laufen. Für die eigene Domain fügen Sie sie in den Einstellungen der App hinzu, und Canvas zeigt Ihnen die genauen DNS-Einträge, die Sie anlegen. Sobald diese gesetzt sind, stellt Canvas das TLS-Zertifikat automatisch aus und erneuert es, sodass Sie keine Zertifikate selbst verwalten. Siehe Netzwerk und Konnektivität für die Details zu DNS und Konnektivität.

Builds laufen isoliert, und Ihre App läuft auf verwalteter, Kubernetes-basierter Infrastruktur, die in Deutschland gehostet wird. Für das größere Bild, wie Apps laufen und wo Daten liegen, siehe Architektur.