Benutzt du Jenkins? Höchstwahrscheinlich ja, denn dies ist das bislang beliebteste Projekt dieser Klasse. Ich war immer daran interessiert, mit einem der Entwickler zu sprechen und ein paar schwierige Fragen zu stellen. Hier haben wir nicht nur einen Entwickler, sondern den Schöpfer von Jenkins selbst - Kohsuke Kawaguchi .
Wie Sie wissen, ist Jenkins ein Open Source-Projekt mit einer MIT-Lizenz. Zuletzt fand die FOSDEM-Konferenz statt - die weltweit größte Konferenz für freie Software. Kostenlos, offen, mit Dutzenden von Rednern aus der ganzen Welt. Dies bedeutet, dass Sie dort jeden treffen können - sogar den Schöpfer von Jenkins. Mit einer kleinen Gruppe von Freunden und Kollegen der JUG.ru-Gruppe landeten wir überraschend dort und konnten ein gutes Interview mit dem Schöpfer von Jenkins aufnehmen.
Also, in unserem virtuellen Studio, Koske Kawaguchi (der sich vorstellen und alles im Detail erklären wird), Ruslan Akhmetzyanov ARG89 von der JUG.ru Group und Kirill Tolkachev tolkkv von CIAN , unserem ständigen Sprecher, Guru Groovy, Gradle, Spring und dem Netflix-Technologie-Stack, den Sie können aus dem Debriefing-Podcast wissen.
Ruslan: Hallo. Erzählen Sie uns zuerst ein wenig über sich und Jenkins?
Kosuke: Mein Name ist Koske, meistens bekannt als der Schöpfer von Jenkins und CTO von CloudBees. Jenkins ist ein Tool, mit dem Entwickler verschiedene Phasen des Softwarebereitstellungsprozesses automatisieren. Ich persönlich kenne mehrere Programmierer aus Russland, die Jenkins verwenden, und ich werde mich freuen, andere zu treffen.
Kirill: Ich werde mich auch vorstellen - ich bin Entwickler und organisiere auch das Moscow Jenkins Area Meetup (JAM). Ich habe umfangreiche Erfahrung mit Jenkins, insbesondere mit der Scripted / Declarative Pipeline. Können Sie mir sagen, was der CTO des Unternehmens, das Jenkins entwickelt, tut?
Kosuke: Eine der Aufgaben meines Teams ist die Interaktion mit der Community. Der Erfolg unseres Unternehmens hängt stark vom Erfolg des Open Source-Projekts ab. Eine weitere wichtige Aufgabe besteht darin, den Rest der Mitarbeiter im Unternehmen über die Funktionsweise von Open Source zu informieren. Im Allgemeinen erhalten wir eine sehr interessante Beziehung zwischen dem Unternehmen und der Community: Jeder lernt etwas voneinander und wir achten sehr auf diese Interaktion.
Sie haben auch gefragt, welche Funktion der technische Direktor ausführt. Tatsache ist, dass sich diese Funktion mit dem Wachstum des Unternehmens weiterentwickelt hat. Anfangs war ich so etwas wie ein leitender Programmierer und habe viel technische Arbeit geleistet. Aber als sich das Unternehmen entwickelte, begannen nach und nach andere Menschen, diese Arbeit zu erledigen. Zum Beispiel begann ein separates Team, sich mit Pipeline zu befassen. Ich kommuniziere regelmäßig mit ihnen, um eine Vorstellung davon zu bekommen, was sie tun. Manchmal gebe ich Ratschläge. Sie treffen jedoch alle Entscheidungen in Bezug auf Design und Entwicklung selbst. Im Allgemeinen war diese Entwicklung meiner Rolle sehr interessant, ich muss mich ständig anpassen.
Kirill: Wenn ich Sie richtig verstehe, hat sich Ihr Fokus von technischen Problemen auf die Arbeit mit der Community verlagert?
Kosuke: Ja, vieles, was ich tue, hängt damit zusammen. Es gibt Dinge, die nur der Gründer eines Unternehmens sagen kann. Daher besteht ein Teil meiner Tätigkeit relativ gesehen darin, eine Flagge zu schwenken und die Gemeinde in eine bestimmte Richtung zu rufen, wenn eine Kursänderung erforderlich ist. Wie zum Beispiel im letzten Jahr. Darüber hinaus engagieren wir uns und das Team für die Förderung von Jenkins: Wir erklären, was unsere Ziele sind, welche Schwierigkeiten wir zu überwinden versuchen. Wenn ich einen Vortrag über den allgemeinen Stand der Dinge halten muss, wecke ich außerdem mehr Selbstvertrauen. So sieht meine Tätigkeit in Kürze aus.
Kirill: Und vor wie vielen Jahren begann diese Abkehr von der technischen Arbeit zur organisatorischen Arbeit? Können Sie die Geschichte von Jenkins erzählen und wie sich Ihre Rolle im Zuge des Projektwachstums verändert hat?
Kosuke: Das Projekt erschien im Jahr 2004 und ich habe zuerst abends und am Wochenende daran gearbeitet, das heißt, es war eine Art Hobby. Aber allmählich wuchs das Projekt. Ich habe viel Zeit damit verbracht, diese Plattform zu erstellen, auf der andere Leute ihre Anwendungen schreiben können. Im Laufe der Zeit entstanden ein Ökosystem und eine Entwicklergemeinschaft, von denen einige aus Russland stammten - zum Beispiel Oleg Nenashev (Twitter: @oleg_nenashev ), der über Jenkins ein sehr interessantes Subsystem schrieb. Mit zunehmender Popularität des Projekts wurde die Notwendigkeit einer besseren Interaktion mit den Benutzern und deren Schulung immer größer. Deshalb begann ich mehr mit diesen Dingen zu tun. Schließlich wurde Jenkins um 2010 so beliebt, dass ich mich entschied, meine ganze Zeit ihm zu widmen und eine Firma zu gründen. Von diesem Moment an wurde die Arbeit an der Organisation des Unternehmens hinzugefügt, um mit der Community zusammenzuarbeiten. Das Unternehmen wuchs und ich begann mir die Frage zu stellen: Welche Art von Aktivität kann niemand außer mir ausführen? Sowohl im Unternehmen als auch in der Gemeinde gibt es viele fähige Leute, die gerne bereit sind, zusätzliche Verantwortung zu übernehmen. Allmählich fingen sie an, viel von dem zu tun, was ich früher selbst getan hatte. Im Großen und Ganzen sah unser Weg also so aus.
Kirill: Danke. Heute ist Jenkins das beliebteste CI-System. Und wie häufig ist die kommerzielle Version von Jenkins im Vergleich zu anderen kommerziellen CI-Systemen? Zum Beispiel mit Travis Enterprise oder mit Systemen, die lokal arbeiten können?
Kosuke: Open Source Jenkins ist ein großes Projekt, es hat viele Benutzer. CloudBees hat einen viel kleineren Maßstab. Wenn es uns daher gelingt, auch nur ein Prozent der Jenkins-Benutzer in CloudBees-Benutzer umzuwandeln, ist dies ein sehr großes Ergebnis. Alle auf Open Source-Produkten basierenden Unternehmen arbeiten nach diesem Prinzip. Eine weitere wichtige Frage ist, wie viel wir schaffen, um Menschen zu helfen, deren Probleme unser Produkt lösen sollte. Wir berechnen, wie effektiv unser technischer Support ist, und wenn ich mich richtig an die Statistiken erinnere, erfüllen unsere Dienstleistungen diese im Allgemeinen.
Kirill: Meinst du diejenigen, die die kostenpflichtige Version verwenden? Oder diejenigen, die auch frei haben?
Kosuke: Beide. Das heißt, wenn eine Person ein Produkt kauft, erhält sie Support, der jedoch auch ohne Verwendung einer proprietären Software erhältlich ist.
Kirill: Das heißt, Sie fungieren als Vermittler zwischen Entwicklern und Ihren Benutzern, Open Source und Werbung. Verstehe ich richtig, dass Sie auch die Aufgaben der Produktvision haben?
Kosuke: Das stimmt nicht ganz, wir haben ein separates Produktteam. Ich bin kein Vertreter des Benutzers, aber ich habe ständig Besprechungen mit vielen Menschen, Benutzern und nicht nur, das heißt, ich halte Kontakt mit der Community. Zum Beispiel habe ich eine Spalte "Zusammenfassung mit Fortgeschrittenen" für andere Mitarbeiter des Unternehmens. In diesen Beiträgen spreche ich darüber, wie unsere Benutzer Software schreiben und was dies für Jenkins bedeutet. Ich versuche also, die Entscheidungen des Produktteams zu beeinflussen.
Kirill: Anscheinend spielen Sie eine wichtige Rolle im Unternehmen. Kommen wir zu persönlicheren Themen. Was ist deine Lieblingsfunktion von Jenkins, über die du von morgens bis abends sprechen könntest?
Kosuke: Nun, es wird schwierig sein, von morgens bis abends zu sprechen. Ich bin jetzt mehr daran interessiert, wie die Organisation funktioniert - ich denke, das liegt an meiner Funktion darin. Wenn ich alleine arbeitete, konzentrierte sich meine Aufmerksamkeit viel mehr auf einzelne Merkmale. Jetzt glaube ich nicht, daher fällt es mir schwer, Ihre Frage zu beantworten.
Kirill: Dann erinnern Sie sich vielleicht an eine Funktion, die vor Jahren implementiert wurde und die sehr stolz war?
Kosuke: Ich kann über eine der jüngsten wichtigen Funktionen sprechen, an denen wir gearbeitet haben - ich denke, sie wird für Benutzer interessanter sein. Dies ist ein Projekt aus dem letzten Jahr, Jenkins Configuration as Code . Wir haben festgestellt, dass unsere Benutzer schrittweise von der Verwaltung von Jenkins mit einem Mausklick in der GUI zur Konfiguration über die Konfigurationsdatei im Git-Repository übergingen. Die Notwendigkeit einer Konfiguration als Code-Projekt war lange Zeit zu spüren, und viele temporäre Krücken wurden geschrieben, um diese Funktion auszuführen. Aber keines dieser Unternehmen war groß genug. Schließlich haben wir es geschafft, die Leute aus der Community, die an diesem neuen Projekt interessiert waren, zusammenzubringen und ein ziemlich großes und durchdachtes Werkzeug zu schaffen. Viele Aspekte dieses Projekts sind sehr gut gelaufen, und es hat eine ziemlich große Popularität erlangt, die sich nur freuen kann.
Sie können sich an ein anderes Projekt erinnern, Jenkins X, das eine Entwicklung in eine ganz andere Richtung darstellt. Es wurde speziell für die Arbeit mit Kubernetes entwickelt. Dank dieser Spezialisierung können wir eine reibungslose Integration erreichen und die Komplexität verbergen, die durch die Integration und die Verbindung kontinuierlicher Lieferprozesse entsteht. Infolgedessen machen wir es einfach, unserer Meinung nach die besten Praktiken umzusetzen. Ich denke, dass Jenkins dank dieses Projekts einer großen Anzahl von Personen zur Verfügung stehen wird, die ganz normale Aktionen ausführen und nicht viel Zeit mit der Konfiguration verbringen möchten, für die alles erforderlich ist.
Ruslan: Verwenden Sie Jenkins beim Schreiben von Jenkins?
Kosuke: Ja, das Jenkins-Projekt hat seine eigenen Jenkins. Tatsächlich haben wir eine große Instanz, die für jedes Plugin und jeden Kern eine Pull-Rique-Überprüfung durchführt. Darüber hinaus gibt es eine Kopie für besonders wichtige Arbeiten im Zusammenhang mit Sicherheit und Sicherheitslücken, da die Entwicklung von Sicherheitsfunktionen in einem separaten, proprietären Repository erfolgt. Schließlich gibt es eine dritte Instanz für noch wichtigere Aufgaben wie das Signieren von Schlüsseln und Dinge, die mit Releases zusammenhängen. Zusätzlich zu diesen drei arbeitet in meinem Haus rund um die Uhr eine separate Kopie.
Kirill: Sie haben Jenkins X erwähnt. Jenkins selbst ist wie ein Schweizer Messer, mit Plugins kann es alles. Im Gegenteil, Jenkins X ist hochspezialisiert, existiert für Pipeline und arbeitet mit Kubernetes. Welche technische Strategie verfolgen Sie und Ihr Unternehmen? Unterstützen Sie nur Jenkins und Jenkins X? Oder gibt es außerdem Jenkins XX für Mesos-Cluster, Jenkins XXX für Cloud Foundry und so weiter?
Kosuke: Ich denke, viel hängt von der Reaktion der Community ab. Eine universelle Plattform zu haben ist natürlich sehr wichtig. Die Frage ist, wer genau diese Flexibilität umsetzt. Heutzutage haben Benutzer normalerweise direkten Zugriff darauf. Dies ist praktisch, wenn Sie ein großes Unternehmen sind und etwas Ungewöhnliches tun. Gleichzeitig kenne ich viele Menschen, die eine solche Flexibilität nicht benötigen. Stellen Sie sich vor, Sie wären ins Esszimmer gekommen und hätten darum gebeten, ein Sandwich zu machen. Sie haben die Wahl zwischen sieben Brotsorten, fünf Butterarten und vier Käsesorten, und Sie müssen sich für alle Zutaten entscheiden. Aber Sie brauchen nicht all diese Auswahl, Sie brauchen nur ein leckeres Sandwich und Sie möchten nicht herausfinden, wie Sie es richtig machen. Ich weiß, dass viele Menschen diese Einstellung zu Jenkins haben und möchten, dass die ganze Flexibilität auf unserer Seite bleibt. Jenkins X ist der erste ernsthafte Schritt in diese Richtung. Wenn dieses Projekt weiterhin erfolgreich ist, würde ich gerne versuchen, etwas Ähnliches für Firmware und IoT, mobile Plattformen oder maschinelles Lernen zu tun. Ich denke, es gibt viele vertikale Märkte, in denen die Menschen nur ein Werkzeug benötigen, mit dem sie das Produkt schnell in Produktion bringen können. Sie kommen aus Russland, wissen also höchstwahrscheinlich etwas über JetBrains?
Kirill: Natürlich.
Kosuke: Ich denke, sie verfolgen eine ähnliche Strategie. Sie haben eine sehr flexible Grundlage, auf der sich viele weitere spezialisierte Add-Ons befinden, in denen im Wesentlichen dieselben Elemente auf unterschiedliche Weise zusammengesetzt werden. Die Benutzer sind ihnen dafür dankbar, und ich mag ihren Ansatz sehr.
Kirill: Seit vielen Jahren beobachte ich in vielen Communities dasselbe Bild, wenn ich Ihnen rate, das eine oder andere Plug-In zu verwenden. Übrigens, jetzt hilft mir https://plugins.jenkins.io sehr, alle genehmigten Plugins sind da. Das Problem ist, dass Menschen in allen Fällen versuchen, ein universelles Werkzeug zu verwenden, das für einen bestimmten Fall oft nicht geeignet ist. Daher empfehle ich jetzt normalerweise nur ein Werkzeug - Pipeline, ein ideales Werkzeug, das in allen Situationen geeignet ist. Es entsteht jedoch ein neues Problem. Menschen versuchen, die Skript-Pipeline oder die deklarative Pipeline zu verwenden, ohne zu verstehen, wie sie intern angeordnet sind. Es gibt Probleme mit der Infrastruktur, mit der Herstellung der Korrespondenz zwischen Knoten, der gemeinsamen Nutzung von Daten, ungewöhnlichem Datenverkehr zwischen dem Agenten und dem Master oder Problemen mit der Skalierung auf dem Master. Welches Tool ist aus Ihrer Sicht besser: dasjenige, das den einzig richtigen Weg zur Lösung des Problems angibt, wie Jenkins X? Oder ein Tool wie Scripted Pipeline, das Sie fragt, was genau Sie vorhatten?
Kosuke: Ich bin nicht sicher, ob ich dich richtig verstanden habe, aber ich werde versuchen zu antworten. Im Japanischen gibt es das Wort "Kata", ich weiß nicht, wie ich es genau übersetzen soll. Es wird unter anderem im Judo verwendet. Wir sprechen über streng definierte Bewegungen, die die Schüler lernen: zum Beispiel eine Hand auf eine bestimmte Weise zu heben, um einen bestimmten Schlag abzulenken. Ich habe ein wenig davon gemacht, also kenne ich die einfachste von ihnen. Die Herausforderung besteht darin, sich eine Reihe einfacher Bewegungen, Muster oder Best Practices zu merken. Dies ist jedoch nur der Anfang. Wenn Sie diese Basis kennen, können Sie sie weiterhin korrekt belassen, wenn die Situation dies erfordert, ohne die Grundbewegungen selbst zu verletzen. Sie studieren Ihren eigenen Raum, Ihr Territorium, aber gleichzeitig hilft es Ihnen trotzdem, die gemeinsame Basis zu kennen. Wenn Sie sie nicht kennen, werden Sie sich immer fragen: Tue ich das Richtige? Auch wenn das, was Sie geschrieben haben, funktioniert, haben Sie immer noch Zweifel.
Im Allgemeinen erinnerte mich Ihre Frage an Kata. Ich denke, wir haben eine ähnliche Situation mit Jenkins. Jenkins X bietet eine Basis, und wenn Sie anfangen, sie besser zu verstehen, können Sie sie bei Bedarf mithilfe von Plugins und anderen Dingen verlassen. Natürlich muss Jenkins X auf Flexibilität verzichten, um eine bessere Erfahrung mit Kubernetes zu ermöglichen. Die Tatsache, dass Jenkins X Sie zu Best Practices drängt, bedeutet jedoch nicht, dass Ihnen die Wahl genommen wird. Im Großen und Ganzen gilt dies in Bezug auf jede Software. Es ist nur so, dass wir mit Jenkins X eine wichtige Änderung in der Denkweise hatten. Bisher haben wir nur die Schlüsselelemente des Systems erstellt - die Plattform und die Plugins. Es war Sache des Benutzers, sie zusammenzusetzen. Mit Jenkins X ist die Community zu einem neuen Ansatz übergegangen, und meiner Meinung nach ist dies ein sehr wichtiger Schritt.
Kirill: Wenn es Ihnen nichts ausmacht, werde ich noch zwei Fragen haben. Welche Funktion hat Ihnen im letzten Jahr die meisten Probleme bereitet? Jedes Projekt hat schwierige Phasen - können Sie uns sagen, wie sie ausgesehen haben?
Kosuke: Wir haben unser Leben mehrmals ernsthaft ruiniert. Das Problem ist, dass unser Projekt mit dem Wachstum von Jenkins immer mehr Aufmerksamkeit von anderen Unternehmen und deren Sicherheitsteams auf sich zog, die nach Löchern in Jenkins suchten. Daher begann die Anzahl der von außen an uns gerichteten Schwachstellenberichte exponentiell zu wachsen. Manchmal wurde es ein wenig beängstigend, besonders wenn man bedenkt, dass einige dieser Anfragen mit einer Frist versehen waren, bis zu der wir die Sicherheitsanfälligkeit schließen mussten. Dies war besonders schwierig, wenn es um von der Community erstellte Funktionen ging. Darüber hinaus werden Benutzer bei der Installation von Updates mit behobenen Sicherheitslücken manchmal gestört. Wir arbeiten hart daran, dies zu verhindern, da Benutzer sonst Angst haben, Sicherheitsupdates zu installieren, was äußerst unerwünscht ist.
Kirill: Haben Sie ein Leitungsgremium, das entscheidet, welche Funktionen in der Veröffentlichung enthalten sein werden? Bitte teilen Sie uns mit, wie solche Entscheidungen getroffen werden, und können Benutzer darum bitten, einige Funktionen in die Version aufzunehmen? Wenn dies möglich ist, wem wird dann Priorität eingeräumt - Benutzern von CouldBees oder Open Source Jenkins? Wenn möglich, teilen Sie uns zum Schluss Ihre Pläne für die nächsten sechs Monate bis zu einem Jahr mit.
Koske: Hier gibt es einen interessanten Punkt: CloudBees besitzt keine Jenkins, dies sind zwei separate Projekte, jedes mit seiner eigenen Entscheidungsstruktur. CloudBees leistet einfach den größten Beitrag von Jenkins. Viele CloudBees-Mitarbeiter arbeiten parallel in der Community. In den letzten Jahren haben wir versucht, bei Jenkins klarere Kontrollstrukturen zu schaffen, die genau das tun, was Sie gerade gefragt haben. Zu diesem Zweck haben wir den Jenkins-Verbesserungsprozess erstellt ...
Cyril: Tut mir leid zu unterbrechen - wird es wie in Java als JEP abgekürzt?
Kosuke: Auf jeden Fall. Offensichtlich haben wir dieses Konzept nicht erfunden, sondern von Python, Java und einigen anderen Communities ausgeliehen, da es sich dort bereits etabliert hat. Die Hauptidee dabei ist, dass die Community in der Lage sein sollte, ihre Meinung zu äußern und einen Konsens zu erzielen, bevor umfangreiche Arbeiten an einem Feature beginnen. Genau dies tun wir, wenn CloudBees eine neue Funktion erstellen wird, sodass wir die Möglichkeit haben, den Kurs abhängig von der erhaltenen Antwort zu ändern. Dies ist das Planungselement, das wir in unserer Arbeit umsetzen konnten. Da wir ein Open Source-Projekt sind, können wir anderen Projektteilnehmern nicht direkt sagen, was zu tun ist. Manchmal hören sie auf unsere Stimme, manchmal nicht.
Was unsere Pläne für die nächsten sechs Monate betrifft, werden wir höchstwahrscheinlich weiterhin an vielen unserer derzeitigen Bemühungen arbeiten, einschließlich Jenkins X. Einige CloudBees-Mitarbeiter und viele Drittanbieter arbeiten daran. Ich hoffe, dass Configuration as Code bei Plugin-Entwicklern immer beliebter wird. Im Großen und Ganzen haben wir bereits die Basis dafür geschaffen, daher müssen wir jetzt einige Plugins konfigurieren, damit sie über dieses System korrekt verbunden werden können. Wenn schließlich neue JEPs entstehen, werden wir daran arbeiten.
Kirill: Nun, hoffen wir, dass JEP nicht patentiert ist :) Frage an Sie als Autor von Jenkins - wessen Idee war Scripted Pipeline?
Kosuke: Das ist eine interessante Frage. Tatsache ist, dass viele Initiativen in der Gemeinde oft keine kritische Masse erreichen und auf experimenteller Ebene bleiben. Bevor wir mit der Arbeit an Pipeline begannen, versuchten die Leute bereits im selben Raum, etwas Ähnliches zu tun, und wir hatten die Gelegenheit, uns mit diesen Versuchen vertraut zu machen. Wir waren also nicht die Erfinder der Pipeline. Einer dieser Vorgänger war das Build Flow-Plugin, das von einem CloudBees-Mitarbeiter vor seinem Eintritt in das Unternehmen geschrieben wurde. Ich denke, der Begriff „Ökosystem“ ist sehr erfolgreich - alles geschieht wirklich wie in einem realen Ökosystem, eine Technologie, die von jemandem entwickelt wurde, entwickelt sich ständig weiter und verändert sich.
Ruslan: Haben Sie die Implementierung von Scripted Pipeline beeinflusst?
Kosuke: Ja, in der Originalversion.
Kirill: Wie wir wissen, gibt es zwei Möglichkeiten, DSL zu implementieren - statisch und dynamisch. Warum wurde der dynamische Ansatz für die Scripted Pipeline gewählt?
Kosuke: Ich fürchte, ich verstehe nicht ganz, was genau Sie unter statischen und dynamischen Ansätzen verstehen.
Kirill: Mit einem statischen DSL haben wir vor der Ausführung ein gewisses Vertrauen in unseren Code. Bei DSL in Java müssen Sie beispielsweise alle APIs und Schnittstellen im Voraus kennen. Mit einem dynamischen Ansatz führen wir die Überprüfung direkt bei der Ausführung durch. Selbst wenn der Code ungültig ist, versucht der Computer dennoch, ihn auszuführen. Bei Bedarf wird lediglich ein Fehler ausgegeben. Mit der deklarativen Version der Pipeline können Sie viele Fehler beseitigen, indem Sie die Variabilität im Build-Skript einschränken.
Kosuke: Um ehrlich zu sein, ist es mir eigentlich egal, wann die Zusammenstellung stattfindet. Aber ich kann über die allgemeinen Einstellungen sprechen, die wir beim Entwerfen der Skript-Pipeline befolgt haben. Zu einem bestimmten Zeitpunkt wurde eine erhebliche Anzahl von Jenkins-Benutzern durch die Komplexität der Automatisierung stark behindert. Es war notwendig, das korrekte Zusammenspiel vieler Komponenten sicherzustellen. Der Code wird kompiliert, Tests werden ausgeführt, dann müssen Sie warten, bis die Bereitstellung bestätigt wurde, und so weiter. , — Infrastructure as Code. , . Scripted Pipeline. , Pipeline , , Scripted Pipeline, . , , . Declarative Pipeline.
: , -, Jenkins, API . -, Scripted Pipeline, DSL. Declarative Pipeline , . — Pipeline Jenkins? , Jenkins.
: , , . , Pipeline, , , . Freestyle Job, Jenkins, . - , , Freestyle Job . , , . , Pipeline . - — , Shared Libraries. , . . , .
: Jenkins. Jenkins 2. API . Jenkins , , , , . , , ?
: , . , . Jenkins. , 800 , 1600 — , , . , . , . « » , , , , , . , , .
: , Java? 15-, 20- . Python 2 Python 3, ? ?
: , , , Java Python. , . , Jenkins , . , . , , . , , , . , , , Jenkins X. , , .
: , !
5-6 JPoint «Superpowers coming to your Jenkins» . , . JPoint ( , ).