Mengapa Jenkins menjadi mesin pemacu

Aliran seperti pengembangan lincah, devops, dan integrasi berterusan menunjukkan keperluan perusahaan moden untuk membina perisian dengan cekap - dan, jika perlu, untuk menghidupkan sedikit.

Manuver terakhir adalah bagaimana CloudBees menjadi syarikat seperti sekarang. Setelah menjadi penyedia PaaS cloud awam yang bebas untuk pengkoder Java (dinilai sangat tinggi oleh Andrew Oliver dalam "PaaS yang manakah yang harus saya gunakan?"), CloudBees berputar tajam 18 bulan yang lalu untuk melancarkan semula sebagai penyedia utama Jenkins, tempat terbuka yang sangat popular alat sumber untuk menguruskan proses pengembangan perisian.

Menurut Ketua Pegawai Eksekutif Sasha Labourey, sebagai penyedia Java PaaS CloudBees telah "berkembang dengan baik", tetapi "banyak lelaki yang lebih besar dengan cek yang lebih besar" ragu-ragu untuk melakukan di pasar PaaS yang tidak stabil yang tidak mempunyai standardisasi. Pada masa yang sama, Jenkins berangkat seperti roket - dan Labourey melihat peluang besar, terutamanya kerana CloudBees sudah menawarkan Jenkins sebagai perkhidmatan dan telah menyewa Kohsuke Kawaguchi, pencipta Jenkins. Hidangan sampingan Jenkins menjadi hidangan utama.

The Jenkins juggernaut

Apa di sebalik populariti Jenkins? Ringkasnya, Jenkins telah menjadi standard sumber terbuka untuk menguruskan bahagian dev dari devops, dari pengurusan kod sumber hingga penghantaran kod hingga produksi. Menurut Labourey, "Masyarakat melihat Jenkins sebagai mesin orkestrasi dan automasi ... Saya rasa alasan mengapa Jenkins menjadi mesin de facto adalah kerana ia sangat mudah dipasang." Ekosistem lebih dari 1,100 pemalam telah muncul, yang membolehkan pelanggan untuk menambahkan pelbagai fungsi dan mengintegrasikan Jenkins dengan segala-galanya dari Active Directory hingga GitHub hingga OpenShift PaaS.

Jenkins adalah penyelesaian integrasi berterusan (CI) dan penyampaian berterusan (CD). Idea CI adalah menggabungkan kod dari pemaju individu ke dalam projek berkali-kali sehari dan menguji secara berterusan untuk mengelakkan masalah hiliran. CD mengambil langkah ini lebih jauh untuk memastikan bahawa semua kod gabungan selalu dalam keadaan siap pengeluaran. Jenkins membolehkan pembangun untuk mengotomatisasi proses ini sebanyak mungkin - hingga ke tahap penerapan. Labourey memberikan contoh:

Katakan syarikat menggunakan Chef atau Boneka untuk menggunakan AWS. Jenkins tidak akan menggantikannya. Jenkins akan memanggil Puppet untuk melakukannya - OK, berikut adalah bit, jadi mari kita panggil skrip Boneka ini dan lihat bagaimana ia berfungsi. Dan hasil pelaksanaan Puppet akan menjadi masalah bagi Jenkins kerana mungkin memutuskan untuk melepaskan penyebaran dan mengambil tindakan selanjutnya. Kami menyebutnya "saluran paip." Ini betul-betul siri langkah ini. Ini boleh menjadi lima langkah, atau mungkin 50 langkah.

Jenkins berfungsi sebagai mesin aliran kerja untuk menguruskan saluran paip CI / CD ini dari sumber hingga penghantaran, kata Labourey, tetapi sepanjang perjalanan banyak alat yang berbeza dapat dipanggil untuk melakukan fungsi yang berbeza.

Docker adalah salah satu alat itu, dan Docker bersama dengan Jenkins memberi kesan yang mendalam pada pasukan pembangunan. Semua orang tahu bahawa Docker menyederhanakan pembangunan dan membuat penyebaran jauh lebih mudah, tetapi Labourey memerhatikan bahawa ia juga membantu menjaga kejujuran pembangun: Mereka tidak lagi dapat menyalahkan beberapa kesalahan konfigurasi persekitaran pembangunan ketika bangunan terhempas dan terbakar. Pada mesin fizikal, persekitaran pengembangan secara beransur-ansur menjadi rosak, secara tidak sengaja menyebabkan binaan pecah. Tetapi semasa anda membuat pengekodan di atas gambar Docker yang murni, anda hanya perlu menyalahkan kod cacat anda sendiri apabila binaan tidak akan berjalan.

Bersama-sama Jenkins dan ekosistemnya yang bersepadu menyediakan infrastruktur perisian penyelarasan untuk pembangunan lincah dan secara lebih luas membentuk "inti inisiatif devops," kata Labourey.

Sampai di sana dari sini

Semua automasi dan kecekapan penggunaan ini terdengar hebat, tetapi bagaimana dengan organisasi yang hampir tidak memikirkan perkembangannya yang lincah? Labourey menawarkan nasihat untuk memasuki CI / CD:

Saya fikir cara terbaik untuk melakukannya adalah dengan memulakan kecil. Pilih projek. Jangan katakan, "Baiklah, sekarang kami adalah kedai penghantaran berterusan, semuanya berjalan seperti ini." Mulakan dengan pasukan yang bersedia, itu mungkin lebih fleksibel daripada pasukan lain, mungkin ahli pasukan yang lebih baru, kurang bertekad dengan cara yang ada untuk melakukan sesuatu. Pilih projek yang mudah. Jangan cuba menggunakannya sebagai cara untuk mengatakan jika itu berfungsi, semuanya akan berfungsi. Jangan cuba gagal; berusaha untuk berjaya. Pilih pasukan yang bersedia, pilih projek yang mudah, sampai di sana. Pasukan ini akan menjadi penjual terbaik anda kerana sekarang anda dapat menunjukkan bahawa ia berjaya. Mereka boleh bercakap tentang bagaimana pekerjaan mereka menjadi lebih baik kerana, terus terang, cara lama membosankan.

Sebahagian dari proses itu, kata Labourey, adalah "mengekstrak pengetahuan yang diam-diam berada di otak orang dan memasukkannya ke dalam perancangan sebagai logik." Itu tidak berlaku dalam semalam. Selalunya, organisasi pembangunan bermula dengan memalu CI dan berusaha menuju CD dari masa ke masa.

Organisasi pembangunan cenderung mempunyai keperluan yang sangat berbeza dan sangat spesifik. Oleh itu, CloudBees menawarkan versi SaaS generik berdasarkan langganan yang dikendalikan oleh CloudBees dan versi "SaaS peribadi", yang dapat digunakan oleh pelanggan di AWS atau Azure (atau secara tempatan di OpenStack) dan menyesuaikannya dengan isi hati mereka.

Sukar untuk menekankan pentingnya mengatur, mengautomatisasi, dan menyelaraskan proses pembangunan. CI / CD adalah pusat bagi devops, dan pelaksanaan devops yang berjaya pada gilirannya mempunyai implikasi yang melampaui IT untuk perniagaan itu sendiri. Memperbaiki perisian secara berterusan secara berterusan meningkatkan produk dan perkhidmatan. Tesla, sebagai contoh, mengalami kemunduran serius dengan salah satu modelnya terbakar - dan melancarkan peningkatan perisian menyelesaikan masalah dalam sekelip mata.

"Menarik jika anda mendapat kecekapan 10 peratus lebih banyak; jika anda membelanjakan $ 100 juta setahun untuk IT, sangat bagus - anda mempunyai $ 10 juta yang anda boleh belanjakan di tempat lain," kata Labourey. "Tetapi keuntungan sebenarnya adalah apabila perniagaan menyedari bahawa dengan memanfaatkan alat tersebut dan cara melakukan sesuatu, mereka dapat meningkatkan penjualan sebanyak 10 persen."