Apa Bagian dari Proyek Anda Seharusnya di Kontrol Kode Sumber?


54

Sesama pengembang telah mulai bekerja pada proyek Drupal baru, dan sysadmin telah menyarankan bahwa mereka hanya harus menempatkan situs / subdirektori default dalam kontrol sumber, karena "akan membuat pembaruan dengan mudah dapat skrip." Mengesampingkan klaim yang agak meragukan itu, menimbulkan pertanyaan lain - file apa yang harus di bawah kendali sumber? Dan apakah ada situasi di mana sebagian besar file harus dikecualikan?

Pendapat saya adalah bahwa seluruh pohon untuk proyek harus di bawah kendali, dan ini akan berlaku untuk proyek Drupal, rel, atau apa pun. Ini seperti no-brainer - Anda jelas perlu versi untuk kerangka kerja Anda sebanyak yang Anda lakukan untuk kode kustom apa pun yang Anda tulis.

Yang mengatakan, saya ingin mendapatkan pendapat lain tentang ini. Apakah ada argumen untuk tidak mengendalikan semuanya?


2
Apa pun yang menghasilkan representasi akhir (termasuk dokumentasi) harus di bawah kontrol versi, asalkan penyimpanan tersebut layak. Kedengarannya seperti pembuatan kode sedang diragukan terkait dengan versi di sini, di mana saya akan memeriksa klaim dengan mudah scripting (baca: menghasilkan) pembaruan dari apa yang Anda versi.
MrGomez

Jawaban:


71

Saya akan mengatakan bahwa minimum yang harus mengandung kontrol sumber adalah semua file yang diperlukan untuk membuat ulang versi proyek yang berjalan. Ini bahkan termasuk file DDL untuk mengatur dan memodifikasi skema basis data apa pun, dan dalam urutan yang benar juga. Minus, tentu saja, alat yang diperlukan untuk membangun dan menjalankan proyek serta apa pun yang dapat secara otomatis diperoleh / dihasilkan dari file lain dalam kontrol sumber (seperti file JavaDoc yang dihasilkan dari file Java dalam kontrol sumber).


1
@EdWoodcock: Anda benar, mendapatkan pesanan yang benar bisa sangat menyusahkan, tetapi kadang-kadang Anda ingin membuat kembali kondisi database tertentu, atau secara opsional menerapkan perubahan tertentu saat menguji daripada menjatuhkan / membuat ulang semuanya. Saya merasa ini bervariasi berdasarkan proyek.
FrustratedWithFormsDesigner

1
Poin yang diambil, ada tingkat atau pragmatisme yang diperlukan untuk itu.
Ed James

3
@JayBazuzi: Panduan pengaturan workstation (dalam kontrol sumber) harus menguraikan alat dan dependensi yang diperlukan, serta cara mengatur dan dari mana mendapatkan alat tersebut. Mempertahankan toolkit yang dapat digunakan adalah penting, tetapi bukan tujuan dari kontrol sumber. Saya kira jika Anda BENAR - BENAR ingin, Anda bisa menambahkan file installer / .msi dan beberapa file instruksi, tetapi itu mungkin tidak layak di tempat kerja. Apakah Anda benar-benar ingin memeriksa di VisualStudio Pro 2010 atau IBM RAD, XMLSpy, dll, ke dalam sistem kontrol sumber Anda ? Banyak tempat kerja mengendalikan penyebaran alat-alat ini.
FrustratedWithFormsDesigner

2
@artistoex: Itu rambut yang membelah. Secara umum diasumsikan bahwa build box memiliki pustaka yang sama dengan dev box. Jika keduanya berbeda, ada yang salah dengan manajer TI. Yang Anda (idealnya) butuhkan hanyalah kode sumber. Beberapa proyek ini tidak berlaku, tetapi untuk sebagian besar seharusnya.
Mike S

1
@ Mike, aku bersungguh-sungguh. Saya pikir Kent Beck dalam sebuah buku tentang XP yang sebenarnya mengusulkan itu. Bukan ide yang buruk. Anda hampir 100% yakin dapat merekonstruksi semua faktor build. Dan jangan lupa lingkungan yang paling mungkin berubah selama proyek.
artistoex

29

Yang terbaik adalah menempatkan segala sesuatu di bawah matahari ke dalam kendali sumber.

  • Kode

  • Perpustakaan

  • Sumber daya

  • Bangun / Terapkan Skrip

  • Pembuatan basis data dan perbarui skrip

  • Dokumentasi tertentu

  • File Konfigurasi Khusus Lingkungan

Satu-satunya hal yang tidak boleh dimasukkan ke dalam kontrol sumber adalah membangun artefak untuk proyek Anda.


5
Pastikan bahwa "dokumentasi tertentu" tidak bergantung pada alat tertentu. Saya telah mengalami sejumlah proyek yang menggunakan sesuatu seperti SunOS versi Frame untuk melakukan dokumentasi, mereka memeriksa semua file ".mif", tetapi bukan file .ps atau .pdf yang dihasilkan. Sekarang SunOS dan Frame diturunkan ke tempat sampah sejarah, banyak dokumen desain hanya ada sebagai salinan kertas berharga.
Bruce Ediger

2
@BruceEdiger Dalam hal ini saya pribadi ingin output dan informasi spesifik alat. Jika alat ini hilang, Anda setidaknya masih memiliki salinan elektronik statis :)
maple_shaft

salah satu keuntungan di sini dari perusahaan proses besar, sumber masuk ke vcs, hal-hal yang dihasilkan harus masuk ke sistem manajemen konfigurasi, jadi bahkan jika alat Anda mati Anda masih memiliki hasil yang dikontrol
jk.

Bagaimana dengan versi spesifik dari kompiler yang Anda gunakan? Heck, mengapa tidak seluruh OS?
Berkumandang

18

Saya akan mengatakan itu;

  • file apa pun yang diperlukan untuk melakukan build masuk ke kontrol versi
  • file apa pun (yang dapat) dihasilkan oleh build tidak

Saya cenderung untuk menempatkan binari besar seperti paket instal alat di suatu tempat di luar trunk, tetapi mereka masih harus di bawah kontrol versi.


15

Dan jangan lupa untuk meletakkan semua kode basis data di Kontrol Sumber juga! Ini akan mencakup skrip pembuatan asli, skrip untuk mengubah tabel (yang ditandai oleh versi perangkat lunak mana yang menggunakannya, sehingga Anda dapat membuat kembali versi database apa pun untuk versi aplikasi apa pun) dan skrip untuk mengisi tabel pencarian apa pun.


15

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. ( ./buildadalah standar yang masuk akal; ./configure; makehampir 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.)

Jangan lupa untuk memeriksa perangkat keras yang sulit diganti. Satu perusahaan kehilangan build karena mereka tidak lagi memiliki beberapa CPU (HPPA? 68040?) Yang menjalankan alat build.
hotpaw2

1
Apa artinya "sistem CM"?
Bodo

1
Dalam kebanyakan kasus, saya lebih suka mendokumentasikan binari dan versi daripada melakukan binari sendiri. Ya - dalam kasus Anda, binari sulit diperoleh, dan Anda tidak memiliki metode lain yang bagus untuk menyimpannya. Tapi saya merasa secara umum mendokumentasikan semua dependensi serta cara mengatur sesuatu (seperti dev VM) berfungsi sebagai padanan yang lebih ringan. Menulis naskah itu meningkatkan reproduksi, tetapi pada akhirnya kita semua harus mengirim.
Iiridayn

Downvoting karena saran untuk meletakkan toolchain dan membangun artefak di kontrol sumber. Ya, jika Anda memiliki solusi manajemen yang buruk untuk itu, kadang-kadang mungkin diperlukan, tetapi itu tidak pernah diinginkan. Dan alat OSS populer seperti PHP akan selalu tersedia (karena tidak ada penerbit tunggal untuk menghilang), jadi itu pasti tidak diperlukan dalam kasus pertanyaan ini.
Marnen Laibow-Koser

13

Satu-satunya hal yang saya tidak letakkan di bawah kendali sumber adalah file yang Anda dapat dengan mudah membuat ulang atau khusus pengembang. Ini berarti executable dan binary yang terdiri dari kode sumber Anda, dokumentasi yang dihasilkan dari membaca / mem-parsing file di bawah kendali sumber, dan file khusus IDE. Segala sesuatu yang lain masuk ke kontrol versi dan dikelola dengan tepat.


7

Kasus penggunaan untuk kontrol sumber adalah: Bagaimana jika semua mesin pengembang kami dan semua mesin penempatan kami terkena meteor? Anda ingin pemulihan sedekat mungkin dengan checkout dan membangun sebanyak mungkin. (Jika itu terlalu konyol, Anda bisa menggunakan "merekrut pengembang baru.")

Dengan kata lain, segala sesuatu selain OS, aplikasi, dan alat harus di VCS, dan di sistem tertanam, di mana ada ketergantungan pada versi alat biner tertentu, saya telah melihat alat disimpan di VCS juga!

Kontrol sumber yang tidak lengkap adalah salah satu risiko paling umum yang saya lihat ketika berkonsultasi - ada segala macam gesekan yang terkait dengan membawa pengembang baru atau menyiapkan mesin baru. Seiring dengan konsep Integrasi Berkelanjutan dan Pengiriman Berkelanjutan Anda harus memiliki rasa "Pembangunan Berkelanjutan" - dapatkah seorang TI membuat mesin pengembangan atau penempatan baru secara otomatis, sehingga pengembang dapat melihat kode sebelum selesai secangkir kopi pertama mereka?


1
Ini juga berarti bahwa bekerja dari banyak mesin tidak menimbulkan rasa sakit. Tarik saja repo, dan Anda siap pergi.
Spencer Rathbun

+1 untuk referensi meteor, yang merangkum semuanya dengan baik.
muffinista

Dapatkah seseorang menunjuk ke contoh (misalnya) proyek java dengan toolchain penuh di bawah kendali rev sehingga dapat diperiksa dan digunakan secara langsung?
andersoj

@andersoj Periksa boxen.github.com
Larry OBrien

6

Apa pun yang berkontribusi pada proyek dan Anda ingin melacak perubahan.

Pengecualian dapat mencakup gumpalan biner besar seperti gambar, jika Anda menggunakan scm yang tidak menangani data biner dengan sangat baik.


2

Drupal menggunakan git jadi saya akan menggunakan terminologi git. Saya akan menggunakan subrepo untuk setiap modul untuk dapat menarik pembaruan modul dari repo resmi drupal, sambil tetap mempertahankan struktur penyebaran individu. Dengan cara itu Anda mendapatkan manfaat skripabilitas tanpa kehilangan manfaat memiliki segalanya di bawah kendali sumber.


1

Semuanya harus di bawah kendali sumber, kecuali:

  • File konfigurasi, jika menyertakan opsi konfigurasi yang berbeda untuk setiap pengembang dan / atau masing-masing lingkungan (pengembangan, pengujian, produksi)
  • File cache, jika Anda menggunakan cache sistem file
  • Log file, jika Anda masuk ke file teks
  • Apa pun yang suka file cache dan file log dihasilkan konten
  • (Sangat) File biner besar yang tidak mungkin berubah (beberapa sistem kontrol versi tidak menyukainya, tetapi jika Anda menggunakan hg atau git, mereka tidak terlalu keberatan)

Pikirkan seperti itu: Setiap anggota baru dalam tim harus dapat mengecek salinan proyek yang berfungsi (minus item konfigurasi).

Dan jangan lupa untuk menempatkan perubahan skema database (kesederhanaan sql setiap perubahan skema) di bawah kontrol versi juga. Anda dapat menyertakan dokumentasi pengguna dan api, jika masuk akal untuk proyek tersebut.


@maple_shaft memunculkan masalah penting dengan pernyataan pertama saya mengenai file konfigurasi lingkungan di komentar. Saya ingin mengklarifikasi bahwa jawaban saya adalah untuk pertanyaan spesifik, yaitu tentang proyek CUP Drupal atau generik. Dalam skenario seperti itu, Anda biasanya memiliki basis data lokal dan produksi, dan satu opsi konfigurasi lingkungan adalah kredensial ke database ini (dan kredensial serupa). Disarankan bahwa ini TIDAK di bawah kendali sumber, karena itu akan menciptakan beberapa masalah keamanan.

Namun, dalam alur kerja pengembangan yang lebih umum, saya setuju dengan maple_shaft bahwa opsi konfigurasi lingkungan harus di bawah kendali sumber untuk memungkinkan pembangunan satu langkah dan penggunaan lingkungan apa pun.


3
-1 SANGAT TIDAK SETUJU dengan pernyataan Anda tentang file konfigurasi yang tidak termasuk dalam kontrol sumber. Mungkin file konfigurasi khusus pengembang ya, namun file konfigurasi khusus lingkungan diperlukan jika Anda menginginkan kemampuan untuk membangun satu langkah dan menggunakan lingkungan apa pun.
maple_shaft

2
@maple_shaft Dalam konteks pertanyaan (proyek drupal atau proyek web CMS gereric) "pembangunan satu langkah dan penerapan lingkungan apa pun" adalah skenario yang sangat tidak mungkin (akankah Anda memasukkan kredensial basis data produksi dengan segalanya?). Saya menjawab pertanyaan, tidak memberikan pedoman umum tentang apa yang harus dimasukkan di bawah kontrol versi. - Tapi downvote Anda diterima :)
yannis

Saya dapat melihat dalam situasi di mana repositori kode sumber bersifat publik, seperti dalam open source atau di mana keamanan menjadi perhatian ekstrem seperti di lembaga keuangan yang kredensial basis datanya tidak termasuk dalam kontrol sumber. Di luar itu kontrol sumber harus dilindungi kata sandi dan terbatas pada sekelompok pengguna tertentu, sehingga kredensial database dalam kontrol sumber tidak boleh menjadi perhatian utama dalam skenario itu. Bahwa Anda menunjukkan kepada saya bahwa downvote tampaknya keras, jika Anda mengedit jawaban Anda, saya dapat menghapusnya.
maple_shaft

@maple_shaft Jangan khawatir tentang downvote (saya sudah mengedit pertanyaan, tetapi jangan ragu untuk meninggalkannya jika Anda mau). Adapun kontrol versi yang dilindungi kata sandi: Kami baru-baru ini harus berhadapan dengan situasi di mana laptop dicuri dari anggota tim manajemen kami, yang berisi kata sandi ke sistem kontrol versi kami (yang pada saat itu memiliki kredensial S3 kami). Itu adalah snafu besar dari pihaknya (laptop tidak dilindungi kata sandi, dan beberapa detail lain yang tidak bisa saya ungkapkan) tetapi tetap saja itu adalah sesuatu yang dapat terjadi pada semua orang. Membangun dari pengalaman itu, kami memindahkan semuanya dari vcs.
yannis

@maple_shaft dan meskipun sepertinya saya menganjurkan paranoia, kita sekarang pergi ke ekstrim untuk melindungi apa pun yang terkait dengan kredensial dari snafus serupa.
yannis

1

Apa pun membangun otomatis Anda tidak menghasilkan tidak tidak masuk kontrol sumber. Apa pun yang tidak memerlukan modifikasi selama build memang masuk dalam kontrol sumber. Sesederhana itu.

Misalnya, berikut ini tidak masuk dalam kontrol sumber:

  • kode yang dihasilkan
  • biner yang dihasilkan
  • apapun yang dibuat oleh build Anda
  • apa pun yang dibuat saat runtime oleh layanan, proses, aplikasi web Anda

Apa yang masuk dalam kontrol sumber:

  • apa pun yang diciptakan manusia
  • apa pun yang dibuat oleh orang atau grup lain (mis. perpustakaan internal pihak ketiga tempat kendali sumber didistribusikan atau binari proyek sumber terbuka).
  • skrip dan sumber lain yang membuat hal-hal seperti database (yaitu bagaimana Anda membuat ulang db jika semua DBA pergi AWOL).

Aturan praktis ini didasarkan pada anggapan bahwa apa pun yang ada dalam kontrol sumber dapat dimodifikasi oleh manusia dan dapat mengambil waktu berharga seseorang untuk memahami mengapa itu ada.


1

Apa pun yang Anda perlukan untuk bekerja dan dapat berubah perlu diversi versi dengan cara apa pun. Tetapi jarang ada kebutuhan untuk memiliki dua sistem independen melacaknya.

Apa pun yang dihasilkan dengan cara yang andal biasanya dapat dilampirkan ke versi sumber - oleh karena itu tidak perlu dilacak secara independen: sumber yang dihasilkan, biner yang tidak diteruskan dari sistem ke yang lain, dll.

Membuat log dan hal-hal lain yang mungkin tidak ada yang peduli (tapi Anda tidak pernah tahu pasti) biasanya dilacak oleh siapa pun yang membuatnya: jenkins, dll.

Membangun produk yang diteruskan dari satu sistem ke sistem lain perlu dilacak, tetapi repo pakar merupakan cara yang baik untuk melakukannya - Anda tidak perlu tingkat kontrol yang disediakan oleh sumber kontrol. Hasil kerja seringkali dalam kategori yang sama.

Apa pun yang tersisa (dan pada titik ini, harus ada sedikit lebih dari file sumber dan membangun konfigurasi server) masuk ke kontrol sumber.


0

Jawaban saya cukup sederhana: bukan binari. Implikasinya, hampir semuanya.

(Jelas bukan backup database atau migrasi skema atau data pengguna.)


Migrasi skema benar-benar masuk dalam kontrol sumber. Dengan begitu Anda tahu skema DB apa yang diharapkan oleh kode.
Marnen Laibow-Koser

0

Kontrol sumber adalah mekanisme pelacakan perubahan. Gunakan saat Anda ingin tahu siapa yang mengubah apa dan kapan.

Kontrol sumber tidak gratis. Ini menambah kompleksitas alur kerja Anda, dan membutuhkan pelatihan untuk kolega baru. Timbang manfaat terhadap biaya.

Misalnya, mungkin sulit untuk mengontrol basis data. Kami dulu memiliki sistem di mana Anda harus menyimpan definisi secara manual dalam file teks dan kemudian menambahkannya ke kontrol sumber. Ini membutuhkan banyak waktu dan tidak dapat diandalkan. Karena tidak dapat diandalkan, Anda tidak dapat menggunakannya untuk mengatur database baru, atau untuk memeriksa pada waktu apa perubahan dibuat. Tetapi kami menyimpannya selama bertahun-tahun, menghabiskan banyak waktu, karena manajer kami berpikir "semua hal harus ada dalam kendali sumber".

Kontrol sumber bukanlah sihir. Cobalah, tetapi tinggalkan jika tidak menambah nilai untuk mengimbangi biaya.


2
Apakah kamu serius? Kontrol sumber buruk karena membutuhkan pelatihan untuk kolega baru? Apakah Anda benar-benar mengatakan Anda lebih suka bekerja jangka panjang dengan orang-orang yang tidak tahu cara menggunakan kontrol sumber dan tidak mau belajar? Secara pribadi saya lebih suka membalik burger.
Zach

Hehe Saya tidak menentang kontrol sumber, hanya menentang secara buta menggunakan kontrol sumber untuk semuanya. Jika kontrol sumber memiliki alur kerja yang sangat kompleks dan itu tidak menambah nilai, saya lebih suka untuk tidak menggunakannya.
Andomar

2
Maksud saya adalah, bahkan jika Anda hanya menggunakannya untuk beberapa hal ( cough source code cough ), kolega Anda harus sudah tahu cara menggunakannya, jadi latih mereka tidak perlu menambah biaya overhead dalam menggunakannya untuk hal lain.
Zach

0

Hal-hal yang tidak akan saya masukkan ke dalam kendali sumber:

  • Kunci dan kata sandi rahasia
  • SDK meskipun itu direktori yang sama dan jika saya membuat tambalan ke SDK maka harus membuatnya menjadi proyek lain karena itu akan per kerangka kerja bukan per aplikasi
  • Perpustakaan pihak ketiga seperti. Sisa dari migrasi, cadangan, kode yang dikompilasi, kode di bawah lisensi lain (mungkin)

Jadi saya tidak melakukan hg addremovemisalnya karena membuat klon baru sesekali ketika pembaruan SDK. Itu juga membuat saya melakukan backup lengkap setiap kali SDk memperbarui dan memeriksa apakah versi baru yang dikloning dari repositori sudah baik.


0

Saya sangat merekomendasikan kepada Anda buku berikut yang membahas masalah Anda:

Pengiriman Berkelanjutan: Rilis Perangkat Lunak yang Andal melalui Build, Test, dan Deployment Automation . Secara khusus, Bab 2 membahas item yang akan ditempatkan ke dalam kontrol sumber, yang seperti yang dikatakan beberapa orang, secara praktis adalah segalanya kecuali sebagian besar konten yang dihasilkan sebagai hasil dari build.

Saya tidak setuju dengan satu bagian dari jawaban yang diterima yang diberikan oleh @FrustratedWithFormsDesigner kurang karena dia menganjurkan tidak menempatkan ke dalam versi mengontrol alat yang diperlukan untuk membangun proyek. Suatu tempat di kontrol sumber (berdekatan dengan kode yang sedang dibangun) haruslah skrip build untuk membangun proyek dan skrip build yang dijalankan dari baris perintah saja. Jika dengan alat yang ia maksudkan, IDE dan editor, mereka seharusnya tidak diminta untuk membangun proyek apa pun. Ini bagus untuk pengembangan aktif / cepat untuk pengembang dan pengaturan jenis lingkungan ini dapat dituliskan juga atau diunduh dari bagian lain SCM atau dari beberapa jenis server manajemen biner dan pengaturan IDE semacam itu harus seotomatis mungkin.

Saya juga tidak setuju dengan apa yang dikatakan @Yannis Rizos tentang menempatkan konfigurasi untuk lingkungan dalam kontrol sumber. Alasannya adalah bahwa Anda harus dapat merekonstruksi lingkungan apa pun sesuka hati hanya dengan menggunakan skrip dan tidak dapat dikelola tanpa pengaturan konfigurasi dalam kontrol sumber. Juga tidak ada sejarah bagaimana konfigurasi untuk berbagai lingkungan telah berevolusi tanpa menempatkan informasi ini ke dalam kendali sumber. Sekarang, pengaturan lingkungan produksi mungkin dirahasiakan atau perusahaan mungkin tidak ingin menempatkan ini dalam kontrol versi, jadi opsi kedua adalah tetap menempatkannya dalam kontrol versi sehingga mereka memiliki sejarah, dan memberikan repositori ini akses terbatas.


-1

Simpan semua kode dalam kontrol versi dan semua konfigurasi & data pengguna. Agar spesifik untuk drupal, Anda harus meletakkan semuanya di kontrol versi kecuali file dan settings.php

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.