Cloud Source Repositories ist nicht mehr verfügbar. Zur Vorbereitung auf die Einstellung dieses Dienstes werden auf dieser Seite Migrationsoptionen für verschiedene Anwendungsfälle beschrieben. Das Datum der Einstellung wird mindestens ein Jahr im Voraus mitgeteilt, damit Sie genügend Zeit haben, zu einem alternativen Produkt zu migrieren.
Alle Nutzer müssen ihre Repositories vor dem Datum der Schließung migrieren. Sehen Sie sich die folgenden Migrationsoptionen an, um mit der Planung Ihrer Migration zu beginnen.
Migrationsleitfäden
-
Zu Secure Source Manager migrieren
In dieser Anleitung finden Sie die erforderlichen Schritte, um ein Git-Repository mit allen Repository-Informationen von Cloud Source Repositories zu Secure Source Manager zu migrieren.
-
Cloud Source Repositories-Rollen und -Berechtigungen in Secure Source Manager übersetzen
In dieser Anleitung wird erläutert, wie Rollen und Berechtigungen in Cloud Source Repositories denen in Secure Source Manager zugeordnet werden.
Repository-Nutzung ermitteln
Um die Migration zu planen, müssen Sie zuerst alle Ihre Cloud Source Repositories identifizieren. Sie können Ihre Repositories auf der Seite „Source Repositories“ aufrufen und mit der Projektauswahl nach Projekten suchen, die Repositories enthalten. Für den Zugriff auf ein Repository benötigen Sie die entsprechenden IAM-Berechtigungen (Identity and Access Management), z. B. „Project Owner“ oder „Source Repository Administrator“.
Nachdem Sie ein Repository identifiziert haben, prüfen Sie, ob es noch verwendet wird oder mit einem Build-System verbunden ist. Wenn ein Repository nicht verwendet wird, löschen Sie es. Durch das Löschen nicht verwendeter Repositories wird der Prozess der Einstellung unterstützt und es werden keine weiteren Benachrichtigungen gesendet.
Migrationspfade nach Anwendungsfall
In der folgenden Tabelle werden häufige Anwendungsfälle für Cloud Source Repositories den empfohlenen Migrationspfaden zugeordnet.
| Anwendungsfall | Migrationspfad |
|---|---|
| Softwareentwicklung | Secure Source Manager oder ein Drittanbieter-Quellcode-Verwaltungssystem. |
| In Cloud Build einbinden | Wenn Ihre Cloud Source Repositories ein Spiegelbild eines externen Repositorys sind, das zum Auslösen von Cloud Build verwendet wird, lesen Sie den Abschnitt Cloud Build mit Ihrem Quellcode-Verwaltungssystem verbinden oder richten Sie einen Webhook-Trigger ein. |
| Kubernetes-Konfigurationssynchronisierung und andere Anwendungsfälle für Infrastructure as Code | Artifact Registry OCI / Helm, Secure Source Manager oder andere Quellcode-Verwaltungssysteme. |
| Quellcode-Repositories sichern | Eine Back-up-Lösung eines Drittanbieters Ein Beispiel finden Sie in der GitHub-Dokumentation unter Backups auf Ihrer Instanz konfigurieren. |
| Verbindung mit privaten Netzwerken | Anwendungsfälle finden Sie unter Developer Connect und Service Directory. Wenn Sie manuelle Trigger, Pub/Sub, Webhook oder Terraform-Unterstützung benötigen, lesen Sie den Abschnitt Cloud Build-Repositories. Wenn Sie Cloud Source Repositories verwenden, um Cloud Build-Repositories in einem privaten Netzwerk mit GitHub Enterprise zu verbinden, lesen Sie den Abschnitt Repositories aus GitHub Enterprise in einem privaten Netzwerk erstellen. Informationen zur Unterstützung von Infrastruktur als Code und privaten Netzwerken finden Sie unter Artifact Registry OCI und Helm. |
| Cloud Debugger oder Error Reporting verwenden | Verbindung zu einem anderen Git-Anbieter herstellen |