Apa itu Continous Integration (CI) dan apa manfaatnya? [Tutup]

Bisakah seseorang menjelaskan kepada saya konsep Continious Integration, bagaimana cara kerjanya dengan cara yang mudah dimengerti? Dan mengapa perusahaan harus mengadopsi CI dalam alur kerja pengiriman kode mereka? Saya seorang pengembang dan perusahaan saya (terutama tim pembangunan) menggunakan Team City. Sebagai seorang pengembang saya selalu checkout, memperbarui dan melakukan kode ke SVN tetapi tidak pernah benar-benar harus repot tentang TeamCity atau CI secara umum. Jadi saya ingin mengerti apa kegunaan CI? Apakah CI bagian dari metodologi Agile?

Integrasi berkelanjutan singkatnya berarti Anda menyimpan pekerjaan Anda, Anda mendorongnya ke sistem manajemen dokumen (SVN dalam kasus Anda), semua tes dijalankan secara otomatis (baik tes unit, integrasi, fungsional, dll.) Dan aplikasi dikompilasi dan disiapkan untuk pengiriman (mis. gambar ISO dibuat). Integrasi berkelanjutan tidak sama dengan Pengiriman Berkelanjutan. Pengiriman masih dilakukan di saat yang berbeda. CI memastikan produk dapat dikirimkan jika diperlukan, tidak lebih.

Setiap kali ada kesalahan, tim mendapat pemberitahuan. Biasanya pada saat itu semua pekerjaan dihentikan dan semua upaya terkonsentrasi untuk memastikan produk dalam cara yang stabil. Tidak ada dorongan dan komit terjadi pada repositori saat sistem tidak berwarna hijau.

CI memastikan bahwa produk selalu dalam keadaan stabil dan berpotensi dapat dikirimkan kapan saja. Harap dicatat bahwa stabil tidak berarti fitur lengkap. Mungkin juga ada fitur setengah diimplementasikan, tetapi sistem bisa stabil.

CI biasanya dikaitkan dengan metodologi Agile, namun saya pribadi tidak tahu persis riwayat CI.

Integrasi berkelanjutan berarti: mengintegrasikan kode ke dalam produk yang benar-benar berjalan dan dapat diuji setiap saat , bukan (seperti yang sebelumnya terjadi) sebagai aktivitas terpisah di akhir siklus pengembangan.

Ini membutuhkan proses pembuatan aplikasi sepenuhnya otomatis, dan test suite otomatis, dan server yang membangun status kode saat ini dan menjalankan test suite di atasnya. Ini harus terjadi setiap hari, atau bahkan setelah setiap kode masuk.

Keuntungannya adalah ada umpan balik langsung tentang perubahan kode yang menyebabkan kesalahan kompilasi (misalnya karena pengembang gagal memeriksa semua perubahan atau menggunakan beberapa komponen yang tidak ada dalam sistem build) atau kegagalan kasus uji. Ini membuat kesalahan seperti itu jauh lebih mudah untuk diperbaiki, karena Anda tahu perubahan mana yang menyebabkannya dan orang yang bertanggung jawab masih memiliki ingatan segar tentang apa yang mereka lakukan.

Tanpa CI, semua kesalahan ini muncul bersamaan pada saat yang sama selama tahap integrasi, yang membuatnya sangat sulit untuk diperbaiki.

Anda mungkin memiliki gaya tertentu dalam pengembangan: Anda checkout, kode, kompilasi, periksa, kutukan, ubah, kompilasi, sorak, komit. Anda hanya melakukan kode kerja, mungkin bahkan dengan cara yang kurang terperinci seperti pada akhir hari kerja Anda, atau ketika fitur selesai. Anda memverifikasi dependensi Anda setiap kali Anda mengimpor perpustakaan API.

Ketika Anda mulai mengkode bersama dengan orang lain dan ketika ada saling ketergantungan, masuk akal untuk mengadopsi integrasi berkelanjutan. Hanya karena Anda tidak dapat mengetahui dampak perubahan pada orang yang bergantung pada kode Anda, dan Anda tidak menerima sinyal setiap kali Anda perlu memperbarui impor Anda.

Jadi ketika salah satu dari Anda melakukan perubahan, kedua proyek harus dibangun dan diuji bersama, yaitu berjalan melawan API satu sama lain, dibangun dan diuji dengan perpustakaan baru, dll. Tes semacam itu, kode Anda dan milik orang lain, disebut tes integrasi.

Mengapa terus menerus Karena lebih mudah untuk mendelegasikan koordinasi integrasi ke sistem yang menguji bangunan bersih setiap kali ada perubahan dalam basis kode daripada mengatur semua itu untuk manusia. Sistem ini dapat menskala.

Ada dua aspek untuk integrasi berkelanjutan.

1. Strategi kontrol sumber pengembangan memastikan bahwa pengembang dapat terus mengintegrasikan pekerjaan mereka yang sedang berlangsung dengan kode stabil pengembang lainnya.
2. Bangunan otomatis dan pengujian kode sumber dipicu oleh komit ke kontrol sumber

Poin 1 sangat penting. Ini adalah langkah untuk membuat penggabungan yang benar-benar dilakukan pengembang untuk menjadi sering, dan sifatnya kecil yang membuat penggabungan tersebut jauh lebih mungkin untuk berhasil.

Poin 2 adalah alat dan kerangka kerja yang diperlukan untuk memungkinkan titik 1 terjadi dengan aman, dengan cepat mengidentifikasi gabungan yang gagal dengan melanggar kode yang ada.

Seberapa bermanfaatkah itu?

Luar biasa. Sebagai pengembang yang mengerjakan suatu proyek, ini memungkinkan Anda untuk menghabiskan sebagian besar waktu Anda berfokus pada apa yang Anda lakukan, dan tidak khawatir tentang pekerjaan bersamaan dari anggota tim lainnya. Ketika pekerjaan Anda saat ini selesai, Anda kemudian mempublikasikan perubahan Anda ke seluruh tim dan selama beberapa jam berikutnya mereka semua menggabungkan perubahan Anda ke dalam pekerjaan mereka saat ini.

Tanpa itu, pengembang melakukan penggabungan big bang. Biasanya mengambil beberapa hari kerja mereka, dan harus menggabungkannya dengan semua perubahan yang dilakukan oleh seluruh tim sekaligus. Ketika penggabungan menjadi sangat buruk, pengembang lain mungkin akan pindah ke pekerjaan lain, dan mulai melupakan detail yang bagus untuk membantu menghilangkan klik kekacauan gabungan. Lebih buruk lagi, tanpa pembangunan dan pengujian terus-menerus, selama kode dikompilasi, menggabungkan bug dapat muncul dalam kode dan tidak akan diambil sampai pengujian (atau pelanggan) menemukannya.

CI berguna, ketika Anda memiliki:

• Kompilasi kode
• Set tes yang sebenarnya
• Laporan, yang berdasarkan pada kode sumber Anda (cakupan kode, kekerasan standar kode, dll.)
• Rutin yang Anda lakukan secara berkala, setelah kode berhasil dikompilasi

Daftar dapat dilanjutkan ..