Penafian . Kostis Kapelonis - Pengembang mengadvokasi Codefresh, platform CI / CD pertama untuk Kubernet dan wadah, untuk mempertahankan dan menegakkan prinsip-prinsip pengembangan perangkat lunak. Misi Codefresh "Mengotomatiskan dan menyederhanakan semuanya dari kode ke cloud." Sebagai seorang insinyur perangkat lunak, Kostis memiliki pengalaman bertahun-tahun dalam mengemas aplikasi, membangun jaringan pipa CI / CD, dan mengembangkan aplikasi Java. Dia tinggal di Yunani dan suka sepatu roda.
Seperti kata pepatah, "jika sesuatu menyebabkan rasa sakit, lakukanlah lebih sering." Integrasi berkelanjutan, pada dasarnya, merupakan pengulangan langkah integrasi dengan frekuensi tinggi untuk mengurangi "rasa sakit" yang ditimbulkannya. Artikel ini adalah tentang ini - tentang "rasa sakit" pembangunan dan bagaimana cara menguranginya.
Ada banyak informasi tentang integrasi berkelanjutan (CI) dan pengiriman berkelanjutan (CD). Posting blog menggunakan istilah teknis untuk menjelaskan apa arti metodologi CI / CD, apa yang mereka lakukan dan bagaimana mereka dapat membantu perusahaan Anda. Sayangnya, seringkali kedua metodologi ini dikaitkan dengan alat khusus atau bahkan penyedia perangkat lunak. Percakapan khas tentang topik ini di perusahaan adalah:
- Apakah Anda menggunakan integrasi berkelanjutan dalam tim Anda?
- Ya, tentu saja, kami menggunakan alat X!
Biarkan saya memberi tahu Anda sedikit rahasia. Integrasi dan pengiriman berkelanjutan adalah dua pendekatan untuk pengembangan kode yang sama sekali tidak terkait dengan alat atau vendor tertentu. Meskipun ada alat dan solusi yang dapat membantu Anda dalam kedua kasus (misalnya, Codefresh), pada kenyataannya sebuah perusahaan dapat berlatih CI / CD hanya menggunakan skrip bash dan Perl skrip baris tunggal. Ini tidak terlalu praktis, tetapi tentu saja sangat mungkin.
Oleh karena itu, alih-alih jatuh ke dalam perangkap umum untuk menjelaskan esensi CI / CD menggunakan alat dan istilah teknis, kami akan menjelaskan apa metodologi ini didasarkan pada faktor paling penting dalam proses pembangunan - orang!
Kisah Orang: Integrasi Perangkat Lunak Masa Sulit
Temui Alice, Bob, Charlie, David, dan Elizabeth - semuanya bekerja untuk SoftwareCo Inc. lebih dari membuat aplikasi SuperBigProject. Alice, Bob, dan Charlie adalah pengembang. David adalah seorang insinyur pengujian, dan Elizabeth adalah manajer proyek tim.
Cara tradisional untuk mengembangkan aplikasi adalah sebagai berikut: Alice, Bob, dan Charlie mengerjakan tiga fungsi berbeda di workstation mereka. Setiap pengembang menulis dan menguji kode secara individual. Mereka menggunakan cabang panjang fungsi yang ada selama beberapa minggu atau bahkan berbulan-bulan sebelum digabungkan menjadi produk akhir.
Pada titik tertentu, manajer proyek Elizabeth mengumpulkan seluruh tim dan berkata: "Teman-teman, kita sudah harus merilis rilis, jadi coba saja!"
Setelah itu, Alice, Bob dan Charlie mencoba mengintegrasikan ketiga fungsi mereka ke dalam satu cabang. Ini adalah waktu yang sangat menegangkan karena fitur-fitur ini belum pernah diuji bersama. Banyak kesalahan dan masalah muncul entah dari mana, karena asumsi yang salah atau masalah dengan lingkungan, karena, jika Anda ingat, sampai titik ini semua fungsi telah diuji pada stasiun kerja yang berbeda, diisolasi satu sama lain.
Segera setelah "demam integrasi" berakhir, hasil gabungan diteruskan ke David, yang akan melakukan pengujian manual dan otomatis tambahan. Periode ini juga membutuhkan banyak waktu, karena David yang dapat menyetujui atau memblokir rilis, tergantung pada berapa banyak kesalahan kritis yang ditemukan. Semua orang mengamati David dengan seksama saat dia melakukan bagiannya, karena pengujian itu dapat mengungkapkan masalah serius yang dapat menunda peluncuran produk.
Akhirnya, pengujian selesai, dan Elizabeth dengan gembira mengumumkan bahwa produk perangkat lunak siap untuk pengemasan dan pengiriman.
Jadi, bagaimana perasaan orang dalam cerita imajiner ini, tetapi sangat realistis?
- Pengembang Alice, Bob, dan Charlie tidak senang karena mereka selalu mencari tahu tentang masalah integrasi tepat sebelum rilis. Periode integrasi mirip dengan baku tembak di mana peluru tiba secara bersamaan dari semua sisi.
- Penguji David terus-menerus gelisah karena sifat "berkedut" dari karyanya - ada periode tenang ketika ia hanya menunggu sampai pengembang menyelesaikan pekerjaan pada fungsi, dan ada fase pengujian ketika ia hanya kewalahan dengan pekerjaan dan harus berurusan dengan skrip tes yang tidak terduga, untuk selain itu, saat ini, tim pengembangan benar-benar berdiri di belakangnya.
- Elizabeth, sebagai manajer proyek, juga tidak bahagia. Fase integrasi adalah tautan penting dalam proyek. Ini adalah periode yang sibuk, karena masalah yang tidak terduga mendorong rilis produk. Elizabeth memimpikan rilis perangkat lunak tanpa kejutan, tetapi dalam praktiknya hal ini tidak pernah terjadi. "Hit" dari tahap integrasi dalam timeline yang direncanakan proyek selalu merupakan permainan menebak.
Secara umum, semua anggota tim tidak bahagia. Omong-omong, jika perusahaan Anda masih mengembangkan perangkat lunak semacam itu, cobalah untuk memahami bahwa proses pengembangan ini merusak moral tim Anda.
Jadi, di sini satu-satunya masalah utama adalah fase integrasi, yang terjadi pada setiap rilis produk perangkat lunak. Ini adalah titik sakit dalam alur kerja yang tidak memungkinkan tim programmer untuk membebaskan diri dari situasi yang penuh tekanan terkait dengan pelepasan program.
Menambahkan Kontinuitas ke Integrasi
Sekarang kita telah melihat apa arti "integrasi", sangat mudah untuk memahami apa arti "integrasi berkelanjutan". Seperti kata pepatah, "jika sesuatu menyebabkan rasa sakit, lakukanlah lebih sering." Integrasi yang berkelanjutan, pada dasarnya, merupakan pengulangan dari langkah integrasi dengan frekuensi tinggi untuk mengurangi "rasa sakit" yang ditimbulkannya.
Cara yang paling jelas untuk membuat prosesnya tidak terlalu menyakitkan adalah dengan mengintegrasikan lebih sering setelah setiap penggabungan, daripada menunggu rilis resmi.
Ketika tim mempraktikkan integrasi berkelanjutan, maka:
- Semua objek digabung langsung ke cabang utama.
- Pengembang bekerja bersama, bukan secara terpisah. Semua fungsi dikembangkan dari jalur utama.
- Suatu fungsi dianggap dikembangkan jika arus utama beroperasi penuh dan bekerja pada mesin apa pun, dan tidak hanya pada stasiun kerja yang terpisah.
- Pengujian dilakukan secara otomatis baik pada level elemen individu atau objek kode, dan pada level garis utama.
Ini adalah inti dari integrasi yang berkelanjutan. Tentu saja, ada nuansa lain dari metodologi ini, ada seluruh buku tentang topik ini, tetapi yang utama adalah bahwa alih-alih satu periode integrasi yang penuh tekanan, ketika semuanya digabung dan diuji pada saat yang sama, integrasi terjadi sepanjang waktu secara terus menerus.
Integrasi berkelanjutan dalam proses pengembangan perangkat lunak lebih unggul daripada integrasi konvensional karena:
- Mengurangi jumlah kejutan yang muncul saat menggabungkan objek kode.
- Ini memecahkan masalah "program hanya bekerja pada mesin saya."
- Ini membagi periode pengujian menjadi beberapa periode, di mana setiap objek kode secara bertahap menyatu dengan garis utama, bukannya menggabungkan semua objek sekaligus.
Akibatnya, tim yang menggunakan CI tidak merasa seperti roller coaster ketika periode tenang pengembangan diselingi dengan rilis yang menegangkan. Selain itu, ia mendapat kesempatan untuk menilai dengan saksama seberapa dekat proyek ini dengan penyelesaian, alih-alih menebak tanggal rilis. Menggunakan CI adalah salah satu pilar pengembangan perangkat lunak modern. Saat ini metode ini didokumentasikan dengan sangat baik dan terkenal. Oleh karena itu, tidak ada pembenaran atas fakta bahwa perusahaan Anda masih tidak mempraktikkan CI dalam pengembangan proyek perangkat lunak.
Pengiriman Perangkat Lunak Hard Times
Sekarang kita telah melihat sejarah integrasi reguler dan cara kerja integrasi berkesinambungan, kita dapat membawa ini ke tingkat proses pengembangan selanjutnya - pengiriman berkelanjutan. Jika kita kembali ke cerita asli kita, kita akan melihat gambar yang mirip dengan proses integrasi normal:
Peluncuran produk pada dasarnya adalah acara yang mirip dengan Big Bang. Setelah perangkat lunak dianggap diuji, seseorang harus menyelesaikan proses meminimalkan dan menggunakan perangkat lunak dari wadah. Menyebarkan perangkat lunak pada produksi juga merupakan periode yang sangat sibuk dan secara tradisional mencakup banyak langkah manual dan prosedur tindak lanjut. Penyebaran sangat jarang, dan bahkan hari ini ada perusahaan yang melakukan prosedur ini tidak lebih dari sekali setiap enam bulan. Hanya dalam kasus-kasus ekstrem, penyebaran terjadi sekaligus - ketika menggunakan model pengembangan perangkat lunak (air terjun).
Pengiriman perangkat lunak hanya setelah mencapai tenggat waktu menciptakan masalah yang sama dengan integrasi reguler yang jarang:
- Lingkungan produksi biasanya berbeda dari lingkungan pengujian, yang memerlukan konfigurasi tambahan pada menit terakhir.
- Fungsi yang bekerja secara normal di lingkungan pengujian terputus di lingkungan kerja.
- Fungsi yang tidak siap pada saat rilis, tidak pernah diberikan kepada pelanggan sama sekali, atau perbaikan mereka mendorong rilis lebih jauh.
- Dalam hal ini, rilis menciptakan ketegangan antara pengembang yang ingin menambahkan fitur baru untuk memperluas fungsionalitas perangkat lunak, dan operator yang ingin stabilitas dan tidak ingin menggunakan terlalu banyak fungsi baru sekaligus.
Solusi untuk masalah ini adalah template yang sama seperti pada kasus integrasi. Jika kita dapat meringankan rasa sakit dari proses integrasi dengan membuatnya lebih sering, maka kita dapat melakukan hal yang sama dalam proses pengiriman perangkat lunak.
Tambahkan kontinuitas pengiriman
Pengiriman berkelanjutan adalah praktik pengemasan dalam wadah dan mempersiapkan perangkat lunak seolah-olah dikirim ke produksi, sesering mungkin. Dan metode pengiriman yang paling ekstrem adalah setelah penggabungan masing-masing.
Dengan cara ini, CD membawa CI selangkah lebih maju. Setelah menggabungkan setiap fungsi dengan cabang arus utama, aplikasi tidak hanya diperiksa kebenarannya, tetapi juga dipaket dan disebarkan ke lingkungan pengujian yang sangat cocok dengan lingkungan kerja. Semua ini terjadi dalam mode otomatis penuh - perhatikan tidak adanya sosok pria kecil yang menunjukkan prosedur manual.
Juga perhatikan bahwa setiap fitur baru adalah kandidat potensial untuk diluncurkan ke produksi. Dalam praktiknya, tidak semua kandidat dikirim untuk diproduksi. Bergantung pada organisasi proses, keputusan untuk menggunakan produksi kadang-kadang membutuhkan intervensi dari orang yang bertanggung jawab yang memutuskan apakah akan merilis rilis ke produksi atau tidak, tetapi tidak secara pribadi berpartisipasi dalam persiapan rilis. Pada titik ini, rilis sudah dikemas, diuji dan digunakan dalam lingkungan pengujian.
Pengiriman kontinu (CD) sedikit lebih rumit daripada integrasi berkelanjutan (CI). Alasannya adalah karena setiap kandidat rilis berpotensi mencapai produksi, siklus hidup penuh harus otomatis:
- Sidang harus dapat diulang dan ditentukan.
- Semua langkah harus otomatis, yang cukup sulit untuk dipraktikkan.
- Semua konfigurasi dan file terkait harus ada di sistem kontrol versi, dan bukan hanya di kode sumber.
- Setiap fitur / rilis harus diuji di lingkungan pengujian yang dibuat secara dinamis dan dihancurkan secara dinamis.
- Semua suite tes harus otomatis dan relatif cepat, yang juga bukan tugas yang mudah.
Meskipun "cloud" tentu saja dapat membantu memenuhi semua persyaratan ini, tim programmer, baik pengembang maupun operator, membutuhkan tingkat disiplin tertentu yang benar-benar memastikan proses pengiriman perangkat lunak berkelanjutan.
Setelah pengenalan rilis CD menjadi rutin, seolah-olah dilakukan dengan klik tombol. Setiap anggota tim, bukan hanya manajer proyek, dapat melihat kandidat rilis saat ini. Kandidat ini mungkin tidak memiliki beberapa fungsi yang disyaratkan atau mungkin tidak sepenuhnya memenuhi semua persyaratan, tetapi ini sama sekali tidak penting sampai mempengaruhi proses rilis itu sendiri.
Fakta penting adalah bahwa rilis sepenuhnya diuji, dikemas dan siap dikirim ke produksi jika perlu. Pada saat yang sama, setiap peserta proyek harus dapat memberikan lampu hijau dan segera merilis perangkat lunak untuk produksi.
Jika Anda menggunakan CD, siklus hidup perangkat lunak dapat direpresentasikan sebagai berikut:
Setiap kandidat rilis selalu dipersiapkan sebelumnya. Orang tersebut memutuskan apakah kandidat rilis juga akan dinominasikan untuk produksi. Kandidat pelepas yang tidak mencapai produksi terus disimpan sebagai artefak jika mereka perlu digunakan di masa depan.
Untuk informasi Anda, tentang pengiriman terus-menerus, serta tentang integrasi berkelanjutan, seluruh buku juga telah ditulis dari mana Anda dapat mengetahui rincian metodologi ini.
Bonus: Penempatan Berkelanjutan
Huruf “D” dalam CD dapat berarti penyebaran, bukan pengiriman pengiriman. Pendekatan untuk proses pengembangan ini didasarkan pada pengiriman terus menerus dan pada dasarnya menghilangkan intervensi manusia. Setiap kandidat untuk rilis, yang akan lulus semua tes dan pemeriksaan kualitas dan akan diakui siap, segera dikirim ke produksi.
Harus diakui, hanya sejumlah kecil perusahaan yang dapat beroperasi dengan cara ini. Promosi ke produksi tanpa keterlibatan manusia tidak boleh dianggap enteng, karena pada saat penulisan ini, banyak perusahaan bahkan tidak mempraktikkan pengiriman terus menerus, belum lagi penyebaran berkelanjutan.
Anda harus memahami bahwa setiap pendekatan selanjutnya pada proses pengembangan didasarkan pada implementasi dari pendekatan sebelumnya.
Sebelum melangkah maju, perusahaan Anda harus memastikan bahwa setiap fondasi proses benar-benar solid. Kami di Codefresh melihat banyak perusahaan yang berniat untuk beralih ke teknologi cloud, mencoba mengubah teknologi mereka yang dioptimalkan untuk digunakan di pusat data pada jaringan pipa CI / CD, tanpa menyadari bahwa beberapa teknologi ini sudah ketinggalan zaman hari ini. Mencoba untuk menggunakan penyebaran berkelanjutan tanpa sepenuhnya merangkul pengiriman berkelanjutan akan menemui kegagalan.
Gambar berikut menunjukkan tahap pengembangan dan implementasi perangkat lunak yang dilakukan oleh Alice, Bob, Charlie, David, dan Elizabeth meliputi CD dan CI.
Pastikan Anda mendekati setiap paradigma pengembangan perangkat lunak dalam urutan yang benar. Percayalah bahwa pengantar pengiriman terus-menerus adalah tujuan yang sangat realistis, untuk implementasi yang ada semua alat yang diperlukan.
Sedikit iklan :)
Terima kasih telah tinggal bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda,
cloud VPS untuk pengembang mulai dari $ 4,99 ,
diskon 30% untuk pengguna Habr pada analog unik dari server entry-level yang kami ciptakan untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2650 v4 (6 Core) 10GB DDR4 240GB SSD 1Gbps dari $ 20 atau bagaimana cara berbagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang
Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?