Integrasi Berkelanjutan - Ikhtisar
Integrasi Berkelanjutan pertama kali diperkenalkan pada tahun 2000 dengan perangkat lunak yang dikenal sebagai Cruise Control. Selama bertahun-tahun, Integrasi Berkelanjutan telah menjadi praktik utama dalam organisasi perangkat lunak mana pun. Ini adalah praktik pengembangan yang meminta tim pengembangan untuk memastikan bahwa build dan pengujian selanjutnya dilakukan untuk setiap perubahan kode yang dibuat ke program perangkat lunak. Konsep ini dimaksudkan untuk menghilangkan masalah menemukan kemunculan yang terlambat dari masalah dalam siklus hidup build. Alih-alih pengembang bekerja dalam isolasi dan tidak cukup terintegrasi, Integrasi Berkelanjutan diperkenalkan untuk memastikan bahwa perubahan kode dan pembuatan tidak pernah dilakukan secara terpisah.
Mengapa Integrasi Berkelanjutan?
Integrasi berkelanjutan telah menjadi bagian yang sangat integral dari proses pengembangan perangkat lunak apa pun. Proses Integrasi berkelanjutan membantu menjawab pertanyaan-pertanyaan berikut untuk tim pengembangan perangkat lunak.
Apakah semua komponen perangkat lunak bekerja bersama sebagaimana mestinya? - Terkadang sistem bisa menjadi sangat kompleks sehingga ada beberapa antarmuka untuk setiap komponen. Dalam kasus seperti itu, selalu penting untuk memastikan bahwa semua komponen perangkat lunak bekerja dengan lancar satu sama lain.
Apakah kode terlalu rumit untuk tujuan integrasi? - Jika proses integrasi berkelanjutan terus gagal, ada kemungkinan kode tersebut terlalu rumit. Dan ini bisa menjadi sinyal untuk menerapkan pola desain yang tepat untuk membuat kode lebih kompleks dan lebih mudah dipelihara.
Apakah kode tersebut mematuhi standar pengkodean yang ditetapkan? - Sebagian besar kasus pengujian akan selalu memeriksa bahwa kode tersebut mematuhi standar pengkodean yang tepat. Dengan melakukan tes otomatis setelah pembuatan otomatis, ini adalah poin yang baik untuk memeriksa apakah kode tersebut memenuhi semua standar pengkodean yang diinginkan.
Berapa banyak kode yang dicakup oleh pengujian otomatis? - Tidak ada gunanya menguji kode jika kasus pengujian tidak mencakup fungsionalitas kode yang diperlukan. Jadi, selalu merupakan praktik yang baik untuk memastikan bahwa kasus uji tertulis harus mencakup semua skenario utama aplikasi.
Apakah semua pengujian berhasil setelah perubahan terbaru? - Jika tes gagal, maka tidak ada gunanya melanjutkan penerapan kode, jadi ini adalah poin yang baik untuk memeriksa apakah kode siap untuk dipindahkan ke tahap penerapan atau tidak.
Alur Kerja
Gambar berikut menunjukkan alur kerja cepat tentang cara kerja seluruh alur kerja Continuous Integration dalam proyek pengembangan perangkat lunak apa pun. Kami akan melihat ini secara rinci di bab-bab selanjutnya.
Jadi, berdasarkan alur kerja di atas, ini biasanya cara kerja proses integrasi berkelanjutan.
Pertama, pengembang memasukkan kode ke repositori kontrol versi. Sementara itu, server Integrasi Berkelanjutan pada mesin build integrasi memeriksa repositori kode sumber untuk perubahan (misalnya, setiap beberapa menit).
Segera setelah komit terjadi, server Integrasi Berkelanjutan mendeteksi bahwa perubahan telah terjadi di repositori kontrol versi, sehingga server Integrasi Berkelanjutan mengambil salinan kode terbaru dari repositori dan kemudian menjalankan skrip build, yang mengintegrasikan perangkat lunak
Server Integrasi Berkelanjutan menghasilkan umpan balik melalui email hasil build ke anggota proyek yang ditentukan.
Tes unit kemudian dilakukan jika pembangunan proyek itu berhasil. Jika pengujian berhasil, kode siap untuk diterapkan ke server penahapan atau produksi.
Server Integrasi Berkelanjutan terus mengumpulkan perubahan dalam repositori kontrol versi dan seluruh proses berulang.