Dari pengalaman masa lalu dengan basis kode Big Ball Of Mud yang berevolusi secara alami selama bertahun-tahun di tangan banyak pengembang junior yang tidak diawasi, saya ingin menunjukkan apa yang terjadi ketika Anda tidak berlatih CI dengan pengembang tersebut.
Edit / Perbarui : Sesuai komentar RubberDuck; jawaban ini mengasumsikan bahwa target gabungan Anda untuk integrasi adalah cabang pengembangan daripada cabang evaluasi atau rilis.
- Jelas perlu ada lebih banyak kontrol atas kode untuk rilis dan penyebaran langsung; jika tidak ada cabang produksi yang terpisah maka akan lebih baik mempertimbangkan perubahan pada strategi percabangan / penggabungan untuk menjalankan cabang pengembangan master (yang digunakan untuk pengujian integrasi dan tidak pernah untuk rilis) di samping cabang rilis master. Ini menjaga semua manfaat CI dan penggabungan yang sering tanpa risiko melanggar kode produksi.
1. Pengembang junior cenderung berkomunikasi dengan rekan kerja atau penyelia mereka
Integrasi berkelanjutan bukan hanya masalah penggabungan kode, ini adalah titik waktu di mana pengembang dipaksa untuk berinteraksi dengan pemangku kepentingan lainnya.
Komunikasi itu penting, dan tanpa ingin menggeneralisasi secara berlebihan, itu cenderung merupakan keterampilan yang dipelajari yang datang kurang alami bagi pengembang yang tidak berpengalaman dibandingkan dengan mereka yang terbiasa bekerja di lingkungan tim.
Jika Anda mengizinkan pengembang junior untuk duduk di bilik mereka dan mem-bash kode selama berminggu-minggu tanpa diminta untuk sering melaporkan / ulasan, maka mereka cenderung menghindari komunikasi sama sekali.
2. Kode yang mereka hasilkan kemungkinan membutuhkan peninjauan yang lebih ketat
Pernahkah Anda meninjau sesuatu yang begitu buruk sehingga Anda berharap dapat mengambilnya lebih awal dan mencegahnya agar tidak pernah ditulis? Ini sering terjadi.
Anda tidak dapat mencegah kode buruk ditulis, tetapi Anda dapat membatasi waktu yang terbuang. Jika Anda berkomitmen untuk sering meninjau dan menggabungkan, maka Anda meminimalkan ruang untuk waktu yang terbuang.
Skenario terburuk adalah bahwa Anda dapat meninggalkan pengembang junior sendirian selama beberapa minggu di proyek miniatur mereka sendiri, dan ketika mereka akhirnya siap untuk meninjau kode, tidak ada cukup waktu tersisa bagi mereka untuk membuang seluruh kekacauan pergi dan mulai lagi dari awal.
Banyak proyek menjadi bola lumpur besar hanya karena seluruh kode buruk ditulis ketika tidak ada yang memperhatikan sampai semuanya terlambat.
3. Anda harus kurang yakin bahwa pengembang junior atau anggota tim baru lainnya telah memahami persyaratan
Terkadang pengembang mungkin membangun solusi sempurna untuk masalah yang salah; ini menyedihkan karena biasanya kesalahpahaman sederhana yang akan sangat mudah untuk dihindari jika hanya seseorang yang mengajukan pertanyaan yang tepat sebelumnya dalam proses.
Sekali lagi, ini adalah masalah yang lebih cenderung mempengaruhi pengembang yang tidak berpengalaman yang lebih cenderung menerima persyaratan "buruk" pada nilai nominal daripada mendorong kembali dan mempertanyakan kebijaksanaan persyaratan.
4. Mereka cenderung kurang akrab dengan pola umum, dengan arsitektur kode yang ada, dan dengan alat dan solusi yang terkenal
Kadang-kadang pengembang menghabiskan seluruh waktu untuk menciptakan kembali roda secara tidak perlu hanya karena mereka tidak tahu bahwa ada solusi yang lebih baik. Atau mereka mungkin menghabiskan waktu berhari-hari untuk mencoba mematok pasak persegi ke dalam lubang bundar tanpa menyadari apa yang mereka lakukan salah.
Sekali lagi, hal semacam ini lebih mungkin terjadi pada pengembang yang tidak berpengalaman, dan cara terbaik untuk mengatasi masalah ini adalah dengan memastikan ulasan rutin.
5. Periode yang lama antara komit / penggabungan kode membuat cacat lebih sulit untuk diidentifikasi dan diperbaiki
Ketika bug muncul segera setelah berminggu-minggu perubahan kode telah digabungkan ke cabang master, tantangan untuk mengidentifikasi perubahan yang mungkin menyebabkan bug menjadi lebih sulit.
Jelas strategi bercabang keseluruhan Anda juga ikut berperan di sini; idealnya semua pengembang Anda akan bekerja di cabang mereka sendiri, atau di dalam cabang fitur (atau keduanya), dan tidak akan pernah bekerja langsung dari master / trunk.
Saya telah melihat situasi di mana seluruh tim semuanya bekerja langsung ke master / trunk pada saat yang sama, dan ini adalah lingkungan yang mengerikan bagi CI, tetapi untungnya solusi menarik semua orang menjauh dari master / trunk umumnya memberikan stabilitas yang cukup untuk pekerjaan individu barang / tiket / dll.
Seharusnya selalu "OK" bagi pengembang mana pun untuk mematahkan cabang master / trunk, dengan pemahaman bahwa penggabungan harus terjadi secara teratur, bahwa pemecahan perubahan dan cacat harus diidentifikasi lebih cepat, dan karenanya diselesaikan lebih cepat juga. Cacat terburuk biasanya adalah mereka yang tetap tidak terdeteksi selama berbulan-bulan atau bahkan bertahun-tahun.
Kesimpulan; keuntungan utama dari integrasi berkelanjutan / penerapan berkelanjutan adalah:
- Komunikasi di antara tim Anda meningkat
- Kualitas kode umumnya dipertahankan pada standar yang lebih tinggi
- Persyaratan cenderung dilewatkan atau disalahartikan
- Masalah arsitektur dan desain harus dideteksi lebih cepat,
- Cacat lebih mungkin terdeteksi dan diperbaiki pada tahap sebelumnya
Jadi jika Anda tidak berlatih CI dengan pengembang junior Anda, maka Anda menerima banyak risiko yang tidak perlu, karena ini adalah anggota tim Anda yang membutuhkannya lebih dari yang lain.
it is more scary to wait a week to deploy all micro services at once to make sure that everything works together, than to strictly enforce api versioning, write lots of automatic tests (...), and auto deploy to production as soon as your commit passes as tests on stage- itu berdasarkan pendapat;) IMHO jauh lebih sulit untuk memastikan kesuksesan dengan penyebaran layanan independen daripada dengan pendekatan monolitik: softwareengineering.stackexchange.com/a/342346/187812 . Dan dengan CI sejati (tanpa cabang fitur / integrasi) Anda tidak perlu menunggu selama seminggu.