Bagaimana Anda menyimpan binari yang dirilis di bawah kontrol versi?

14

Bagaimana Anda menyimpan binari yang dirilis di bawah kontrol versi? Ini memungkinkan untuk melacak barang mana yang diubah di antara setiap rilis. Maksud saya untuk memisahkan binari yang dirilis dari repositori sumber. Binari yang dirilis dibuat dari perangkat lunak Continuous Integration atau dikompilasi secara manual.

version-control release-management

— linquize
sumber

Apa yang Anda maksud dengan "melacak hal-hal yang telah berubah"? Atribut biner rilis apa yang Anda (atau inginkan) lacak? Sepertinya aneh, jadi saya penasaran.

— Jeremy Heiler

misalnya antara v1.0.0 dan v1.0.1, hanya ABC.exe yang diubah, sedangkan dependensi DEF.dll tetap tidak berubah

— linquize

1

Bagaimana Anda menentukan ini dengan melihat binari?

— Jeremy Heiler

versi lama dan baru berbeda dari file yang sama

— linquize

21

Dua pilihan:

a) Jangan. Pastikan Anda memiliki build deterministic yang dapat direproduksi, yaitu, membangun revisi kontrol sumber yang sama dengan konfigurasi yang sama selalu menghasilkan biner yang sama persis.

b) Tentukan direktori di suatu tempat sebagai sumber otoritatif untuk build yang diterbitkan. Jadikan mengunggah binari sebagai bagian dari prosedur penyebaran / pengiriman, dan pastikan direktori terbitan tercakup oleh paket cadangan Anda. Anda tidak memerlukan kontrol versi apa pun di sini; build adalah write-once, jika Anda perlu mengubah apa pun, Anda membuat build baru.

Either way, biner dan output build lainnya tidak termasuk dalam kendali sumber, karena berbagai alasan.

— tammmer
sumber

7

a) sering tidak mungkin tentu saja blogs.msdn.com/b/ericlippert/archive/2012/05/31/…

— jk.

@ jk: tautan bagus. Saya kira memiliki kode sumber dan semua file input untuk tahap pembuatan sepenuhnya di bawah kendali sumber (dan menginstal versi kompiler yang tepat) mungkin "cukup deterministik" dalam banyak skenario dunia nyata (dan tidak cukup pada yang lain, tentu saja ). Tergantung pada kasus, betapa pentingnya memiliki binari yang dapat direproduksi sedikit demi sedikit.

— Doc Brown

10

Gunakan repositori artefak untuk binari, bukan sistem kontrol versi. Versi spesifik dari biner yang dirilis tidak seharusnya berubah seiring waktu, oleh karena itu kontrol versi tidak masuk akal karena file tidak akan berubah.

Lihat misalnya repositori Maven sebagai repositori untuk mengarsipkan / menerbitkan / menawarkan rilis dan binari lainnya (mis. Seperti dokumentasi)

— mhaller
sumber

versi spesifik dari file sumber yang dirilis juga tidak boleh berubah seiring waktu. SCM adalah tempat yang baik untuk meletakkan binary yang dikirimkan, Anda hanya menyimpannya di samping file sumber yang digunakan untuk membangunnya.

— gbjbaanb

2

gbjbaanb, SCM singkatan dari "Manajemen Kontrol Sumber". Itu seharusnya memberi petunjuk kepada siapa pun bahwa sistem ini tidak dirancang untuk menyimpan binari tetapi sumber. Jika Anda masih ingin menyimpan binari, silakan. Saya tidak akan.

— mhaller

4

SCM singkatan dari "Manajemen Kontrol Perangkat Lunak" tetapi usaha yang bagus. "kode sumber" seringkali bukan hanya file teks, tetapi gambar, dokumen, diagram dll.

— gbjbaanb

Biasanya, "Manajemen Konfigurasi Perangkat Lunak." Saya belum pernah mendengar "Manajemen Kontrol Perangkat Lunak."

— James McLeod

7

Masukkan saja. Tidak ada masalah dengan itu, kecuali jika Anda menggunakan git (yang tidak menggabungkan biner dengan baik, jadi Anda harus mengelolanya sendiri) atau Anda melakukannya berkali-kali (hanya komit saat itu siap dikirim, tidak setiap kali Anda membangunnya).

Kebanyakan binari delta SCM cukup baik, kami biasa menempatkan sumber daya dll 2Mb ke dalam SVN kami dan itu akan delta ke beberapa kb setiap kali.

Saya mendengar banyak argumen bahwa SCM adalah untuk sumber, bukan binari tetapi ini jelas salah ketika Anda menganggap sebagian besar perangkat lunak terdiri dari gambar, bahkan jika mereka hanya ikon file. Mereka biner, tetapi mereka adalah bagian dari sumber, jadi masukkan dan jangan terlalu dogmatis tentang hal itu. Saya juga mendengar bahwa Anda hanya dapat membangun kembali biner saat dibutuhkan, sering kali ini yang terjadi, tetapi ini dapat menjadi upaya yang sangat membuang waktu untuk sistem lama yang tidak lagi didukung secara aktif. Jika Anda harus membuat ulang sistem dengan hanya paket atau tambalan layanan yang lebih lama untuk menyesuaikan dengan sistem yang digunakan untuk membangun biner 3 tahun yang lalu, Anda akan senang Anda menambahkan nampan ke SCM Anda saat itu.

Satu-satunya waktu Anda perlu khawatir tentang menambahkan build ke SCM Anda adalah jika Anda melakukannya secara otomatis sebagai bagian dari proses build server - jangan lakukan ini. Anda akan mengisi SCM Anda dengan bangunan yang tidak bermanfaat bagi Anda. Alih-alih hanya menambahkannya saat dirilis. Dengan cara ini Anda tahu persis apa yang dimiliki pelanggan Anda dan Anda dapat mereproduksi masalah yang dilaporkan pelanggan dengan binari yang mereka gunakan, dan bukan yang telah Anda bangun kembali (menggunakan, katakanlah, pembaruan terbaru untuk kompiler atau OS).

— gbjbaanb
sumber

1

@ MarnenLaibow-Koser, Anda jelas sudah lama tidak bekerja di industri ini. Lingkungan build berubah seiring waktu, jadi sementara Anda bisa membangun kembali yang lama, kemungkinan Anda harus menghabiskan waktu berhari-hari untuk menciptakan kembali env dengan alat dan SDK yang tepat. Yang saya harap Anda sudah berversi ....

— gbjbaanb

1

Saya membayangkan Anda akan dapat membangun biner VC6 lama yang dikompilasi pada mesin XP menggunakan SDK lama yang Microsoft tidak lagi melihat cocok untuk dirilis. Jika seseorang meminta biner itu, mudah saja mengambilnya dari tempat yang sama dengan yang lainnya. Biaya pengelolaan yang besar dibandingkan dengan rasa sakit harus membangun kembali, dan biaya menyimpannya dengan sumber tidak signifikan. Saya pernah ke sana (dengan aplikasi VB6 yang dibuat dengan kontrol pihak ke-3 ketika pelanggan melaporkan bug - mendapatkan biner dan menjalankannya jauh lebih mudah daripada membangunnya kembali, yang ternyata tidak mungkin)

— gbjbaanb

1

@ gjbaanb Saya akan mengakui juga bahwa Anda berada dalam situasi yang berbeda dari saya dengan cara lain: semua dependensi eksternal saya adalah OSS, jadi mereka tidak dapat pergi hanya karena beberapa perusahaan tidak lagi ingin melepaskannya.

— Marnen Laibow-Koser

1

Maksud saya adalah bahwa SCM dapat menyimpan semuanya, jadi tidak perlu untuk tidak menyimpan biner secara terpisah dari sumbernya. Nyaman dan mudah serta menjamin Anda tahu apa yang terjadi bertahun-tahun kemudian. Tidak ada kerugian untuk melakukannya. Setiap rilis yang diberikan itu sendiri hanya sinkron dengan satu sumber komit juga. Saya tidak melihat masalah, kecuali bahwa beberapa orang berpikir SCM hanya berarti teks kode sumber. Tidak, gunakan untuk menyimpan hampir semua (kadang-kadang termasuk alat atau lib jika mereka tidak besar), hidup menjadi lebih mudah.

— gbjbaanb

1

@ gjbaanb Dan poin saya adalah bahwa Anda salah tentang itu. :) Tentu, VCS dapat menyimpan semuanya, tetapi mereka tidak diatur dengan baik untuk menyimpan file yang hanya hidup untuk satu komit (setelah semua, Anda tidak ingin r500 Anda membangun repo di r550; itu hanya akan membingungkan) . Masalah mendasar dengan menyimpan artefak bangunan di repo bukanlah bahwa mereka biner , tetapi mereka data turunan dan akan tidak sinkron dengan sumbernya di repo yang sama. Argumen yang sama yang saya gunakan akan berlaku untuk file teks yang dihasilkan.

— Marnen Laibow-Koser

5

Saya tidak menyimpan rilis binari di bawah kontrol versi. Sebaliknya saya menerbitkannya ke lokasi yang terdefinisi dengan baik sehingga alat-alat lain dan memeriksa dan menggunakannya. Saya melakukan banyak pekerjaan di Jawa, jadi itu berarti saya menerbitkan Jars ke repositori Maven lokal. Namun, saya tidak menggunakan alat ini untuk melacak apa yang telah berubah per rilis. Bagaimanapun, mereka adalah binari dan tidak ada banyak untuk dilacak selain jumlah file.

Untuk melacak perubahan di antara rilis, saya akan menandai atau memberi label rilis di sistem kontrol versi saya dengan nomor versi rilis. Tapi ini hanya untuk melacak file sumber, bukan binari. Binari adalah artefak dari build dan tidak perlu di bawah kontrol versi.

— Jeremy Heiler
sumber

1

Solusi terbaik adalah dengan menggunakan sistem CI Anda secara eksklusif untuk semua versi signifikan organisasi (rilis, rilis kandidat dll ...).

Ini secara sistematis mengikat binari yang dirilis ke konten repositori tanpa harus benar-benar menyimpan binari dalam repositori.

Misalnya, jika Anda menggunakan SVN, gunakan skema organisasi cabang-utama; lakukan semua pengembangan sehari-hari di / trunk, dan buat / tag untuk setiap rilis setelah siap.

Konfigurasikan sistem CI Anda untuk membangun dari tag maupun dari trunk, dan minta untuk menulis output ke direktori jaringan yang strukturnya mencerminkan struktur tingkat atas dari repo:

/ builds / trunk / [rev] [date] [build_id] /
/ builds / tag / release_0_1_3beta4 / [rev] [date] [build_id] /

Sistem build perlu memperlakukan direktori / builds / trunk / seperti buffer bundar, menyimpan n build terakhir, menghapus build lama saat berjalan.

Direktori / builds / tags / , di sisi lain, adalah toko permanen. Artefak buatan sendiri disimpan di direktori dengan nama yang dihasilkan sesuai dengan skema berikut:

[rev] [date] [build_id]

di mana [rev] adalah revisi ID SVN, [tanggal] adalah tanggal dalam format YYYYMMDD, dan [build_id] adalah penghitung unik 3 digit, bertambah dari bangunan pertama dan seterusnya, membuat setiap direktori bangunan menjadi unik.

Proses yang dirinci di atas memberi Anda manfaat berikut:

Bangun artefak terikat secara sistematis ke sumber yang dihasilkannya, sehingga Anda dapat menemukan sumber untuk artefak bangunan tertentu dengan sangat mudah, (dan sebaliknya).
Ini membentuk dasar untuk otomatisasi rilis lebih lanjut. Misalnya, pembuatan dokumen rilis otomatis dll ...

— William Payne
sumber