Jenkins gegen Azure DevOps Pipelines

Ich habe einige Nachforschungen über die Azure DevOps-Lösung angestellt, die Microsoft kürzlich vorgestellt hat .

Einige Hintergrundinformationen, ich benutze Jenkins seit Jahren und habe vor kurzem begonnen, das Containerisierungskaninchenloch (Docker, Kubernetes usw.) zu erkunden.

Bei einigen Aspekten von Azure DevOps-Pipelines bin ich mir nicht sicher, und es wäre großartig, Feedback und Klarheit zu erhalten.

TL; DR

1. Konkurriert Azure DevOps jetzt mit Jenkins, wo sie zuvor die Jenkins-Community über Open Source-Plugins für Jenkins unterstützt haben?
2. Kann ich Azure DevOps Pipelines vollständig vor Ort hosten, nicht nur Agenten?
3. Ist es möglich, eine selbst gehostete Git-Lösung (wie GitLab vor Ort) mit Azure DevOps Pipelines zu verwenden?

Längere Version

1. Microsoft hat verschiedene Open-Source-Plugins für Jenkins entwickelt, beispielsweise das Azure App Service Jenkins-Plugin . Es gibt viele Beispiele. Mir scheint, dass die Azure DevOps-Lösung (speziell Pipelines) jetzt direkt mit Jenkins konkurriert, oder fehlt mir etwas?
2. Mir scheint, dass es keine Möglichkeit gibt, die Azure Pipelines-Lösung vor Ort oder bei einem Cloud-Anbieter meiner Wahl zu hosten. Ja, ich kann meine eigenen Agenten hosten, auf denen der Großteil der Arbeit ausgeführt wird, aber die eigentliche Ausführung der Pipeline-Logik erfolgt auf den Servern von Microsoft. Und dann muss ich für Paralleljobs bezahlen . Ich vergleiche dies mit einer vor Ort (oder einem Cloud-Anbieter Ihrer Wahl) gehosteten Jenkins-Instanz, bei der keine Zahlung erforderlich ist und kein Dritter überhaupt weiß, dass unsere Pipelines ausgeführt werden. Vermisse ich etwas
3. Soweit ich weiß, unterstützt Azure Pipelines keine selbst gehosteten Repositorys. Ich habe meinen Code entweder auf GitHub oder auf Azure-Repos abgelegt , sonst nichts. Daher kann ich diese Pipelines-Lösung nicht einmal verwenden, wenn ich eine privat gehostete GitLab-Instanz habe.

Vielen Dank für jede Eingabe.

Ich würde gerne auch Klarheit bekommen, vielleicht aus einer maßgeblicheren Quelle als ich selbst (ich bin sicher, dass ich mich auch der FUD schuldig gemacht habe).

Ich habe versucht, mithilfe von Kubernetes in Azure bereitzustellen. Ich bin ähnlich verwirrt, aber ich denke, das liegt daran, dass es keinen klaren Weg gibt. Ich kann nicht für Microsoft sprechen, aber ihre Einstellung zur Cloud scheint zu sein, dass sie glücklich sind, " alles für alle Männer " zu werden. Wenn Sie Azure verwenden, scheint Microsoft keine feste Meinung darüber zu haben, wie Sie dorthin gelangen.

Microsoft versucht aktiv, sich weiterzuentwickeln. zB Linux dominiert jetzt Azure

Die Azure DevOps- Bereitstellungspipeline macht eindeutig genau das, was Jenkins kann - in diesem Sinne ist es also ein Konkurrent. Es gibt auch die etwas abstoßende Vorauszahlung von Azure DevOps für parallele Pipelines.

Einerseits scheint Azure DevOps ein Rebranding von Visual Studio Team Services zu sein. Daher sind Personen bereits im traditionellen Microsoft-Entwicklungsökosystem vertraut. Gleichzeitig unternimmt Microsoft große Anstrengungen, um Technologien zu nutzen, die nicht traditionell von Microsoft stammen ( Go, Java, Node.js, Python, Ruby, PHP usw.).

Es ist noch früh - aber es ist keine Überraschung, dass Azure DevOps-Pipelines die Microsoft Git-Eigenschaften von Azure Repos und GitHub bevorzugen sollten. Ebenso wie BitBucket-Pipelines BitBucket- und GitLab-Pipelines GitLab bevorzugen.

Inzwischen;

Der Azure Marketplace bietet eine Jenkins-Bereitstellung , die standardmäßig mit Azure-Bereitstellungs-Plugins geliefert wird.

Viele Jenkins-Plugins wurden vom Azure DevOps-Team entwickelt .

und dazu;

Microsoft hat Kubernetes-bezogene Projekte Helm und Draft unterstützt . Helm ist Paketmanager für Kubernetes. Sie können Helm sogar verwenden, um eine Jenkins-Installation in Kubernetes bereitzustellen.

- -

Es wäre interessant zu sehen, wie jemand die Vorteile, Kosten und den Aufwand für die Ausführung eigener Jenkins in Azure-Versen mithilfe von Azure DevOps-Pipelines abwägt.

... und dann ist da noch Jenkins-X .

Es scheint also, dass wir viele Optionen und Entscheidungen treffen müssen.

Als Antwort auf Teil 2 (vielleicht) scheint es, als würden sie es als Alternative zu Jenkins aufstellen, obwohl es zahlreiche Dokumentationen gibt, die darauf hinweisen, dass alles zusammen (und hier ) verwendet werden kann. Bei Verwendung mit Jenkins scheint es sich jedoch eher auf eine Bereitstellungsbrücke zu konzentrieren. Ich hatte gehofft, dass ich es als Build-Agent mit Jenkins als Orchestrator verwenden kann, wie ich es mit Jenkins & AWS CodeBuild tun könnte. Ich habe noch nichts gesehen, was darauf hindeutet, dass ich dies tun könnte, aber vielleicht ... Multi-Cloud-Bereitstellungen sind jedoch sehr faszinierend ...

1. Ja, da Azure Pipelines das können, was Jenkins tut. Sie müssen das Baby jedoch nicht mit dem Badewasser hinauswerfen. Microsoft positioniert seine Plattformen weiterhin so, dass Integrationen mit vorhandenen Installationen von nahezu allem möglich sind. Viele Organisationen haben enorme Investitionen in Werkzeuge, die schwer zu ändern sind. Anstatt alles oder nichts einzunehmen, setzt Microsoft auf Standards und eine eigene Mentalität, sodass Sie die ultimative Wahl haben, wie Sie die Tools implementieren möchten.

2. Die Agenten sind technisch gesehen Ihre Pipeline, da die Aufgaben für die Agenten ausgeführt werden, auf die in der Pipeline abgezielt wird. Alles, was Sie im Portal konfigurieren, sind die Schritte, die die Pipeline ausführen wird. Die Agenten laden Tools / Erweiterungen herunter, die zur Ausführung der Aufgaben erforderlich sind. Darüber hinaus werden mit den neuen YAML-Pipelines die Pipelines in Ihren Code-Repos definiert. Beim Hosting können Sie Azure DevOps Server vollständig vor Ort, in einem beliebigen Cloud-Anbieter oder in einer Kombination aus Azure-VMs und Azure SQL hosten.

3. Generische Git-Repositorys werden in Azure DevOps Services mit dem klassischen Editor oder sowohl mit YAML als auch mit dem klassischen Editor unterstützt, wenn derzeit Azure DevOps Server (vor Ort) verwendet wird. Sie können die GitLab-Repository-Integration hinzufügen, indem Sie die Erweiterung installieren.