Geeigneteste Architektur oder Lösung ermitteln

Berücksichtigen Sie die Reihe von Bewertungsfaktoren (oder Stressoren), um die Referenzarchitektur (RA) oder Lösung zu identifizieren, die Ihren Anforderungen am besten entspricht. In den folgenden Abschnitten finden Sie Informationen zu den Faktoren, die Sie berücksichtigen sollten.

Für jeden Faktor geben wir Ihnen einen Hinweis darauf, ob eine Architektur oder Lösung den Faktor unterstützt oder nicht. Falls erforderlich, können Sie es nuancierter machen, indem Sie jedem Faktor einen numerischen Score zuweisen. Verwenden Sie die Informations- und Entscheidungsmatrix anhand dieser Empfehlungen.

Verfolgen Sie, welche Spalten mit Ihrer bevorzugten Antwort übereinstimmen.
Vergleichen Sie mit der Entscheidungsmatrix die RA oder Lösung, die Ihren Anforderungen am besten entspricht, mit jedem Bewertungsfaktor.
Fügen Sie eine Gewichtung zu den Faktoren hinzu, die für Sie wichtiger sind als andere.

Verschiedene Bewertungsfaktoren berücksichtigen

Überlegen Sie jeden Bewertungsfaktor, und vergleichen Sie ihn dann mit jeder Architektur und Lösung, um den Faktor zu bestimmen, der Ihren Anforderungen am besten entspricht.

Container, Virtual Machine (VM) oder Specialist

Sie können Ressourcen für Prozesse, die mehr Rechenleistung erfordern, effizient skalieren, indem Sie Prozesse in Containern innerhalb einer Containerorchestrierungsumgebung wie Kubernetes bereitstellen. Aufgaben wie Einheitentests und statische Codeanalyse können davon profitieren. Der Nachteil der Verwendung von Containern ist die erhöhte Komplexität der End-to-End-Konfiguration. Ihr Team muss wissen, wie Containerorchestrierungstools wie Kubernetes verwendet werden. Mithilfe von Containern wird außerdem sichergestellt, dass sie beim Löschen der Container transiente Abhängigkeiten oder vorherige Statusdaten nicht versehentlich aufnehmen.

Die Verwendung einer VM ist einfacher, da Sie eine einzelne VM erstellen können, um alle Schritte einer Pipeline auszuführen. Ein Behälter ist monolithisch. Ein VM-Ansatz lindert auch Probleme wie das Bereitstellen von Entwicklern und vermeidet Probleme bei der Verwendung von Windows im Vergleich zu Linux-Hosts.

Einige Spezialszenarios unterstützen nur PaaS- oder SaaS-Produkte, bei denen der Erstellungsprozess Artefakte für den Service vorbereitet und bereitstellt. Sie können dies mit einem allgemeinen Tool orchestrieren. In einigen Fällen kann die Verwendung eines für die Anforderung spezifischen Werkzeugs vorteilhafter sein. Beispiel: Oracle Visual Builder Studio wurde für Lösungen mit Visual Builder entwickelt.

Pipelineorchestrierung mit nativer OCI mit Open Source-/Drittanbieterprodukten

Die Verwendung domänenspezifischer oder sehr anpassbarer Tools, einschließlich Open-Source-Tools wie Jenkins, kann bei der Ausführung mehr Freiheit im Erstellungsprozess bieten als bei der Verwendung nativer OCI-Lösungen. Obwohl Tools wie OCI DevOps regelmäßig neue Features veröffentlichen. Diese Flexibilität verursacht jedoch die Verwaltung weiterer Prozessphasen, wie Deployment, Patching und Überwachung, selbst bei der Ausführung typischer Pipelines.

Standardisierte Deployment Repositorys oder spezielle Produkt-Repositorys

Native Services unterstützen Ihre Anforderungen, wenn Sie Konfigurationen mit branchenüblichen Services wie OCI Git, GitLab oder GitHub und ähnlichen Tools verwalten. CI/CD-Prozesse können durch teilweise integrierte Legacy-Repositorys eingeschränkt werden. Möglicherweise müssen Sie wichtige Änderungen an der Pipeline vornehmen, um CI/CD-Prozesse mit Legacy-Repositorys verwenden zu können.

Branchenstandards entsprechende Konfigurationsverwaltungs- oder Legacy-Tools

Bei der Verwendung von Cloud-Services ist es üblich, dass der Service nur Lösungen nach Branchenstandard mit Configuration Management-(CM-)Systemen wie Git und SVN unterstützt. Diese Serviceanbieter können auch spezielle Konfigurationsverwaltungsmechanismen unterstützen, die für die eigenen Produkte des Anbieters erforderlich sind. Wenn Sie ein Legacy- oder Nischen-CM-System verwenden müssen, müssen Sie möglicherweise Drittanbieterlösungen berücksichtigen, die der CM-Systemanbieter unterstützt. Beispiel: Für die Unterstützung von CVS als Legacy-Lösung müssen Benutzer möglicherweise Tools von Drittanbietern verwenden, um die Konfiguration zu verwalten.

Multi-Cloud- oder Single-Cloud-Bereitstellung

Das Deployment derselben Kernlösung in mehreren Clouds kann zu zusätzlichen Komplexitäten führen, die Sie berücksichtigen sollten. Beispiel: Wenn der Deployment-Prozess in einen Terraform-Service integriert ist, müssen für jeden Cloud-Provider Deployment-Prozesse ausgeführt werden, die den Unterschieden zwischen verschiedenen Terraform-Providern Rechnung tragen. Es können subtilere Überlegungen wie ein Zielchipset für Docker-Images erforderlich sein, da verschiedene Images erstellt werden müssen.

Um eine bessere Sicherheit zu gewährleisten, können Sie festlegen, dass Ihre Deployment-Ziele nicht für eine externe Deployment-Lösung verfügbar gemacht werden. Beispiel: Wenn Sie das Deployment in Oracle Container Engine for Kubernetes (OKE) und Azure Kubernetes (AKE) ausführen, können Sie GitHub verwenden, um den allgemeinen Code und GitHub Actions zur Orchestrierung des Container-Builds zu speichern. Sie können AKS und OKE jedoch nicht direkt für GitHub-Aktionen verfügbar machen. Erwägen Sie stattdessen eine mehrstufige Lösung mit Azure und OCI, um die Deployment-Orchestrierung bereitzustellen und GitHub für die kontinuierlichen Build-Prozesse oder den Kerncode zu verwenden.

Ziehen Sie eine mehrstufige Lösung in Betracht, wenn Infrastructure-as-Code (IaC) Teil des Deployment-Prozesses ist. Dadurch kann jede Umgebung über eine andere IaC-Konfiguration für das Provisioning von Compute-, Speicher- und verwalteten Services verfügen. Mit Kubernetes können Sie solche Probleme begrenzen oder entfernen.

Prozessanpassung oder Bespoke-Prozesse

Wenn Sie spezielle Prozesse oder Nischenprozesse benötigen, müssen die Tools zur Unterstützung der Build-Pipeline Erweiterungen für die benutzerdefinierte Konfiguration zulassen. Der Aufbau eigener maßgeschneiderter Prozesse erfordert mehr Aufwand. Berücksichtigen und bewerten Sie das Risiko, wie zukünftige Änderungen die Anpassung verhindern können.

Skalierungspotenzial

Entwicklungs-Workloads können aufgrund von Faktoren wie allgemeinen Trends an einem Arbeitstag schwanken. Beispiel: Commits zur Nachbearbeitung von Tagesabschlussaktivitäten, die CI/CD-Prozesse auslösen, führen zu einer Erhöhung der Arbeitslast am Ende des Arbeitstages. Während Projekte ihren gesamten Lebenszyklus mit dem Erstellen, Freigeben und Bereitstellen durchlaufen, steigt die Nachfrage für die Build-Infrastruktur. Es gibt ein Muster für eine Zunahme von Anforderungen für kleine Änderungen, da kleinere Probleme am Ende der Release-/Sprintzyklen angegangen werden.

Entscheidungsmatrix prüfen

Die Architekturen und Lösungen werden unter einer gemeinsamen Anzahl gruppiert, wie z. B. 1a, 1b und 1c, je nachdem, wo sie subtile Variationen aufweisen. Beispiel: Ein einzelner Knoten für die CI/CD-Lösung oder dieselbe Lösung mit einer anderen Tooling-Konfiguration gibt an, dass die Lösung in größerem Maßstab arbeiten kann. Jede Gruppierung ist eine Spaltenüberschrift in der Entscheidungsmatrix, und jeder Faktor ist eine Zeilenüberschrift. Callouts in der Tabelle, wie ¹, geben zusätzliche Informationen an.

Architektur- und Lösungsgruppierungen

Jenkins Orchestration (mit zwei Varianten)
1. CI/CD-Pipeline für Cloud-Deployments mit Jenkins einrichten: Minimaler Deployment-Ansatz ohne Skalierung oder Resilienz
2. Jenkins im Master-/Agent-Modus bereitstellen: Skalierbares und resilientes Deployment
3. Erstellen Sie mit dem Oracle DevOps-Service eine kontinuierliche Integrations- und Deployment-Pipeline
GitLab
1. Stellen Sie GitLab bereit, um CI/CD-Pipelines auf OCI zu aktivieren
2. Stellen Sie GitLab Runner auf Oracle Container Engine for Kubernetes mit Cluster-Autoscaling bereit
OCI DevOps: Varianten für serverlose Verarbeitung und Container
1. Erstellen Sie eine CICD-Pipeline mit dem Oracle Cloud Infrastructure DevOps-Service und OCI Functions
2. Erstellen Sie mit dem Oracle DevOps-Service eine kontinuierliche Integrations- und Deployment-Pipeline
GitHub Aktionen: CI/CD-Pipeline für Cloud-Deployments mit GitHub Actions und Oracle Cloud Infrastructure DevOps Service erstellen
Moderne App-Strategie: Moderne App-Deployment-Strategien mit Oracle Cloud Infrastructure-Devops planen
Mobile Hub: CI/CD-Pipeline für Apps erstellen
Bots: CI/CD-Pipeline für benutzerdefinierte Bots-Komponenten erstellen

Die folgende Entscheidungsmatrix stellt die Abweichungen zwischen den Architekturen und Lösungen dar, mit denen Sie die geeignete für Ihre Geschäftsanforderungen ermitteln können.

Faktor	1. Jenkins-Orchestrierung	2. GitLab	3. OCI DevOps	4. GitHub-Aktionen	5. Moderne App-Strategie	6. Mobiler Hub	7. Bots (Begriffsklärung)
Container, Virtual Machine (VM) oder Spezialist	VM und Container (Obwohl bereitgestellte Lösung auf VMs ausgerichtet ist)	VM oder Container	VM und Container	VM und Container	VM und Container	Spezialist	Spezialist
Pipelineorchestrierung mit nativer OCI oder nicht verwaltet mit Open-Source-/Drittanbieterprodukten	Ja	Ja	Nein	Ja	Nein	Nein (Oracle Dev Cloud)	Nein
Standardisierte Deployment Repositorys	Ja^1,3	Ja¹	Nein	Nein (in RA-Implementierung - aber möglich)	Ja¹	Nein	Nein
Unterstützte Konfigurationsmanagement-Repositorys	GIT, SVN und andere	GIT	GIT	GIT	GIT	GIT	GIT
Multicloud- oder Einzel-Cloud-Bereitstellung	Einfach^2,3	Einzel- oder Multi-Cloud	Einzeln²	Einzel- oder Multi-Cloud	Einzeln²	Einfach	Nein
Prozessanpassung oder maßgeschneiderte Prozesse	Ja	Ja	Ja	Ja	Ja	Nein	Limitiert
Skalierungspotenzial	1a - Nein 1b - Ja	Ja	Ja	Ja	Ja	Nein	Nein

Tabellenfußnoten

Hinweis:

¹ OCIR ist standardkonform.
² Verwendet OCI, um Prozesse in anderen Umgebungen zu steuern. Aber auch die Herausforderung einer unerwünschten Exposition gegenüber Dienstleistungen in anderen Umgebungen.
³ Verwendet OCI DevOps in der Bereitstellungsphase für Option 1a, sodass diese Phase auf eine einzige Cloud beschränkt wird.