Argumen terhadap pengecekan file biner ke SCM

Saya bekerja untuk perusahaan yang terutama membangun aplikasi Java dan saya mencoba meyakinkan semua orang untuk berhenti memeriksa file biner (dependensi dan produk akhir) ke SCM.

Mereka tahu itu adalah praktik yang buruk tetapi mereka berpikir bahwa "itu berhasil" dan itu tidak benar-benar masalah bahkan ketika banyak orang tahu tentang Maven dan alat-alat lain untuk membangun selain Semut. Baik PM dan programmer (sekitar 50 orang) siap mendengarkan argumen yang menentang dan bahkan mengakui bahwa itu adalah pemborosan ruang cadangan tetapi saya ingin benar-benar meyakinkan karena perubahan kebiasaan akan melibatkan banyak upaya. Argumen apa yang Anda gunakan untuk mendukung perubahan?

Sunting: Oke, masuk akal untuk membuat perbedaan antara file yang hampir tidak berubah, seperti dependensi, dan file yang dihasilkan. Meski begitu, saya tertarik pada alasan terhadap yang terakhir.

Ruang penyimpanan murah, dan itu bukan argumen yang sangat meyakinkan mengapa Anda harus atau tidak harus memeriksa file.

Sebagai gantinya, Anda dapat naik banding ke tujuan SCM. Setiap file yang dilacak oleh SCM mewakili beberapa kebutuhan untuk mengelola paralel, perubahan terdistribusi yang dilakukan tim Anda. Tidak ada yang benar-benar jelas sampai dua anggota tim mencoba mengubah file yang sama. Menyelesaikan perubahan-perubahan itu adalah untuk apa SCM sebenarnya, mencegah penimpaan yang tidak disengaja dari pekerjaan dev lain, dan mudah-mudahan, mengotomatiskan proses menggabungkan perubahan-perubahan itu.

Menggabungkan file biner biasanya merupakan tantangan nyata, karena tidak ada cara yang waras untuk alat penggabungan generik untuk menebak bagaimana seharusnya file biner yang digabung bekerja. Itu tidak bisa cukup tahu tentang bagaimana indeks atau offset pointer dalam file bekerja kecuali dirancang khusus untuk mengenali tipe file tertentu.

Itu berarti terserah pada dev untuk menggabungkan file biner dengan tangan, dan kemudian memberi tahu SCM bahwa file tersebut telah begitu digabung. Karena ini adalah pengembang yang melakukannya, penggabungan mungkin tidak benar-benar mencakup semua perubahan dari kedua check-in sebelumnya, dan karena file tersebut biner, tidak ada cara otomatis untuk memverifikasi penggabungan.

Untuk format biner yang benar-benar mewakili sumber proyek, seperti aset seni, ini merupakan langkah yang disayangkan, tetapi perlu. Namun, output build bukan sumber. Tidak perlu untuk menggabungkan mereka, karena sumber dapat digabungkan dan output build yang dihasilkan dapat dibuat ulang. Melacak dan mengelola perubahan ini adalah pemborosan 100%. Itu memboroskan sumber daya SCM, meskipun tidak terlalu banyak, tetapi juga membuang waktu pengembang untuk melewati kegagalan penggabungan palsu. Waktu pengembang sangat mahal, dan apa pun yang sia-sia adalah kanker.

Di sisi lain, ada kasus khusus di mana output build harus diarsipkan. Setiap versi dari proyek yang pernah dikirimkan atau disebarluaskan mungkin harus dipertahankan, tanpa batas waktu. Memiliki salinan byte yang tepat untuk byte dari bangunan aktual yang bermasalah dengan pelanggan dapat membuat mendukung pelanggan itu lebih mudah, karena Anda akan memiliki versi persis yang ia miliki.

Cadangan itu mungkin tidak boleh berada dalam repositori yang sama dengan kode sumber, karena mereka umumnya akan mengikuti jadwal yang berbeda dan pada dasarnya memiliki struktur yang berbeda.

Ketergantungan, bahkan dalam bentuk biner, harus diperiksa sehingga ketika orang lain menarik proyek, itu hanya berfungsi. Perhatian utama bukanlah jenis file, tetapi bagaimana file dibuat. Aturan praktis yang saya gunakan adalah bahwa jika dapat dihasilkan menggunakan file lain, itu tidak bisa diperiksa - ini berarti dokumentasi yang dihasilkan secara otomatis, file biner yang saya buat, dan sebagainya.

Salah satu keuntungan utama menggunakan SCM adalah Anda dapat merekonstruksi sistem Anda kapan saja di masa lalu. Jadi tidak ada gunanya menyimpan bangunan akhir Anda di SCM Anda karena Anda bisa memeriksa nomor revisi dan membangunnya.

Anda menyebutkan dependensi ... SCM Anda harus diatur sehingga Anda dapat melakukan checkout bersih ke mesin baru (dengan lingkungan dev), tekan build dan Anda harus dapat membangun sistem Anda tanpa perlu menginstal apa pun. Jadi menjaga dependensi biner di SCM Anda adalah ide yang bagus. Perpustakaan jarang berubah sehingga tidak membutuhkan banyak ruang.

Hampir tidak ada yang melakukan ini.

Tampaknya berlebihan untuk menyertakan file sumber dan objek (file sumber jelas diperlukan). Selain menjadi tidak perlu, file objek dapat mengambil banyak ruang. Jika perusahaan Anda menggunakan SCM terdistribusi (Git, Hg, Bzr) maka file-file biner tersebut harus disalin dan disimpan di antara semua pengembang.