Apakah Anda menggunakan Jenkins? Kemungkinan besar ya, karena ini adalah proyek paling populer di kelas ini hingga saat ini. Saya selalu tertarik untuk berbicara dengan salah satu pengembang dan mengajukan beberapa pertanyaan sulit. Di sini, kami tidak hanya memiliki pengembang, tetapi juga pencipta Jenkins - Kohsuke Kawaguchi .
Seperti yang Anda ketahui, Jenkins adalah proyek sumber terbuka dengan lisensi MIT. Baru-baru ini, konferensi FOSDEM diadakan - konferensi terbesar di dunia yang ditujukan untuk perangkat lunak bebas. Gratis, terbuka, dengan puluhan pembicara dari seluruh dunia. Ini berarti bahwa Anda dapat bertemu siapa pun di sana - bahkan pencipta Jenkins. Dengan sekelompok kecil teman dan kolega di Grup JUG.ru, kami melakukan pendaratan yang mengejutkan di sana dan dapat merekam wawancara yang baik dengan pencipta Jenkins.
Jadi, di studio virtual kami, Koske Kawaguchi (yang akan memperkenalkan dirinya dan menjelaskan semuanya secara rinci di bawah), Ruslan Akhmetzyanov ARG89 dari Grup JUG.ru dan Kirill Tolkachev tolkkv dari CIAN , pembicara tetap kami, guru Groovy, Gradle, Spring dan tumpukan teknologi Netflix, yang Anda bisa tahu dari podcast Pembekalan.
Ruslan: Halo. Pertama, ceritakan sedikit tentang diri Anda dan tentang Jenkins?
Kosuke: Nama saya Koske, sebagian besar dikenal sebagai pencipta Jenkins dan CTO CloudBees. Jenkins adalah alat yang digunakan pengembang untuk mengotomatisasi berbagai tahap proses pengiriman perangkat lunak. Saya pribadi kenal beberapa programmer dari Rusia yang menggunakan Jenkins, dan saya akan senang bertemu dengan yang lain.
Kirill: Saya juga akan memperkenalkan diri - Saya adalah seorang pengembang dan juga menyelenggarakan Pertemuan Daerah Jenkins Moskow (JAM). Saya memiliki pengalaman luas menggunakan Jenkins, terutama Scripted / Declarative Pipeline. Bisakah Anda memberi tahu saya apa yang dilakukan CTO perusahaan yang sedang mengembangkan Jenkins?
Kosuke: Salah satu tugas tim saya adalah berinteraksi dengan komunitas. Keberhasilan perusahaan kami sangat tergantung pada keberhasilan proyek sumber terbuka. Tugas penting lainnya adalah mengedukasi orang-orang di perusahaan tentang cara kerja open source. Secara umum, kami mendapatkan hubungan yang sangat menarik antara perusahaan dan komunitas: semua orang saling belajar sesuatu, dan kami sangat memperhatikan interaksi ini.
Anda juga bertanya fungsi apa yang dilakukan direktur teknis. Faktanya adalah bahwa fungsi ini telah berkembang seiring dengan perkembangan perusahaan. Pada awalnya, saya adalah sesuatu seperti programmer utama dan melakukan banyak pekerjaan teknis. Tetapi ketika perusahaan berkembang, orang lain secara bertahap mulai melakukan pekerjaan ini. Misalnya, tim terpisah mulai berurusan dengan Pipeline. Saya berkomunikasi secara berkala dengan mereka untuk memiliki gagasan tentang apa yang mereka lakukan, kadang-kadang saya memberikan saran. Tetapi mereka membuat semua keputusan yang terkait dengan desain dan pengembangan sendiri. Secara umum, evolusi peran saya ini sangat menarik, saya harus terus beradaptasi.
Kirill: Jika saya mengerti Anda dengan benar, maka fokus Anda telah beralih dari masalah teknis menjadi bekerja dengan komunitas?
Kosuke: Ya, banyak hal yang saya lakukan terkait dengan ini. Ada hal-hal yang hanya bisa dikatakan oleh pendiri perusahaan. Karena itu, bagian dari kegiatan saya adalah, secara relatif, mengibarkan bendera dan mendorong masyarakat ke arah tertentu ketika perubahan tentu saja diperlukan., Seperti itu, misalnya, tahun lalu. Selain itu, kami dan tim terlibat dalam promosi Jenkins: kami menjelaskan apa tujuan kami, kesulitan apa yang kami coba atasi. Selain itu, ketika saya perlu membuat presentasi tentang keadaan umum, saya menginspirasi lebih banyak kepercayaan. Seperti inilah aktivitas saya secara singkat.
Kirill: Dan berapa tahun yang lalu keberangkatan ini dari pekerjaan teknis ke pekerjaan organisasi dimulai? Bisakah Anda menceritakan kisah Jenkins dan bagaimana peran Anda berubah saat proyek tumbuh?
Kosuke: Proyek ini muncul pada 2004, dan pada awalnya saya mengerjakannya di malam hari dan pada akhir pekan, itu adalah semacam hobi. Namun lambat laun proyek itu berkembang. Saya menghabiskan cukup banyak waktu membuat platform ini di mana orang lain dapat menulis aplikasi mereka. Seiring waktu, sebuah ekosistem dan komunitas pengembang muncul, beberapa di antaranya berasal dari Rusia - misalnya, Oleg Nenashev (Twitter: @oleg_nenashev ), yang menulis subsistem yang sangat menarik di atas Jenkins. Ketika proyek mendapatkan popularitas, kebutuhan untuk interaksi yang lebih baik dengan pengguna dan pelatihan mereka menjadi lebih akut. Karena itu, saya mulai berbuat lebih banyak dengan hal-hal ini. Akhirnya, sekitar 2010, Jenkins menjadi sangat populer sehingga saya memutuskan untuk mencurahkan seluruh waktu saya kepadanya dan mendirikan perusahaan. Mulai saat ini, bekerja pada organisasi perusahaan ditambahkan untuk bekerja dengan masyarakat. Perusahaan berkembang, dan saya mulai bertanya pada diri sendiri pertanyaan - kegiatan apa yang tidak bisa dilakukan oleh siapa pun selain saya? Baik di perusahaan maupun di masyarakat ada banyak orang yang mampu yang siap untuk mengambil tanggung jawab tambahan. Perlahan-lahan, mereka mulai melakukan banyak hal yang dulu saya lakukan sendiri. Jadi, pada umumnya, jalan kami tampak seperti.
Kirill: Terima kasih. Saat ini, Jenkins adalah sistem CI paling populer. Dan seberapa umum versi komersial Jenkins dibandingkan dengan sistem CI komersial lainnya? Misalnya, dengan Travis Enterprise atau dengan sistem yang dapat bekerja secara lokal?
Kosuke: Sumber terbuka Jenkins adalah proyek besar, ia memiliki banyak pengguna. CloudBees memiliki skala yang jauh lebih kecil. Oleh karena itu, jika kami berhasil mengubah bahkan satu persen dari basis pengguna Jenkins menjadi pengguna CloudBees, ini akan menjadi hasil yang sangat besar. Semua perusahaan yang berbasis produk open source bekerja berdasarkan prinsip ini. Pertanyaan penting lainnya adalah seberapa besar kita mengelola untuk membantu orang-orang yang masalah yang harus dipecahkan oleh produk kita. Kami menghitung seberapa efektif dukungan teknis kami, dan jika saya mengingat statistik dengan benar, secara umum, layanan kami memuaskan mereka.
Kirill: Apakah yang Anda maksud adalah mereka yang menggunakan versi berbayar? Atau mereka yang punya gratis juga?
Kosuke: Keduanya. Artinya, jika seseorang membeli produk, dia akan diberikan dukungan, tetapi itu juga dapat diperoleh tanpa menggunakan perangkat lunak berpemilik.
Kirill: Yaitu, Anda bertindak sebagai perantara antara pengembang dan pengguna Anda, open source dan komersial. Apakah saya mengerti benar bahwa Anda juga memiliki tugas visi produk?
Kosuke: Ini tidak sepenuhnya benar, kami memiliki tim produk terpisah. Saya bukan perwakilan pengguna, tetapi saya terus-menerus melakukan pertemuan dengan banyak orang, pengguna dan tidak hanya, yaitu, saya tetap berhubungan dengan komunitas. Misalnya, saya memiliki kolom "Ringkasan dengan lanjutan" untuk karyawan perusahaan lainnya. Dalam posting ini, saya berbicara tentang bagaimana pengguna kami menulis perangkat lunak dan apa artinya bagi Jenkins. Jadi saya mencoba untuk mempengaruhi keputusan yang dibuat oleh tim produk.
Kirill: Rupanya, Anda memainkan peran penting dalam perusahaan. Mari kita beralih ke masalah yang lebih pribadi. Apa fitur Jenkins favorit Anda yang bisa Anda bicarakan dari pagi hingga malam?
Kosuke: Ya, berbicara dari pagi hingga malam akan sulit. Saya sekarang lebih tertarik pada cara kerja organisasi - saya pikir ini karena fungsi saya di dalamnya. Ketika saya bekerja sendirian, perhatian saya jauh lebih terfokus pada fitur individu. Sekarang saya rasa tidak, jadi sulit bagi saya untuk menjawab pertanyaan Anda.
Kirill: Lalu, mungkin, Anda ingat beberapa fitur yang diterapkan bertahun-tahun yang lalu dan mana yang sangat bangga?
Kosuke: Saya dapat berbicara tentang salah satu fitur penting terbaru yang kami kerjakan - saya pikir ini akan lebih menarik bagi pengguna. Ini adalah proyek dari tahun lalu, Jenkins Configuration as Code . Kami melihat bahwa pengguna kami secara bertahap berpindah dari mengelola Jenkins dengan mengklik mouse di GUI ke mengkonfigurasi melalui file konfigurasi di repositori git. Kebutuhan akan Konfigurasi sebagai proyek Code dirasakan untuk waktu yang lama, dan banyak kruk sementara ditulis untuk menjalankan fungsi ini. Tetapi tidak satu pun dari usaha ini yang cukup besar. Akhirnya, kami berhasil menyatukan orang-orang dari komunitas yang tertarik pada proyek baru ini dan membuat alat yang cukup besar dan bijaksana. Banyak aspek dari proyek ini ternyata sangat baik, dan itu mendapatkan popularitas yang cukup luas, yang tidak bisa tidak bersuka cita.
Anda dapat mengingat proyek lain, Jenkins X, yang merupakan evolusi ke arah yang sama sekali berbeda. Itu dibuat khusus untuk bekerja dengan Kubernetes. Berkat spesialisasi ini, kami dapat mencapai integrasi yang lancar dan menyembunyikan kerumitan yang timbul karena integrasi dan karena koneksi proses pengiriman yang berkelanjutan. Sebagai hasilnya, kami membuatnya mudah untuk menerapkan yang terbaik, menurut pendapat kami, praktik. Saya pikir berkat proyek ini, Jenkins akan tersedia untuk sejumlah besar orang yang melakukan tindakan yang cukup standar dan tidak ingin menghabiskan banyak waktu untuk konfigurasi, yang membutuhkan segalanya untuk bekerja.
Ruslan: Apakah Anda menggunakan Jenkins saat menulis Jenkins?
Kosuke: Ya, proyek Jenkins memiliki Jenkins sendiri. Faktanya, kami memiliki contoh besar yang menjalankan review pull-rique pada setiap plugin dan core. Selain itu, ada salinan untuk pekerjaan yang sangat penting terkait dengan keamanan dan kerentanan, karena pengembangan fitur-fitur untuk keamanan terjadi dalam repositori kepemilikan yang terpisah. Akhirnya, ada contoh ketiga untuk tugas yang bahkan lebih penting seperti menandatangani kunci dan hal-hal yang berkaitan dengan rilis. Selain ketiganya, salinan terpisah berfungsi di rumah saya sepanjang waktu.
Kirill: Anda menyebut Jenkins X. Jenkins sendiri seperti pisau Swiss, dengan plugin dapat melakukan apa saja. Tetapi Jenkins X, sebaliknya, sangat terspesialisasi, ia ada untuk Pipeline dan bekerja dengan Kubernetes. Strategi teknis seperti apa yang Anda dan perusahaan Anda patuhi? Apakah Anda hanya mendukung Jenkins dan Jenkins X? Atau, selain ini, juga akan ada Jenkins XX untuk cluster Mesos, Jenkins XXX untuk Cloud Foundry dan sebagainya?
Kosuke: Saya pikir banyak tergantung pada reaksi masyarakat. Memiliki platform universal tentu saja sangat penting. Pertanyaannya adalah siapa yang sebenarnya menerapkan fleksibilitas ini. Saat ini, pengguna cenderung memiliki akses langsung ke sana. Ini nyaman jika Anda adalah perusahaan besar dan melakukan sesuatu yang tidak biasa. Tetapi pada saat yang sama, saya tahu banyak orang yang tidak membutuhkan fleksibilitas seperti itu. Bayangkan Anda datang ke ruang makan dan meminta Anda membuat sandwich. Anda ditawari pilihan tujuh jenis roti, lima jenis mentega, empat jenis keju, dan Anda harus memutuskan semua bahan. Tetapi Anda tidak membutuhkan semua pilihan ini, Anda hanya perlu sandwich lezat, dan Anda tidak ingin mencari cara untuk memperbaikinya. Saya tahu bahwa banyak orang memiliki sikap terhadap Jenkins dan menginginkan semua fleksibilitas untuk tetap berada di pihak kita. Jenkins X adalah langkah serius pertama ke arah ini. Jika proyek ini terus berhasil, saya ingin mencoba melakukan sesuatu yang serupa untuk firmware dan IoT, platform seluler atau pembelajaran mesin. Saya pikir ada banyak pasar vertikal di mana orang hanya membutuhkan alat yang akan memungkinkan mereka dengan cepat membawa produk ke produksi. Anda dari Rusia, jadi kemungkinan besar Anda tahu tentang JetBrains?
Kirill: Tentu saja.
Kosuke: Saya pikir mereka mengikuti strategi yang sama. Mereka memiliki fondasi yang sangat fleksibel, di atasnya terdapat banyak tambahan khusus, di mana, pada dasarnya, elemen yang sama dirakit dengan cara yang berbeda. Pengguna berterima kasih kepada mereka untuk ini, dan saya sangat suka pendekatan mereka.
Kirill: Selama bertahun-tahun saya telah mengamati gambar yang sama di banyak komunitas, ketika saya menyarankan Anda untuk menggunakan satu atau lain plug-in - omong-omong, https://plugins.jenkins.io banyak membantu saya sekarang, ada semua plug-in yang disetujui di sana. Masalahnya adalah orang-orang berusaha agar semua kasus menggunakan satu alat universal, yang seringkali tidak cocok untuk kasus tertentu. Karena itu, sekarang saya biasanya merekomendasikan hanya satu alat - Pipeline, yang merupakan alat ideal yang cocok dalam semua situasi. Namun muncul masalah baru. Orang-orang mencoba untuk menggunakan Scripted Pipeline atau Declarative Pipeline tanpa memahami bagaimana mereka diatur secara internal. Ada masalah dengan infrastruktur, dengan pembentukan korespondensi antara node, berbagi data, lalu lintas yang tidak biasa muncul antara agen dan master, atau masalah dengan penskalaan pada master. Alat mana, dari sudut pandang Anda, yang lebih baik: alat yang menunjukkan satu-satunya cara yang benar untuk menyelesaikan masalah, seperti Jenkins X? Atau alat seperti Scripted Pipeline yang menanyakan apa sebenarnya yang ada dalam pikiran Anda?
Kosuke: Saya tidak yakin saya mengerti Anda dengan benar, tetapi saya akan mencoba menjawab. Di Jepang, ada kata "kata", saya tidak tahu bagaimana menerjemahkannya dengan akurat. Ini digunakan, antara lain, dalam judo. Kita berbicara tentang gerakan yang didefinisikan secara ketat yang dipelajari siswa: misalnya, mengangkat tangan dengan cara tertentu untuk menangkis pukulan tertentu. Saya melakukan sedikit ini, jadi saya tahu yang paling sederhana dari mereka. Tantangannya adalah menghafal seperangkat gerakan sederhana, semacam pola atau praktik terbaik. Tapi ini baru permulaan. Mengetahui basis ini, Anda dapat terus meninggalkannya dengan benar jika situasinya mengharuskannya, sambil tidak melanggar gerakan dasar itu sendiri. Anda mempelajari ruang Anda sendiri, wilayah Anda, tetapi pada saat yang sama, mengetahui pangkalan bersama membantu Anda. Jika Anda tidak mengenalnya, Anda akan selalu bertanya pada diri sendiri - apakah saya melakukan hal yang benar? Bahkan jika apa yang Anda tulis berhasil, Anda masih memiliki keraguan.
Secara umum, pertanyaan Anda mengingatkan saya pada kata. Saya pikir kami memiliki situasi yang sama dengan Jenkins. Jenkins X menyediakan basis, dan ketika Anda mulai memahaminya lebih dalam, Anda dapat meninggalkannya jika perlu dengan bantuan plugin dan hal-hal lain. Tentu saja, Jenkins X harus mengorbankan fleksibilitas untuk memberikan pengalaman yang lebih baik dengan Kubernetes. Tetapi fakta bahwa Jenkins X mendorong Anda ke arah praktik terbaik tidak berarti Anda kehilangan pilihan. Secara umum, ini benar dalam kaitannya dengan perangkat lunak apa pun. Hanya saja dengan Jenkins X kami memiliki perubahan penting dalam pola pikir. Sebelumnya, kami hanya menciptakan elemen-elemen kunci dari sistem - platform dan plugin, terserah kepada pengguna untuk merakitnya. Dengan Jenkins X, komunitas telah pindah ke pendekatan baru, dan menurut saya, ini adalah langkah yang sangat penting.
Kirill: Jika Anda tidak keberatan, saya akan memiliki dua pertanyaan lagi. Fitur mana yang membuat Anda paling kesulitan dalam setahun terakhir? Setiap proyek memiliki periode yang sulit - dapatkah Anda memberi tahu kami bagaimana mereka terlihat seperti Anda miliki?
Kosuke: Kami telah benar-benar menghancurkan hidup kami beberapa kali. Masalahnya adalah ketika Jenkins tumbuh, proyek kami mulai menarik lebih banyak perhatian dari perusahaan lain dan tim keamanan mereka yang mulai mencari celah di Jenkins. Oleh karena itu, jumlah laporan kerentanan yang datang kepada kami dari luar mulai tumbuh secara eksponensial. Kadang-kadang menjadi sedikit menakutkan dari ini, terutama ketika Anda mempertimbangkan bahwa beberapa permintaan ini datang dengan tenggat waktu, yang kami butuhkan untuk menutup kerentanan. Ini terutama sulit ketika datang ke fitur yang dibuat oleh komunitas. Selain itu, saat menginstal pembaruan dengan kerentanan tetap, pengguna terkadang terganggu. Kami bekerja keras untuk mencegah hal ini terjadi, karena jika tidak, pengguna akan takut untuk menginstal pembaruan keamanan, yang sangat tidak diinginkan.
Kirill: Apakah Anda memiliki badan pengelola yang memutuskan fitur mana yang akan disertakan dalam rilis? Beri tahu kami bagaimana keputusan tersebut dibuat dan bisakah pengguna meminta untuk menyertakan beberapa fitur dalam rilis? Jika mereka bisa, lalu siapa yang akan diberi prioritas - untuk pengguna CouldBees atau open source Jenkins? Akhirnya, jika mungkin, beri tahu kami tentang rencana Anda untuk enam bulan hingga satu tahun ke depan.
Koske: Ada poin menarik di sini: CloudBees tidak memiliki Jenkins, ini adalah dua proyek terpisah, masing-masing dengan struktur pengambilan keputusannya sendiri. CloudBees hanyalah kontributor terbesar Jenkins, dengan banyak CloudBees yang bekerja di komunitas. Selama beberapa tahun terakhir, kami telah berusaha membuat struktur kontrol yang lebih jelas di Jenkins yang melakukan persis seperti yang Anda minta. Untuk tujuan ini, kami menciptakan Proses Peningkatan Jenkins ...
Cyril: Maaf mengganggu - apakah disingkat JEP, sama seperti di Jawa?
Kosuke: Tentu saja. Jelas, kami tidak menciptakan konsep ini, tetapi meminjamnya dari Python, Jawa, dan beberapa komunitas lain, karena di sana ia telah memantapkan dirinya. Gagasan utama di sini adalah bahwa komunitas harus dapat mengekspresikan pendapat mereka dan mencapai konsensus sebelum pekerjaan besar pada fitur dimulai. Inilah yang kami lakukan ketika CloudBees akan membuat fitur baru, jadi kami memiliki kesempatan untuk mengubah kursus tergantung pada respons yang diterima. Ini adalah elemen perencanaan yang dapat kami implementasikan dalam pekerjaan kami. , , . , .
, , , , .. Jenkins X. CloudBees . , Configuration as Code . , , , . , JEP, .
: , , JEP :) Jenkins – Scripted Pipeline?
: . , . , Pipeline, , . , , Pipeline. Build Flow, CloudBees , . , «» — , , - .
: Scripted Pipeline?
: , .
: , DSL — . Scripted Pipeline ?
: , , .
: DSL . , DSL Java API . . , , . .
: , , . , Scripted Pipeline. Jenkins . . , , , . , — 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 ( , ).