Kasus bisnis untuk sistem kontrol versi desentralisasi

26

Saya mencari dan tidak dapat menemukan alasan bisnis mengapa sistem git / mercurial / bazzr lebih baik daripada sistem terpusat (subversi, terpaksa).

Jika Anda mencoba menjual DVCS kepada orang non-teknis, argumen apa yang akan Anda berikan untuk DVCS yang meningkatkan laba .

Saya akan segera mengirimkan git ke manajer saya, itu akan memakan waktu beberapa lama untuk mengubah repositori subversi dan beberapa biaya dalam membeli lisensi smartgit.

Sunting Saya mencoba menjadikan pertanyaan ini menjadi diskusi umum tentang terpusat vs terdesentralisasi, tetapi mau tidak mau itu telah berubah menjadi git vs subversi. Tentunya ada sistem terpusat yang lebih baik daripada subversi.

version-control mercurial dvcs svn git Keyo
sumber
1
Kami berada dalam posisi yang sama dalam membuat kasus dan harus dikatakan, saya tidak yakin bahwa ada satu saat ini.
Jon Hopkins
Bisakah git-svnmemenuhi kebutuhan Anda?
JBRWilkinson
@ JBRWilkinson Saya baru saja menggunakan git-svn untuk memigrasi sekelompok repositori ke git. Perusahaan tidak memiliki banyak investasi dalam alat yang berintegrasi dengan svn sehingga tidak banyak masalah.
Keyo
Ref edit - Anda masih belum menjelaskan bagaimana dan mengapa SVN mengecewakan Anda sehingga Anda merasa perlu pengganti. Jawaban saya (misalnya) BUKAN tentang git vs svn tentang menemukan kasus bisnis untuk mengubah status quo.
Murph

Jawaban:

23

Hmm, setelah menjadi manajer, saya memiliki dua reaksi "spontan" untuk ini:

  • Jika Anda belum memiliki alasan yang bagus mengapa Anda melempar git selain menjadi trendi?
  • Demikian pula, bagaimana Subversi gagal sehingga Anda perlu pengganti?

Sebenarnya, saya bukan negatif - saya pikir mungkin ada kasus yang harus dibuat (tergantung pada keadaan) tetapi jika kasusnya hanya bahwa git "lebih baik" daripada subversi maka Anda tidak benar-benar memilikinya.

Anda juga harus dapat menghitung kekurangannya - Anda telah mengidentifikasi overhead migrasi dan menginstal ulang - apa lagi yang menjadi masalah? mis. Apa yang terjadi pada repositori Anda yang bagus, terpusat, dan didukung? Bagaimana Anda mengintegrasikan dengan server build integrasi berkelanjutan Anda (jika Anda tidak memilikinya, lupakan git dan lakukan sortir dulu). Oh keamanan dan pelacakan - SVN berjalan dengan login dan izin yang tepat.

Menurut saya, manfaatnya adalah fleksibilitas, penggabungan yang lebih baik, kemampuan untuk melakukan komitmen lokal tanpa merusak build dan sebagainya. Kerugiannya adalah kurangnya kontrol dan fleksibilitas yang sama.

Mungkin yang ingin Anda lakukan adalah menjalankan git secara lokal ke mesin Anda sebagai klien subversi yang "lebih baik" (Saya melihat ini menggunakan mercurial).

Hmm, mungkin seluruh jawaban ini benar-benar komentar? Anda perlu membuat kasing Anda di sini (dalam pertanyaan) untuk git over subversi (di lingkungan Anda) untuk mengetahui apakah kami dapat membantu Anda mengidentifikasi kasing bisnis.

FWIW, saya tahu bahwa seseorang dapat dengan mudah menunjuk contoh spesifik dari repositori untuk menjadi sumber trunk / referensi dan lebih jauh bahwa itulah cara seseorang menghubungkan server build-nya - perbedaannya adalah dengan DVCS yang lebih merupakan keputusan administratif daripada sesuatu yang melekat dalam arsitektur.

Murph
sumber
1
Mengatasi masalah izin / fleksibilitas: Anda masih memerlukan repositori "sumber" juga, tempat Anda dapat mengatur haknya seperti biasa. Integrasi Berkelanjutan berjalan untuk repositori sumber, pengembang mengkloning repositori sumber, dll ... Cadangannya kurang penting, karena semua orang memiliki klon, bukan hanya checkout.
Matthieu M.
1
Poin tentang klon penuh menjadi cadangan dibuat dengan baik. Saya akan dengan bebas mengakui bahwa ada beberapa bidang yang tidak saya pahami dengan baik karena "pekerjaan" saya adalah svn dan lincah saya bersifat pribadi dan, sampai sekarang, agak terbatas.
Murph
14

Saya akan mengatakan percabangan dan penggabungan yang cepat dan tidak menyakitkan akan memungkinkan pengembang menjadi lebih produktif dengan kode mereka, karena setiap fitur baru dapat bercabang, kemudian digabungkan. Membuat proses pengembangan berjalan jauh lebih lancar. Juga, sifat terdistribusi, akan memungkinkan setiap pengembang untuk memiliki seluruh salinan kode, sehingga tidak ada kekhawatiran kegagalan server terpusat mencatat semua kode Anda. Mungkin ada lebih banyak alasan, tetapi keduanya adalah alasan utama saya untuk menggunakan Git.

sarung tangan mbreed
sumber
2
Dalam lingkungan bisnis, 'server terpusat' akan memiliki cadangan, cadangan, dan admin yang bertanggung jawab untuk mempertahankannya (dan semua server lainnya) tetap hidup.
JBRWilkinson
2
Dalam lingkungan bisnis yang besar, Anda akan mengalami redundansi server. Dalam bisnis kecil redundansi server seperti itu tidak begitu pasti.
Michael Shaw
2
Kegagalan server terpusat tidak akan menghapus semua kode Anda. Bahkan jika Anda tidak memiliki cadangan, hal terburuk yang bisa dilakukan adalah mencatat riwayat revisi Anda. Tetapi selama semua pengembang memeriksa kode, kode itu ada dalam bentuk saat ini pada sistem mereka juga.
Mason Wheeler
1
@mason: tapi itu cukup asumsi: 'selama semua pengembang ... ". Karena pada perusahaan berskala kecil dengan proyek berskala lebih kecil, proyek dapat hidup dan digunakan dengan bahagia tanpa ada orang yang mengkodekannya selama setahun atau dua
Inca
Dan juga, saya tidak akan meremehkan nilai sejarah komit. Dalam sistem yang sangat besar, sangat berharga untuk melihat siapa dan mengapa melakukan sesuatu terhadap kode tersebut.
Tamás Szelei
8

Saya berasumsi Anda dapat membuat kasus untuk kontrol versi meningkatkan produktivitas (dan dengan demikian keuntungan) bahkan ketika pengembang bekerja sendiri.

DVCS yang baik mengakui manfaat produktivitas yang sama bahkan ketika bekerja sebagai bagian dari tim - setiap pengembang bisa mendapatkan semua manfaat dari bekerja dengan kontrol versi - mereka dapat sering melakukan komitmen, kembalikan, bermain-main dengan hal-hal, dll. - tanpa khawatir tentang konflik dengan apa yang dilakukan pengembang lain sampai mereka siap untuk mendorong perubahan mereka.

Segera.
sumber
Inilah yang akan saya posting, cukup banyak. Anda tentu harus melihat peningkatan produktivitas dari pengembang yang melakukan lebih awal dan sering ke repositori mereka sendiri, tanpa menimbulkan masalah bagi rekan kerja mereka.
Carson63000
5
Maka Anda akan berada di neraka integrasi ketika Anda akhirnya mendorong perubahan Anda. Ini adalah hal yang buruk, bukan hal yang baik.
Henry
Saat Anda melakukan pengembangan lokal dengan banyak komitmen, Anda dapat terus menarik perubahan dari repositori pusat dan menjaga perubahan lokal Anda sejalan dengan pengembangan yang sedang berjalan yang sedang dilakukan orang lain. Jadi ketika tiba saatnya untuk mendorong perubahan Anda ke repositori pusat Anda harus sudah memiliki sebagian besar perubahan yang telah terjadi di sana dan integrasi akan mudah.
DaveJohnston
1
Kecuali salah satu rekan kerja Anda telah melakukan hal yang persis sama dan Anda berdua belum terintegrasi untuk sementara waktu. Selalu ada trade off. Saya memang pernah melihat kasus di mana hal-hal telah diintegrasikan pada garis utama di mana mereka seharusnya tidak (solusi yang salah, upaya buntu pada solusi dan semacamnya), mengintegrasikan pada kelengkapan fitur memiliki fasilitasnya juga.
Joppe
2
Tidak bisakah Anda melakukan semua hal ini dengan (a) cabang SVN atau (b) banyak salinan yang berfungsi?
JBRWilkinson
4
  • Cabang-per-bug
  • Mengurangi latensi pada diff Anda.
  • Mampu sangat cepat menavigasi sewenang-wenang melalui sejarah cabang ketika Anda rekan meninjau.
  • Anda masih memiliki akses ke seluruh riwayat Anda ketika Anda tidak memiliki akses ke server terpusat: Anda tidak di kantor, listrik padam tetapi baterai laptop Anda masih bekerja, ...

Hal-hal ini memungkinkan Anda bekerja lebih efisien, baik solo maupun dalam tim. Bekerja lebih efisien = waktu pengembangan lebih cepat = waktu lebih cepat ke pasar = keuntungan.

Frank Shearar
sumber
3

Maafkan saya karena menautkan ke blog saya sendiri, tetapi saya telah menulis artikel tentang hal ini:

Jangan ragu untuk downvote jika Anda merasa itu tidak relevan.

Singkatnya, DVCS membuat model percabangan mudah yang dapat membuat kelompok besar pengembang tidak saling melangkah, yang meningkatkan produktivitas dan kualitas bangunan harian Anda. Bagian kolaborasi yang berantakan dari kontrol versi dapat dilakukan di repo lokal, meninggalkan repositori pusat Anda dan berkualitas lebih tinggi. Juga, keputusan tentang kapan harus bercabang dapat memiliki efek besar pada efisiensi, misalnya jika satu departemen siap untuk mulai bekerja pada 2.0 ketika 1.0 masih sedang dibersihkan oleh yang lain. DVCS memungkinkan keputusan itu dibuat di tingkat lokal alih-alih oleh komite.

Karl Bielefeldt
sumber
Entri blog Anda ditulis dengan baik. Saya belum membaca semuanya. Saya ingin tahu mengapa Anda memilih Bzr ketika Git dan Hg tampaknya jauh lebih populer. Orang-orang tampaknya membenci Bzr karena lambat. Saya juga penggemar Git karena hash pohon, bukan angka revisi, yang tampaknya sangat aman bagi saya. Bukankah angka rev bzr akan diacak ketika cabang digabung?
Keyo
2
@ Yaho, saya memilih bzr karena saya harus mengajar DVCS untuk diri saya sendiri dan bzr adalah yang paling ramah-pemula. Saya telah beralih ke git untuk kecepatan, fitur, dan stabilitas sejak saat itu. Bazaar juga membuat revisi-revisi dan memiliki pengidentifikasi unik secara global, mereka bukan default yang diekspos kepada pengguna. Nomor revisi mereka benar-benar tidak berbeda daripada menggunakan HEAD~1, HEAD~2, dll di git. Sangat jarang Anda membutuhkan hash yang sebenarnya, tetapi ini adalah hal pertama yang Anda pelajari di git dan selalu ada di wajah Anda. Menyembunyikan itu dari pengguna kecuali Anda benar-benar membutuhkannya adalah salah satu alasan bzr lebih ramah pemula.
Karl Bielefeldt
Terimakasih atas klarifikasinya. Git tidak mudah bagiku untuk datang dari subversi. Banyak perintah memiliki kata yang sama tetapi melakukan hal yang berbeda.
Keyo
2

Argumen saya untuk DVCS adalah ini:

  • Percabangan tidak rusak, yang menyebabkan lebih sedikit gesekan dalam mengembangkan fitur dan menjaga produk yang ada ditambal. Gesekan membutuhkan uang dalam waktu.

  • Pindah ke sistem modern lebih baik menarik pengembang mutakhir, yang akan mengarah pada budaya produk yang lebih baik, yang memungkinkan bisnis untuk menjual lebih banyak produk.

  • Komitmen non-jaringan lebih cepat , memungkinkan pengembang untuk sering melakukan, yang mengarah pada deteksi bug dan analisis yang baik.

Intinya, ini tentang mengurangi gesekan. Ada istilah untuk ini: Muda . Semakin banyak gesekan, semakin banyak rasa sakit untuk melakukan sesuatu. Semakin banyak rasa sakit, semakin sedikit yang dilakukan, semakin sedikit keuntungan.

Paul Nathan
sumber
2

Saya minta maaf jika saya sombong, tetapi izinkan saya untuk menempatkan kasus bisnis tanpa syarat yang tidak pasti:

SVN membuat hidup para pengembang sengsara . Dan itu membuat bisnis perangkat lunak sengsara.

... dengan cara yang tidak akan disadari banyak orang sebelum mereka mulai menggunakan DVCS. Ini adalah kasus bisnis paling penting yang mungkin dapat dibuat . Mengapa? Nah, dibandingkan dengan biaya untuk menemukan dan mempertahankan pengembang yang baik, biaya untuk beralih ke DVCS hampir tidak ada .

Pertimbangkan yang berikut ini:

  • Semua kecuali operasi paling sepele di SVN (dan sebagian besar CVCSes lainnya) memerlukan akses jaringan. Di sebagian besar DVCSes, akses jaringan hanya terjadi ketika Anda melakukan pushatau pullmengoperasikan. Ini berarti bahwa perintah non-sepele lambat . Apa yang Anda lakukan ketika sebuah perintah mengambil selamanya? Saya pribadi mencari berita programmer atau hacker sementara saya menunggu. Sederhananya, DVCSes memungkinkan programmer untuk fokus melakukan apa yang mereka sukai: menulis perangkat lunak perusahaan .
  • SVN memiliki dukungan untuk bercabang di banyak cara yang sama penjara memiliki dukungan untuk menjatuhkan sabun Anda di kamar mandi: Anda bisa melakukannya, tetapi ketika Anda melakukannya, Anda menjadi kacau. Dengan demikian, SVN memaksa pengembang Anda untuk terus berebut satu sama lain untuk melakukan perubahan .
  • Ketika SVN turun, itu turun. Menjadi sangat sulit bagi pengembang untuk melakukan pekerjaan mereka jika mereka bisa melakukannya sama sekali. Dengan demikian, SVN memaksa pengembang Anda untuk bergantung pada infrastruktur Anda yang 100% bebas bug .
  • Saat ini, git dengan cepat mendapatkan mindshare sementara SVN dengan cepat kehilangannya. Jika tidak ada manfaat menggunakan DVCSes dibandingkan SVN, mengapa komunitas pemrograman berubah secepat mungkin?

Apa artinya semua ini? Saya belum pernah bertemu pengembang yang diberi DVCS percobaan jujur ​​yang akan memilih SVN sesudahnya. Jika saya bisa membuat satu lagi pernyataan yang menyebalkan dan berani, SVN adalah "kejahatan yang perlu" yang memaksa para diri mereka untuk menggunakannya. Git adalah alat yang membuat pengembang lebih produktif dan lebih bahagia .

(Saya harus menunjukkan bahwa pernyataan tebal adalah yang khusus Anda harus fokus pada. Sisanya hanya memberikan konteks.)

Jason Baker
sumber
5
-1 - Anda anggun dan sementara ada beberapa kebenaran dalam apa yang Anda tulis, ia berputar sangat negatif hingga mendekati FUD daripada analisis yang beralasan. Apakah SVN lambat? Hanya jika repositori luas dan jaringan glasial. Apakah SVN sedang turun menghentikan saya bekerja - erm, tidak dapat mengingatnya pernah turun dan TIDAK karena komputer saya tidak bergantung pada keberadaan repositori untuk mengedit / mengkompilasi / menjalankan sumber. Apakah SVN bercabang dan bergabung miskin? Wow orang memiliki ingatan pendek ... mengapa DVCS mendapatkan mindshare? Kecelakaan fungsionalitas - yang ditingkatkan - dan, terus terang, fashion.
Murph
1
@Murph - Suka atau tidak, orang membenci perubahan sampai menjadi lembek. Untuk meyakinkan mereka untuk berubah, Anda perlu meyakinkan mereka bahwa status quo rusak. Dan itu adalah rusak. FUD hanya buruk ketika tidak ada alasan untuk takut, tidak pasti, dan ragu. Sedangkan untuk mindshare, saya setuju dengan Anda. Tapi bukan itu intinya. Apakah orang yang membuat keputusan setuju atau tidak dengannya. Dan setiap manajer yang pernah saya temui telah diyakinkan oleh argumen ini (bahkan jika mereka membenci git).
Jason Baker
2
Saya tidak selalu tidak setuju dengan Anda Jason hanya menyarankan bahwa poin Anda tidak dibuat dengan baik. Khususnya saya pikir Anda sangat bersemangat untuk efek dan jika Anda tertangkap basah melakukan itu Anda cenderung kehilangan poin untuk argumen Anda, bahkan jika Anda benar. (Kecuali untuk poin di mana Anda salah, tentu saja ... (
:)
2
Semua poin Anda lebih merupakan masalah opini daripada fakta. Saya akan menghitung satu per satu tetapi tidak ada cukup ruang dalam komentar. Bagaimana kalau Anda menjawab lagi tanpa megah?
Henry
1
@Henry - Programmers.se untuk pertanyaan dan jawaban subyektif. Subyektif == masalah pendapat.
Jason Baker
1

Satu-satunya hal yang bisa saya pikirkan adalah git bekerja tanpa koneksi jaringan. Segala sesuatu yang lain bahkan seringkali sulit dijual kepada pengguna teknis yang menggunakan subersi atau terpaksa beberapa waktu.

Brainlag
sumber
2
Tentu, tetapi sebagian besar Subversion berfungsi tanpa koneksi jaringan juga. (Tidak melakukan jelas, tetapi hal-hal umum seperti mendapatkan info tentang copy pekerjaan atau berbeda dengan revisi dasar semua pekerjaan.)
j_random_hacker
@ j_random_hacker: Maksud dari VCS adalah untuk melacak perubahan kode. Mengkomit perubahan kode trek. Jika Anda tidak dapat melakukan offline, saya berpendapat bahwa VCS Anda tidak berfungsi saat offline.
Daenyth
1

Perbedaannya muncul ketika ada masalah

Kami beralih ke git 6 bulan lalu setelah porting repositori lama kami.

Sejauh ini saya telah menemukan yang berikut, setelah sedikit bereksperimen:

  • percabangan dan penggabungan hampir tidak menyakitkan. Ini membuatnya lebih mudah untuk bekerja pada fitur-fitur yang terpisah dan perbaikan bug tanpa menginjak kaki masing-masing. Ini juga membuatnya sangat mudah untuk menerapkan perbaikan bug yang diberikan di tempat lain juga.

  • lebih kuat menurut desain - Anda tidak mengandalkan 100% pada server pusat yang tersedia, dan jika tidak, Anda dapat menggunakan mempromosikan klon apa pun untuk sementara sebagai pengganti panas. Ini menghapus titik kegagalan penting - jika server SVN turun karena alasan apa pun, tidak ada yang dapat melakukan pekerjaan SVN. Jika repositori central git turun karena alasan apa pun, Anda masih dapat bekerja dan mendorong / menarik secara lokal untuk memastikan bahwa komit direplikasi. Anda bahkan dapat memiliki beberapa repositori luar-situs untuk tujuan ini.

  • interaksi repositori disederhanakan. Untuk CVS Anda pada dasarnya membutuhkan akses setiap saat kapan pun Anda membutuhkan informasi. Untuk git seluruh repositori tersedia secara lokal memungkinkan banyak hal berjalan lebih cepat.

Jadi, manfaatnya tidak sebanyak dalam rutinitas sehari-hari, tetapi sangat jelas saat Anda memiliki sesuatu yang tidak berfungsi dengan benar!

Oleh karena itu, saya sarankan untuk kasus bisnis Anda, lihat apa yang akan Anda lakukan ketika bencana melanda ...


sumber
Argumennya sama dengan cadangan: Anda hanya membutuhkannya saat terjadi bencana. Pertanyaan adalah apa yang akan Anda lakukan ketika itu terjadi, dan apa yang akan Anda terima terjadi saat itu.
0

Kemudahan bercabang dan menggabungkan adalah alasan paling konkret, tetapi untuk meyakinkan seseorang Anda harus memberi mereka contoh nyata tentang bagaimana hal itu meningkatkan banyak hal.

Katakanlah Anda memiliki beberapa programmer yang bekerja pada peningkatan kinerja untuk suatu aplikasi, dan mereka sedang dalam tahap percobaan dan tidak tahu apakah kode yang mereka tulis akan pernah menjadi bagian dari cabang utama / utama. Namun, mereka perlu sering berbagi kode satu sama lain dan mencoba ide-ide yang mungkin buntu. Bagaimana Anda mengelola percabangan dan penggabungan yang sering terjadi seperti itu? Jawaban singkatnya adalah Anda tidak. Dengan DVD sangat mudah, dan programmer dapat dengan cepat mencoba ide-ide baru di cabang dan berbagi dengan yang lain sebelum memutuskan apakah ide itu akan bertahan.

jshen
sumber
-1

Kasus bisnis untuk membuang SubVersion adalah dukungan percabangan merupakan penghalang untuk stabilisasi dan pemeliharaan produk. Jika Anda perlu merilis produk dan kemudian melanjutkan pengembangan Anda memerlukan cabang. Dengan subversi, pengembang tidak akan menggunakan percabangan dengan baik, sehingga Anda akan gagal untuk menjaga pengembangan pada tunk, dan memastikan bahwa perbaikan bug benar-benar membuatnya ke kedua trunk dan cabang juga.

Michael Shaw
sumber