Bagaimana Anda mendefinisikan Integrasi Berkelanjutan dan komponen spesifik apa yang terkandung dalam server CI?
Saya ingin menjelaskan kepada seseorang di departemen pemasaran apa itu Continuous Integration. Mereka memahami kontrol Sumber - yaitu mereka menggunakan Subversion. Tapi saya ingin menjelaskan kepada mereka apa itu CI. The Wikipedia Pasal tidak pernah benar mendefinisikan hal itu, artikel Martin Fowler hanya memberikan berikut, yang pada dasarnya merupakan tautologi diikuti dengan penjelasan samar 'integrasi':
Continuous Integration adalah praktik pengembangan perangkat lunak di mana anggota tim sering mengintegrasikan pekerjaan mereka, biasanya setiap orang mengintegrasikan setidaknya setiap hari - yang mengarah ke beberapa integrasi per hari. Setiap integrasi diverifikasi oleh build otomatis (termasuk pengujian) untuk mendeteksi kesalahan integrasi secepat mungkin.
Pembaruan : Saya mengirimi mereka gambar ini, saya tidak dapat menemukan yang lebih sederhana.
Pembaruan 2 : Umpan balik dari bab pemasaran (untuk saat ada 3 pertanyaan):
Saya sebenarnya suka semua 3 jawaban - untuk alasan yang berbeda. Saya merasa ingin masuk hanya untuk berterima kasih kepada mereka semua!
Jelas dia tidak bisa - jadi terima kasih atas namanya :)
Pembaruan 3 : Saya menyadari melihat artikel Wikipedia yang memuat prinsip - prinsip yang, ketika Anda hanya mengambil judul, adalah daftar yang cukup bagus:
- Menyimpan repositori kode
- Otomatis pembuatan
- Buat pengujian mandiri build
- Setiap orang berkomitmen pada garis dasar setiap hari
- Setiap komit (ke baseline) harus dibangun
- Pertahankan build dengan cepat
- Uji di klon lingkungan produksi
- Permudah untuk mendapatkan kiriman terbaru
- Semua orang dapat melihat hasil build terbaru
- Penerapan otomatis
sumber
Jawaban:
Ketika seseorang mengubah file yang membentuk produk perangkat lunak dan kemudian mencoba untuk memeriksanya (dengan kata lain, upaya untuk mengintegrasikan perubahan ke dalam kode produk utama) Anda ingin memastikan bahwa produk perangkat lunak masih dapat berhasil dibuat.
Biasanya ada sistem eksternal, yang disebut server CI , yang baik secara berkala atau pada setiap perubahan, akan mengambil file sumber dari kontrol versi, dan berusaha untuk membangun produk (kompilasi / uji / paket). Jika server CI berhasil melakukan pembangunan, perubahan telah berhasil diintegrasikan.
Server CI juga harus dapat menyiarkan jika build gagal atau berhasil, sehingga sistem seperti Jenkins (salah satu server CI yang paling banyak digunakan saat ini) akan memiliki cara untuk mengirim email / teks serta antarmuka web seperti dashboard dengan sekelompok informasi tentang bangunan saat ini dan yang lalu, yang kode check-in, ketika semuanya rusak, dll. (Pada gambar Anda di atas, ini akan menjadi Mekanisme Umpan Balik .)
CI penting, karena memastikan bahwa secara berkelanjutan, Anda memiliki produk yang berfungsi. Ini penting untuk semua pengembang yang bekerja pada produk perangkat lunak serta untuk semua orang yang ingin memiliki akses ke rilis harian produk perangkat lunak, seperti QA.
sumber
Saya kira untuk departemen pemasaran Anda tidak penting bagaimana CI bekerja , tetapi apa artinya CI untuk rilis baru perangkat lunak Anda .
Idealnya CI akan berarti bahwa Anda dapat menghasilkan versi perangkat lunak Anda yang berpotensi dapat dirilis setiap hari, siap untuk disajikan atau dijual kepada pelanggan Anda, dengan beberapa fitur baru, fungsi atau perbaikan bug ditambahkan. Itu tidak berarti Anda harus memberikan versi baru setiap hari, tetapi Anda bisa jika mau.
Misalnya, jika Anda memiliki set fitur baru yang rencananya akan dirilis secara resmi untuk versi "2015" dari perangkat lunak Anda, dan Anda memiliki bagian-bagian dari set fitur yang sudah dikodekan dan diintegrasikan hari ini, petugas pemasaran dapat mengambil versi terbaru dari perangkat Anda. perangkat lunak dan menunjukkannya - kurang lebih aman - pada konferensi berikutnya sekarang pada tahun 2013. Tanpa CI, mereka harus meminta tim Anda untuk membekukan kode yang tidak direncanakan, setiap anggota tim harus mengintegrasikan fitur setengah matang yang sedang ia kerjakan ke dalam produk, mereka mungkin tidak memiliki tes otomatis yang cukup siap, dan coba tebak apa yang akan terjadi di konferensi - "versi alfa" dari rilis 2015er Anda akan memiliki risiko jauh lebih tinggi dari crash, terutama ketika fitur baru diperagakan.
sumber
Anda tidak bisa tahu apa itu CI kecuali Anda tahu apa yang dulu kami lakukan. Bayangkan sebuah sistem dengan 3 bagian. Ada UI yang mengumpulkan data dan memasukkannya ke dalam basis data. Ada sistem pelaporan yang membuat laporan dari database. Dan ada semacam server yang memonitor database dan mengirimkan peringatan email jika kriteria tertentu dipenuhi.
Dulu ini akan ditulis sebagai berikut:
Selama waktu ini para devs tidak akan menjalankan kode masing-masing, atau mencoba menggunakan versi database yang telah dibuat oleh kode orang lain. Penulis laporan hanya akan menambahkan sekumpulan data sampel. Penulis lansiran akan secara manual menambahkan catatan yang mensimulasikan acara laporan. Dan penulis GUI akan melihat database untuk melihat apa yang telah ditambahkan GUI. Seiring waktu, para pengembang akan menyadari bahwa spesifikasi itu salah dalam beberapa hal, seperti tidak menentukan indeks atau memiliki panjang bidang yang terlalu pendek, dan "memperbaikinya" dalam versi mereka. Mereka mungkin memberi tahu yang lain, yang mungkin menindaklanjutinya, tetapi biasanya hal-hal ini masuk daftar nanti.
Ketika ketiga bagian sepenuhnya dikodekan, dan diuji oleh devs mereka, dan kadang-kadang bahkan diuji oleh pengguna (menunjukkan kepada mereka laporan, layar atau peringatan email) maka akan datang fase "integrasi". Ini sering dianggarkan pada beberapa bulan tetapi masih akan berakhir. Itu perubahan panjang bidang oleh dev 1 akan ditemukan di sini, dan akan membutuhkan devs 2 dan 3 untuk membuat perubahan kode besar dan mungkin perubahan UI juga. Indeks tambahan itu akan mendatangkan malapetaka sendiri. Dan seterusnya. Jika salah satu devs diberi tahu oleh pengguna untuk menambahkan sebuah field, dan memang demikian, sekaranglah saatnya kedua lainnya harus menambahkannya juga.
Fase ini sangat menyakitkan dan sangat sulit untuk diprediksi. Maka orang-orang mulai berkata, "Kita harus lebih sering berintegrasi." "Kita harus bekerja sama sejak awal." "Ketika salah satu dari kami mengajukan permintaan perubahan [itulah cara kami berbicara kemudian] yang lain harus mengetahuinya." Beberapa tim mulai melakukan tes integrasi sebelumnya sambil terus bekerja secara terpisah. Dan beberapa tim mulai menggunakan kode dan output masing-masing setiap saat, sejak awal. Dan itu menjadi Integrasi Berkelanjutan.
Anda mungkin berpikir saya melebih-lebihkan cerita pertama itu. Saya pernah melakukan beberapa pekerjaan untuk sebuah perusahaan di mana kontak saya membuat saya keluar untuk memeriksa beberapa kode yang menderita dari kekurangan berikut:
Pendapatnya bahwa Anda tidak memasukkan hal-hal ke dalam kontrol sumber sampai selesai. Dia biasanya melakukan satu atau dua checkin setahun. Kami memiliki sedikit perbedaan filosofi :-)
Juga, jika Anda merasa sulit untuk percaya tim akan terputus di sekitar sumber daya bersama seperti database, Anda benar-benar tidak akan percaya (tapi itu benar) bahwa pendekatan yang sama diambil untuk kode. Anda akan menulis fungsi yang bisa saya panggil? Itu hebat, silakan dan lakukan itu, saya hanya akan hardcode apa yang saya butuhkan sementara itu. Berbulan-bulan kemudian saya akan "mengintegrasikan" kode saya sehingga memanggil API Anda dan kami akan menemukan itu meledak jika saya lulus nol, saya meledak jika mengembalikan nol (dan itu banyak) ia mengembalikan hal-hal yang terlalu besar bagi saya, itu tidak dapat menangani tahun kabisat, dan ribuan hal lainnya. Bekerja secara mandiri dan kemudian memiliki fase integrasi adalah normal. Sekarang kedengarannya seperti kegilaan.
sumber