Pengalaman yang sulit dimenangkan telah mengajari saya bahwa hampir semuanya termasuk dalam kontrol sumber. (Komentar saya di sini diwarnai oleh satu setengah dekade yang dikembangkan untuk sistem telekomunikasi tertanam pada perangkat keras berpemilik, dan kadang-kadang sulit ditemukan, alat.)
Beberapa jawaban di sini mengatakan "jangan letakkan binari di kontrol sumber". Itu salah. Ketika Anda mengerjakan suatu produk dengan banyak kode pihak ketiga dan banyak perpustakaan biner dari vendor, Anda memeriksa di perpustakaan biner . Karena, jika tidak, maka pada titik tertentu Anda akan meningkatkan dan Anda akan mengalami masalah: build rusak karena mesin build tidak memiliki versi terbaru; seseorang memberi CD baru kepada orang baru untuk diinstal; wiki proyek memiliki instruksi basi mengenai versi apa yang akan diinstal; dll. Lebih buruk lagi, jika Anda harus bekerja sama dengan vendor untuk menyelesaikan masalah tertentu dan mereka mengirimi Anda lima set perpustakaan dalam seminggu, Anda harusdapat melacak kumpulan biner mana yang memperlihatkan perilaku mana. Sistem kontrol sumber adalah alat yang memecahkan masalah itu dengan tepat.
Beberapa jawaban di sini mengatakan "jangan letakkan toolchain di kontrol sumber". Saya tidak akan mengatakan itu salah, tetapi yang terbaik adalah menempatkan toolchain di kontrol sumber kecuali Anda memiliki sistem manajemen konfigurasi (CM) yang solid . Sekali lagi, pertimbangkan masalah peningkatan seperti yang disebutkan di atas. Lebih buruk lagi, saya bekerja pada sebuah proyek di mana ada empat rasa terpisah dari rantai alat melayang ketika saya dipekerjakan - semuanya digunakan secara aktif ! Salah satu hal pertama yang saya lakukan (setelah saya berhasil membangun untuk bekerja) adalah meletakkan toolchain di bawah kendali sumber. (Gagasan sistem CM yang solid adalah di luar harapan.)
Dan apa yang terjadi ketika proyek yang berbeda membutuhkan toolchain yang berbeda? Contoh kasus: Setelah beberapa tahun, salah satu proyek mendapat pembaruan dari vendor dan semua Makefiles rusak. Ternyata mereka mengandalkan versi GNU make yang lebih baru. Jadi kita semua ditingkatkan. Aduh, Makefiles proyek lain semua bangkrut. Pelajaran: komit kedua versi GNU make, dan jalankan versi yang disertakan dengan checkout proyek Anda.
Atau, jika Anda bekerja di tempat di mana segala sesuatu di luar kendali, Anda memiliki percakapan seperti, "Hei, orang baru mulai hari ini, di mana CD untuk kompiler?" "Entahlah, sejak Jack berhenti, dia adalah penjaga CD-nya." "Uhh, bukankah itu sebelum kita naik dari lantai 2?" "Mungkin mereka ada di dalam kotak atau apa." Dan karena alat tersebut berusia tiga tahun, tidak ada harapan untuk mendapatkan CD lama dari vendor.
Semua skrip build Anda termasuk dalam kontrol sumber. Segala sesuatu! Semua jalan ke variabel lingkungan. Mesin build Anda harus dapat menjalankan build dari salah satu proyek Anda dengan mengeksekusi satu skrip di root proyek. ( ./build
adalah standar yang masuk akal; ./configure; make
hampir sama baiknya.) Script harus mengatur lingkungan seperti yang diperlukan dan kemudian meluncurkan alat apa pun yang membangun produk (make, semut, dll).
Jika Anda pikir itu terlalu banyak pekerjaan, itu tidak. Ini sebenarnya menghemat banyak pekerjaan. Anda mengkomit file sekali pada awal waktu, dan kemudian setiap kali Anda memutakhirkan. Tidak ada serigala pun yang dapat meng-upgrade mesinnya sendiri dan melakukan banyak kode sumber yang tergantung pada versi terbaru dari beberapa alat, menghancurkan build untuk semua orang. Saat Anda mempekerjakan pengembang baru, Anda dapat memberi tahu mereka untuk memeriksa proyek dan menjalankannya ./build
. Ketika versi 1.8 memiliki banyak penyempurnaan kinerja, dan Anda men-tweak kode, flag kompiler, dan variabel lingkungan, Anda ingin memastikan bahwa flag kompiler baru tidak secara tidak sengaja diterapkan ke versi 1.7 patch build, karena mereka benar - benar membutuhkan kode perubahan yang menyertainya atau Anda melihat beberapa kondisi ras berbulu.
Yang terbaik dari semuanya , ini akan menghemat waktu Anda: bayangkan Anda mengirimkan versi 3.0.2 produk Anda pada hari Senin. Hore, rayakan. Pada hari Selasa pagi, seorang pelanggan VIP menelepon hotline dukungan, mengeluhkan bug superkritis dan mendesak ini dalam versi 2.2.6 yang Anda kirim 18 bulan lalu. Dan Anda masih secara kontraktual harus mendukungnya, dan mereka menolak untuk memutakhirkan sampai Anda dapat memastikan dengan pasti bahwa bug telah diperbaiki dalam kode baru, dan mereka cukup besar untuk membuat Anda menari. Ada dua alam semesta paralel:
Di alam semesta di mana Anda tidak memiliki perpustakaan, toolchain, dan membuat skrip dalam kontrol sumber, dan Anda tidak memiliki sistem CM yang kuat .... Anda dapat memeriksa versi kode yang tepat, tetapi memberikan Anda semua jenis kesalahan ketika Anda mencoba membangun. Mari kita lihat, apakah kita meningkatkan alat pada bulan Mei? Tidak, itu perpustakaannya. Ok, kembali ke perpustakaan lama - tunggu, apakah ada dua upgrade? Ah ya, itu terlihat sedikit lebih baik. Tapi sekarang crash linker aneh ini terlihat familier. Oh, itu karena pustaka lama tidak bekerja dengan toolchain baru, itu sebabnya kami harus memutakhirkan, kan? (Saya akan menghindarkan Anda dari penderitaan selama sisa upaya. Butuh dua minggu dan tidak ada yang senang pada akhirnya, bukan Anda, bukan manajemen, bukan pelanggan.)
Di alam semesta di mana semuanya berada dalam kontrol sumber, Anda memeriksa tag 2.2.6, memiliki debug build siap dalam satu jam atau lebih, menghabiskan satu atau dua hari menciptakan "bug VIP", melacak penyebabnya, memperbaikinya di rilis saat ini, dan meyakinkan pelanggan untuk memutakhirkan. Stres, tetapi tidak seburuk yang ada di alam semesta lain di mana garis rambut Anda 3cm lebih tinggi.
Dengan itu, Anda bisa melangkah terlalu jauh:
- Anda harus memiliki instalasi OS standar yang memiliki "salinan emas". Dokumentasikan, mungkin dalam README yang ada dalam kontrol sumber, sehingga generasi mendatang tahu bahwa versi 2.2.6 dan sebelumnya hanya dibangun di atas RHEL 5.3 dan 2.3.0 dan kemudian hanya dibangun di Ubuntu 11.04. Jika lebih mudah bagi Anda untuk mengelola rantai alat dengan cara ini, lakukan saja, pastikan itu adalah sistem yang andal.
- Dokumentasi proyek rumit untuk dipelihara dalam sistem kontrol sumber. Dokumen proyek selalu berada di depan kode itu sendiri, dan itu tidak biasa untuk mengerjakan dokumentasi untuk versi berikutnya sambil mengerjakan kode untuk versi saat ini. Terutama jika semua dokumen proyek Anda adalah dokumen biner yang tidak dapat Anda gabungkan atau gabungkan.
- Jika Anda memiliki sistem yang mengontrol versi semua yang digunakan dalam build, gunakan itu ! Pastikan mudah untuk menyinkronkan seluruh tim, sehingga semua orang (termasuk mesin pembuat) menarik dari seperangkat alat yang sama. (Saya sedang memikirkan sistem seperti pbuilder Debian dan penggunaan virtualenv python yang bertanggung jawab.)