Kontrol subversi / sumber hanya untuk kode produksi?

21

Saya lulus dari perguruan tinggi di bidang Ilmu Komputer setahun yang lalu, dan sekarang saya bekerja di sebuah perusahaan pengembangan web kecil (saya dan satu pengembang lainnya, plus manajer, layanan pelanggan, dan penguji). Sampai sebelum saya mulai, tidak ada sistem kontrol sumber. Kami sekarang mulai mengimplementasikan SVN secara perlahan, tetapi pengembang (senior) lainnya (selanjutnya disebut Joe) menegaskan bahwa satu-satunya kode yang harus dikomit ke repositori SVN kami adalah kode yang telah diuji dan disetujui sebagai siap produksi. Itu berarti, pada proyek yang lebih besar, mungkin tidak ada komitmen selama berminggu-minggu pada suatu waktu atau lebih.

Apakah ini praktik normal? Sepertinya saya kehilangan banyak manfaat dari kontrol sumber, termasuk:

  • Pelacakan kemajuan proyek secara cermat
  • Pelacakan masalah saat muncul dan diselesaikan
  • Mudah memutar balik kesalahan
  • Pencadangan kode mudah, jadi kami tidak kehilangan banyak jika workstation turun
  • Lebih mudah untuk mengidentifikasi secara tepat kode apa yang berjalan di lokasi produksi, dengan asumsi kami mencap revisi menjadi executable seperti yang dijelaskan di sini
  • Kolaborasi mudah (meskipun kami tidak melakukan kerja tim; itu semua proyek solo)
  • Dll

EDIT: Saya harus menekankan bahwa secara historis, belum ada kerja tim yang sebenarnya di perusahaan ini; hanya dua pengembang yang mengerjakan proyek terpisah. Juga, banyak proyek yang kecil, sehingga dapat diselesaikan dalam beberapa minggu. Dan perusahaan telah berkecimpung dalam bisnis selama lebih dari satu dekade dan bergaul dengan baik tanpa kendali sumber. Proyek biasanya selesai dalam jangka waktu perkiraan mereka.

web-development version-control Tuan Jefferson
sumber
2
Bagaimana dia memotivasi ide ini? Jika dia tidak memberi Anda alasan, sudahkah Anda bertanya?
Anto
8
Apakah "Joe" mengerti Branching? Beberapa pertanyaan lembut untuk mencari tahu bisa jadi menarik.
James
2
@Anto - Saya pikir itu yang terbaik disimpulkan oleh "itu bukan produksi dan tidak boleh menjadi bagian dari repositori produksi".
Tuan Jefferson
1
@ James - Saya tidak berpikir dia tahu SVN secara umum dengan sangat baik, jadi tidak, saya tidak berpikir dia tahu tentang percabangan. Tetapi mengingat tanggapan di bawah ini, saya pikir itu solusinya.
Tuan Jefferson
4
Baca pertanyaan ini dan sebuah suara kecil di kepalaku hanya berteriak "NOOOOOOOOOOOOOooooooooooooo".
Kevin D

Jawaban:

1

Jika proyek selesai dalam jangka waktu perkiraan mereka, apakah aman untuk menganggap bahwa klien adalah klien yang bahagia? :)

Tampaknya perusahaan mulai mengambil jenis-jenis proyek baru juga dan melalui beberapa rasa sakit yang tumbuh atau "rasa sakit yang berubah". Banyak asumsi yang terjadi di sini ... Tolong bersamaku!

Jika Anda yakin bahwa organisasi dan kontrol kode dapat membantu Anda dan tim Anda secara internal maka SVN harus dipertimbangkan, IMHO. Anda mendapatkan poin bonus jika rute ini benar-benar berfungsi dan perusahaan dapat membuat produk berkualitas lebih tinggi sehingga membuat pelanggan lebih bahagia!

Hati-hati jika tampaknya perjuangan dengan manajemen akan membuat lingkungan kerja yang tegang. Faktanya adalah pemilik telah membuat perusahaan. Dan tidak hanya itu, mereka telah membuat perusahaan yang sukses. Tidak mungkin mereka mendapatkan jackpot karena mereka jago bermain judi.

Bersikaplah hormat dan akhirnya Anda didengar.

Semoga ini akan menghasilkan tim yang lebih efisien dan lebih bahagia. Dalam pengalaman saya, itu sulit diperoleh dengan manajemen yang frustrasi.


sumber
42

Joe salah besar. Sekarang, Anda dapat membuat argumen bahwa Anda memiliki satu cabang "bersih" yang mewakili kode, siap-produksi kode. Tetapi tidak menggunakan kontrol sumber sampai barang siap terus terang merugikan diri sendiri. Agak seperti mencoba membuat martini tanpa gin.

Wyatt Barnett
sumber
6
Harap tekankan masalah percabangan dan penandaan. Ini - saya pikir - fitur penting yang membuat orang bersikeras hanya-produksi di SVN.
S.Lott
3
titik yang sangat baik, bahkan dengan bias Anda terhadap vodka.
Covar
Kurang lebih? Saya akan mengatakan dia adalah mati salah. Tidak ada pertanyaan tentang itu.
Steven Evers
2
@Covar: Saya tidak mencemari vodka saya dengan vermouth :)
Wyatt Barnett
22

"Senior" sebenarnya sangat tidak terampil. Kode apa pun yang dapat dikompilasi (dan lulus tes jika Anda memilikinya) harus berkomitmen untuk kontrol sumber. Kontrol sumber adalah aset utama untuk berbagi kode dan membangun SW secara bertahap.

Poin baiknya adalah memisahkan kode produksi (versi stabil terakhir) tetapi untuk sistem kontrol sumber kasus seperti itu berisi fitur-fitur seperti tag / label dan cabang.

Tim kami menjadi sangat curiga jika seseorang tidak melakukan apa pun dalam dua-tiga hari. Itu berarti dia memiliki beberapa masalah dan mungkin butuh bantuan. Poin lain dari kontrol sumber adalah bahwa biasanya dicadangkan secara teratur yang tidak berlaku untuk mesin pengembangan. Jika disk Anda macet, Anda kehilangan pekerjaan selama beberapa minggu.

Ladislav Mrnka
sumber
12
Tetapi dia tidak terampil dalam bekerja sebagai anggota tim.
Ladislav Mrnka
2
@ Tom Hamming: Memotong kode tidak mengembangkan perangkat lunak. Saya yakin dia pandai pemrograman, tetapi hari ini kontrol versi bukan lagi 'alat' daripada IDE adalah alat. Tentu, secara teknis Anda bisa melakukannya tanpanya, tetapi tidak ada yang waras yang melakukannya.
Steven Evers
2
@SnOrfus - Meskipun saya setuju sampai batas tertentu tentang utilitas SCM, tujuan saya dengan pertanyaan ini bukan untuk menampar Joe dan / atau keahliannya sebagai pengembang. Sekali lagi, dia menghasilkan produk yang hebat, dia berpengetahuan luas, dan dia baik-baik saja tanpa SCM selama 10 tahun terakhir. Tujuan saya dengan pertanyaan ini adalah untuk melihat apakah sudut pandangnya dipegang secara luas yang tidak saya temui; Bagaimanapun, saya baru lulus sekolah dan relatif tidak berpengalaman dalam industri ini. Bagaimanapun, saya yakin dia jujur ​​ingin memastikan kualitas dan keandalan alur kerja.
Tuan Jefferson
3
@ Tom: Saya dapat memberitahu Anda sekarang bahwa terlepas dari apa yang Anda pikirkan tentang kualitas karyanya, dia bukan pengembang yang terampil jika dia tidak tahu cara menggunakan kontrol sumber dengan benar. Tidak ada pilihan lain, selain itu mungkin dia sudah bekerja sendirian di ruang bawah tanah. Bahkan dalam proyek saya sendiri di mana saya satu-satunya pengembang, saya menggunakan kontrol sumber sepenuhnya.
Jordan
5
@SnOrfus: Saya bisa bekerja dengan sangat bahagia tanpa IDE. Saya tidak akan bekerja tanpa kontrol versi. Jika tim tidak menggunakannya, saya akan menjalankannya sendiri.
kevin cline
12

Mengesampingkan pertanyaan apakah Joe benar atau salah (dia salah, ngomong-ngomong), menurut saya kompromi dapat dicapai jika Anda menggunakan sistem kontrol versi terdistribusi seperti Git atau Mercurial .

Dengan begitu, Anda dan pengembang lain akan bekerja di repositori lokal Anda, melakukan perubahan Anda ke kontrol sumber lebih awal dan sering, tetapi tidak mendorong perubahan Anda ke repositori "produksi" sampai mereka "diuji dan disetujui sebagai siap produksi". Anda akan memiliki sejarah lengkap dari setiap hal yang Anda kerjakan selama beberapa minggu, dan Joe akan memiliki repositori murni yang hanya memiliki sejarah perubahan yang diberkati sebagai siap untuk diproduksi.

Carson63000
sumber
1
Saya telah memikirkan hal ini dan melakukan sedikit investigasi (dan mendengar hal-hal baik), tetapi keraguan saya terletak pada kenyataan bahwa kita telah membeli dan menginstal VisualSVN Server, dan tidak ada dari kita yang memiliki pengalaman dengan Git atau Mercurial . Akan lebih sulit lagi jika saya mencoba meyakinkan semua orang bahwa kita perlu membeli lebih banyak perangkat lunak dan / atau membuang investasi yang ada. Tapi bagus.
Tuan Jefferson
3
@ Tom: Jika harus Subversion di bagian belakang, Anda dapat menggunakan lapisan interoperabilitas Subversion milik Git atau Mercurial untuk hal-hal yang belum siap produksi, dan dorong pekerjaan ke subversi bila sudah siap.
Ken Bloom
2
@ Tom Hamming: Saya beralih dari SVN ke GIT hampir satu tahun yang lalu. Setelah beberapa sumpah awal, saya mulai menyukainya (meskipun di bawah Cygwin itu tidak berfungsi sebaik di Linux). Saya tidak pernah menghabiskan uang untuk itu, saya cukup puas dengan baris perintah dan dua alat gratis termasuk. Saya bahkan tidak bekerja untuk mengintegrasikannya ke dalam IDE saya (gerhana). YMMV, tetapi jika saya berada di tempat Anda, saya akan menggunakan git repo pribadi saya dan git svnuntuk interaksi. Anda tidak perlu membeli apa pun dan Anda tidak perlu meyakinkan siapa pun; mereka bahkan tidak perlu tahu.
maaartinus
1
@ Tom Hamming: Sebagai pengembang perorangan, Anda dapat memilih untuk secara teratur git pushmengubah Anda ke beberapa mesin lain (sebagai cadangan). Itu tidak harus menjadi repositori "master".
Greg Hewgill
1
@ Tom Hamming: Menempel dengan SVN karena Anda telah membeli dan menginstal server SVN benar-benar merupakan kesalahan biaya cekung. Git dan Mercurial keduanya gratis, dan biaya VisualSVN telah dibayarkan, jadi lihat opsi Anda karena masing-masing memiliki biaya pengaturan awal yang sama (nol).
Cercerilla
7

Tidak masuk akal, untuk alasan yang Anda sebutkan. Ini seperti menggunakan kontrol versi tanpa manfaat menggunakan kontrol versi.

Anto
sumber
5

Saya percaya Joe tidak mengerti bahwa sistem kontrol sumber bukanlah cadangan yang dimuliakan dari rilis produksi kode sumber, tetapi alat yang bermanfaat bagi programmer dengan meletakkan kata-kata pada langkah-langkah kecil dari kemajuan dan pematangan kode untuk masa depan Anda sendiri dan kolega. Mungkin Joe tidak terbiasa bekerja dalam tim dengan kode orang lain?

Pernah dianggap "mengapa baris kode ini ditambahkan"? Temukan komit yang memperkenalkannya, dan lihat komentarnya. Jika Anda hanya berkomitmen ketika akan berproduksi, komentar tidak akan cukup spesifik untuk berguna bagi Anda.

Saya juga menyarankan agar Anda menggunakan alat yang lebih kuat daripada SVN. Anda dapat melihat pengantar yang baik tentang kemungkinan di http://hginit.com/ oleh Joel Spoelsky.

Dia menggunakan lincah, dan ada beberapa pesaing hari ini. Git dianggap sangat kuat, dan https://github.com/ memiliki beberapa alat yang sangat, sangat berguna dan menyediakan akun pemula gratis sehingga Anda dapat mencobanya secara nyata.


sumber
3

Joe sepertinya tidak tahu tentang SVN, coba cari tahu tentang Branches, Tag dan Trunk ... Tag konsisten dengan apa yang diinginkan Joe. Beberapa membaca tentang praktik terbaik SVN tidak ada salahnya

IvoC
sumber
2

Tidak pernah menggunakan SVN jadi saya tidak tahu apa prosedur untuk ini. Kami menggunakan ClearCase, dan praktik di sini adalah untuk setiap pengembang memiliki cabang pengembangan sendiri, kemudian cabang integrasi yang kami gabungkan ketika kami siap untuk memulai pengujian, dan satu atau lebih cabang rilis untuk kode terintegrasi dan teruji .

John Bode
sumber
SVN juga bisa melakukannya.
Phil Lello
2

Joe adalah seorang hacker, bukan pengembang. Dia kedengarannya seperti peretas yang sangat baik, tetapi dia salah tentang cara menggunakan kontrol revisi. Jadi apa yang harus dilakukan?

Sepertinya saya organisasi Anda memiliki investasi di SVN, dan itu akan membatasi karir Anda untuk menantang Joe dan membatalkan investasi dolar di server SVN. Atur repo GIT dan gunakan antarmuka git svn untuk bekerja seperti yang Anda inginkan (Ini semua adalah perangkat lunak gratis dan akan memakan waktu satu jam hingga satu hari untuk pengaturan, semuanya pada workstation Anda). Sosialisasikan alur kerja Anda dengan Joe - ia dapat mempertahankan sistem kepercayaan "repo SVN yang tidak dicemari" dan mempertahankan kredibilitasnya di atas gajah putih yang mahal di sudut (dan ego).

Dalam waktu singkat saya berharap Joe akan melihat cara Anda bekerja, dan mulai melakukan hal yang sama. Dalam satu atau dua tahun, server SVN akan menjadi repo Git.

mattnz
sumber
investasi dolar di server svn tidak lebih dari investasi dolar di server git repo ...
TZHX
2

Anda bisa mencoba meyakinkan Joe dengan argumen di atas. Jika ini tidak berhasil, gunakan SVN secara lokal untuk pekerjaan pengembangan Anda sendiri dan berharap suatu saat akan diambil oleh Joe. Jika Anda tidak dapat meyakinkan mereka dengan argumen, lakukan hal yang Anda yakini dan tunjukkan bahwa itu berhasil. Jenis pendekatan yang didistribusikan tetapi dengan tooling yang ada.

refro
sumber
2

Saya akan menggema @ Carson63000 di sini dan mengatakan bahwa saya telah melihat sikap ini sebelumnya, dan ini sebagian besar disebabkan oleh kemampuan percabangan / penggabungan yang mengerikan dari VCS. Memiliki cabang yang mengkompilasi dan lulus tes, dengan tag untuk setiap rilis, adalah pendekatan yang bagus tetapi tidak harus diikuti sampai pada titik bahwa tidak ada kode lain yang dikomit. DVCS pada umumnya, dan git pada khususnya, membuat percabangan operasi yang mudah dan umum dan itu mengurangi banyak kesulitan dengan alur kerja ini.

Cercerilla
sumber
1

Alasan dukungan tag sistem kontrol versi adalah karena Anda dapat menandai kode yang disertifikasi dan pekerjaan harian Anda tetap dilakukan. Setiap kali Anda memiliki kode kualitas produksi, Anda mengkomitnya dengan tag dan Anda selesai. Anda tahu titik pasti dalam 'waktu' Anda harus kembali untuk mendapatkan apa yang dimiliki pelanggan. Dan Anda selalu dapat memeriksa dan membandingkan berbagai versi kode Anda. Dengan cara ini Anda berdua bisa bahagia dengan apa yang Anda miliki di basis data kontrol sumber. Ini bekerja untuk perusahaan tempat saya bekerja, yang memiliki 100 pengembang, semuanya bekerja pada proyek yang sama. Ini juga akan bekerja untuk Anda.

Gus
sumber
0

Sangat umum untuk hanya menyimpan hal-hal dalam sistem kontrol versi yang siap untuk pengiriman ke produksi. Begitulah cara itu dilakukan secara historis selama beberapa dekade, sejak masa lalu ketika penyimpanan disk menghabiskan biaya ratusan dolar per megabyte dan menyimpan semuanya terlalu mahal.

Ini tidak lagi dianggap sebagai cara terbaik untuk melakukan sesuatu, tetapi saya dapat sepenuhnya memahami mengapa orang masih melakukannya, karena banyak sistem kontrol versi yang lebih lama masih digunakan yang menyulitkan jika tidak mustahil untuk melakukan hal lain dan masih mempertahankan pengetahuan tentang apa yang Anda lakukan. setiap rilis (atau lebih tepatnya, tidak ada cara untuk mengetahui apa rilis itu tanpa memeriksa tag pada setiap file jika Anda perlu kembali. Saya telah melihat lebih dari satu repositori di mana satu-satunya cara untuk mendapatkan kembali yang lama rilis adalah untuk mengambil dari repositori file zip dengan kode sumber dan binari untuk rilis itu).

jwenting
sumber
Menarik bahwa Anda harus mencatat bahwa binari dimasukkan. Diskusi terpisah yang kami miliki adalah apakah akan memasukkan binari yang dikompilasi dalam kontrol sumber. Saya bilang tidak, karena itu membuang-buang ruang dan berarti Anda bisa mengotori checkout Anda hanya dengan kompilasi. Mengapa file yang dikompilasi disertakan secara historis?
Tuan Jefferson
binari dimasukkan karena tidak mungkin untuk memulihkan sumber rilis dengan andal. Jadi biner disimpan sebagai gantinya kalau-kalau mereka akan diperlukan untuk mengembalikan server ke rilis yang lebih lama ... Kompromi berdasarkan keputusan buruk yang dibuat bertahun-tahun sebelumnya.
jwenting