Apakah tidak biasa bagi perusahaan kecil (15 pengembang) untuk tidak menggunakan kontrol sumber / versi terkelola? [Tutup]

Ini sebenarnya bukan pertanyaan teknis, tetapi ada beberapa pertanyaan lain di sini tentang kontrol sumber dan praktik terbaik.

Perusahaan tempat saya bekerja (yang akan tetap anonim) menggunakan berbagi jaringan untuk meng-host kode sumber dan kode yang dirilis. Merupakan tanggung jawab pengembang atau manajer untuk memindahkan kode sumber secara manual ke folder yang benar tergantung pada apakah kode itu dirilis dan versi apa dan sebagainya. Kami memiliki berbagai spreadsheet yang tersebar di sekitar tempat kami merekam nama dan versi file dan apa yang berubah, dan beberapa tim juga menempatkan detail berbagai versi di bagian atas setiap file. Setiap tim (2-3 tim) tampaknya melakukan ini secara berbeda di dalam perusahaan. Seperti yang dapat Anda bayangkan, ini adalah kekacauan yang terorganisir - terorganisir, karena "orang yang tepat" tahu di mana barang-barang mereka, tetapi berantakan karena semuanya berbeda dan itu bergantung pada orang yang mengingat apa yang harus dilakukan pada satu waktu.

Saya telah mencoba untuk mendorong semacam kontrol sumber yang dikelola untuk sementara waktu, tetapi saya sepertinya tidak mendapatkan cukup dukungan untuk itu di dalam perusahaan. Argumen utama saya adalah:

• Kami saat ini rentan; pada titik mana pun seseorang bisa lupa untuk melakukan salah satu dari banyak tindakan rilis yang harus kita lakukan, yang bisa berarti seluruh versi tidak disimpan dengan benar. Mungkin perlu berjam-jam atau bahkan berhari-hari untuk menyatukan kembali satu versi jika perlu
• Kami sedang mengembangkan fitur baru bersama dengan perbaikan bug, dan sering kali harus menunda rilis satu atau yang lain karena beberapa pekerjaan belum selesai. Kami juga harus memaksa pelanggan untuk mengambil versi yang menyertakan fitur baru bahkan jika mereka hanya ingin memperbaiki bug, karena hanya ada satu versi yang sedang kami semua kerjakan
• Kami mengalami masalah dengan Visual Studio karena beberapa pengembang menggunakan proyek yang sama pada saat yang sama (bukan file yang sama, tetapi masih menyebabkan masalah)
• Hanya ada 15 pengembang, tetapi kita semua melakukan hal yang berbeda; bukankah lebih baik untuk memiliki pendekatan standar seluruh perusahaan yang kita semua harus ikuti?

Pertanyaan saya adalah:

1. Apakah normal jika sekelompok ukuran ini tidak memiliki kontrol sumber?
2. Sejauh ini saya hanya diberikan alasan yang tidak jelas karena tidak memiliki kendali sumber - alasan apa yang Anda sarankan dapat berlaku untuk tidak menerapkan kendali sumber, mengingat informasi di atas?
3. Apakah ada alasan lagi untuk kontrol sumber yang bisa saya tambahkan ke gudang senjata saya?

Saya meminta terutama untuk merasakan mengapa saya memiliki begitu banyak perlawanan, jadi tolong jawab dengan jujur.

Saya akan memberikan jawaban kepada orang yang saya percaya telah mengambil pendekatan yang paling seimbang dan telah menjawab ketiga pertanyaan.

Terima kasih sebelumnya

1. Ini mungkin tidak normal , tetapi seperti yang dikatakan Treb , itu mungkin tidak biasa

2. Seperti yang orang lain katakan, tidak ada alasan yang sah untuk tidak memiliki kendali sumber di perusahaan Anda. Jadi, Anda perlu mengidentifikasi dan menyerang alasan yang tidak valid :

   a) yang utama adalah status quo : "jika tidak rusak, jangan memperbaikinya". Ini sulit: Anda bisa mulai menunjukkan semua hal yang tidak berfungsi sebaik yang seharusnya (yang dapat dengan cepat membuat Anda dicap sebagai 'orang negatif'), atau Anda hanya menunggu sesuatu meledak (yang mungkin tidak akan pernah terjadi), atau Anda bisa menekankan semua hal yang bisa salah. Sayangnya orang-orang yang bertanggung jawab perusahaan kecil relatif tahan terhadap 'hal-hal yang bisa salah' sampai mereka benar-benar lakukan salah ...

   b) ketidaktahuan / ketakutan / ketidakpastian : "kita tidak benar-benar mengerti apa itu kontrol sumber; kita tidak tahu bagaimana menggunakannya; kita tidak tahu alat mana yang harus dipilih; itu akan membuat gaya kita kram" . Ini adalah salah satu alasan saya pasti tidak akan mengirim mereka ke sini! Ini mungkin urutan yang cukup tinggi untuk Anda sendiri, tetapi saya pikir untuk memaksimalkan peluang Anda, Anda perlu menghadirkan solusi 'turn-key', dan tidak terlalu banyak varian atau alternatif. Anda memerlukan gagasan yang jelas tentang: bagaimana Anda ingin menyesuaikan / mengubah proses kerja Anda untuk bekerja dengan alat yang diberikan; bagaimana / jika Anda berencana untuk kembali-port kode yang ada; seberapa cepat Anda berpikir Anda dapat 'melatih' pengguna dan membuatnya beroperasi; bagaimana Anda dapat mengelola periode transisi (jika ada); berapa besar kemungkinan 'biaya' (dalam jam, jika tidak dalam dolar).

   c) mungkin ada alasan lain (misalnya pengalaman buruk dengan VSS sebelumnya, atau setelah membaca 'cerita horor' tentang alat yang diduga terlalu rumit), tetapi Anda harus memukulnya secara terpisah ketika Anda menemukannya.

3. Ada banyak alasan untuk kontrol sumber yang diuraikan dalam jawaban lainnya. Saran saya adalah memilih 2 atau 3 utama yang benar - benar dapat membuat perbedaan bagi perusahaan Anda dan memoles mereka dan mempresentasikannya dalam rapat kepada sebanyak mungkin rekan kerja Anda. Cobalah untuk memprovokasi diskusi: bahkan jika Anda tidak segera meyakinkan mereka, Anda akan mendapatkan wawasan tentang apa poin yang mungkin muncul.

(Sudahkah Anda membaca / mendengar tentang Fungsi Perubahan ?)

Sama sekali tidak normal bagi kelompok yang ukurannya dapat bekerja tanpa kontrol sumber — ukuran kelompok programmer terbesar yang dapat bekerja secara efektif tanpa kontrol sumber kurang dari atau sama dengan satu. Benar- benar tidak dapat dimaafkan untuk bekerja tanpa kontrol versi untuk tim profesional dalam ukuran apa pun , dan mungkin saya tidak merasa kreatif, tetapi saya tidak dapat mengemukakan alasan mengapa Anda ingin melupakannya.

Kontrol versi hanyalah alat lain — yang sangat kuat, dan yang memberikan manfaat luar biasa relatif terhadap biaya minimalnya. Ini memberi Anda kekuatan untuk mengelola semua perubahan Anda dengan rapi, dengan semua jenis hal praktis lainnya seperti percabangan, penggabungan otomatis, penandaan, dan sebagainya. Jika Anda perlu membangun versi dari sekian versi yang lalu, Anda dapat memeriksa kode dari titik waktu dan hanya membangun tanpa harus melompat melalui lingkaran lain.

Lebih penting lagi, jika Anda perlu menulis perbaikan bug, Anda dapat menggabungkannya menjadi pembaruan tanpa harus menghadirkan fitur-fitur baru yang sedang Anda kerjakan — karena mereka ada di cabang lain, dan sejauh sisa pengembangan perlu dilakukan. khawatir, mereka belum ada.

Anda mengalami perlawanan karena Anda menantang budaya perusahaan. Akan butuh waktu bagi mereka untuk menyesuaikan, tidak peduli apa yang Anda katakan. Yang terbaik yang dapat Anda lakukan adalah terus mendorongnya, dan jika perusahaan benar-benar tidak mau bergerak, cari pekerjaan lain yang lebih cocok untuk level Anda sebagai pengembang.

Apakah normal jika sekelompok ukuran ini tidak memiliki kontrol sumber?

Dalam pengalaman saya, ini bukan norma, tetapi tidak sepenuhnya tidak biasa seperti jawaban lain di sini. Mayoritas perusahaan kecil memang menggunakan kontrol sumber, tetapi sejumlah besar tidak, sayangnya.

Sejauh ini saya hanya diberikan alasan yang tidak jelas karena tidak memiliki kendali sumber - alasan apa yang Anda sarankan dapat berlaku untuk tidak menerapkan kendali sumber, mengingat informasi di atas?

Lihat pertanyaan ini di SO untuk diskusi yang bagus. Jawaban yang diterima mengatakan:
"Tidak ada alasan bagus untuk tidak menggunakan kontrol versi. Tidak ada."

Apakah ada alasan lagi untuk kontrol sumber yang bisa saya tambahkan ke gudang senjata saya?

Konsensus di antara semua pengembang dan manajer proyek yang saya temui, dan tentu saja di sini di Programmer dan SO adalah bahwa kontrol sumber adalah suatu keharusan. Ini praktik terbaik yang diterima . Jika seseorang memutuskan untuk mengabaikannya, ia perlu memiliki beberapa argumen yang sangat kuat dan meyakinkan mengapa ini adalah keputusan yang tepat baginya (yaitu sedikit lebih dari 'kita tidak pernah membutuhkannya, jadi mengapa kita harus membutuhkannya di masa depan'). Argumen yang telah Anda sampaikan sejauh ini difokuskan pada isu-isu spesifik, mungkin Anda harus mencoba pendekatan yang lebih luas di sepanjang garis 'semua orang melakukannya, jadi mengapa kita tidak melakukannya juga?

Kontrol sumber baik untuk tim pengembang tunggal. Sistem kontrol sumber apa pun pada dasarnya adalah sistem kontrol versi yang melacak perubahan. Bayangkan satu pengembang, yang mungkin telah menghapus beberapa kode dan merasa bahwa kode itu sekarang diperlukan. Bisakah dia mendapatkan kode lama kembali?

Cukup gunakan alat yang membantu Anda. Ukurannya tidak masalah di mana-mana. Kualitas tidak masalah di mana-mana.

Sepertinya Anda sudah menggunakan sistem kontrol versi, tetapi tidak terlalu bagus. Orang-orang tampaknya sudah mengenali kontrol versi kebutuhan. Anda hanya perlu memperkenalkan mereka ke tingkat berikutnya - kontrol versi perangkat lunak.

Jika itu saya, saya akan memperkenalkan SCM sebagai versi perbaikan dari apa yang sudah mereka lakukan. Saya akan menekankan bagaimana menggunakan alat yang baik akan mengotomatisasi banyak pekerjaan yang sudah terjadi.

• Alih-alih merekam perubahan dalam spreadsheet, sistem SCM melacak tidak hanya apa yang berubah, tetapi siapa yang mengubahnya dan mengapa.

• Sebagai bonus, Anda dapat kembali ke titik mana pun dalam kehidupan kode dan melihat apa yang sebenarnya ada di sana.

• Alih-alih memiliki versi kode yang berbeda di folder yang berbeda dan perlu memindahkan / menggabungkan berbagai hal di antara folder untuk melakukan perubahan, Anda dapat menyimpan semuanya di tempat yang sama, dan (yang lebih penting), biarkan alat melakukan penggabungan.

Seperti yang telah dikatakan orang lain, saya akan mengharapkan resistensi, jadi saya akan membuat prototipe sistem dengan menggunakannya pada hal-hal yang saya lakukan.

(BTW, saya benar-benar meletakkan resume saya dan dokumen lain di bawah SVN. Kemudian lagi, saya telah memainkan peran Manajer Konfigurasi dan Integrasi beberapa kali.)

Sejauh ini saya hanya diberikan alasan yang tidak jelas karena tidak memiliki kendali sumber - alasan apa yang Anda sarankan dapat berlaku untuk tidak menerapkan kendali sumber, mengingat informasi di atas?

• Produk yang Anda kembangkan adalah sistem kontrol versi; manajer khawatir tentang mencegah produk yang ada dari mempengaruhi desain dan implementasi produk baru.

• Antara akhir pekan DASAR melompat dan berlari dengan lembu jantan, para manajer yang mencari kesenangan menikmati mengemudi untuk bekerja sambil bertanya-tanya apakah semuanya sudah masuk neraka.

• Menghindari pengambilalihan yang bermusuhan. Siapa yang ingin memperoleh pakaian pengembangan perangkat lunak yang dikelola dengan cara ini?

Apakah ada alasan lagi untuk kontrol sumber yang bisa saya tambahkan ke gudang senjata saya?

• Anda sudah melakukan kontrol versi, tetapi saat ini Anda melakukannya dengan cara yang paling tidak efisien, paling padat karya, paling rentan kesalahan yang bisa dibayangkan. Menggunakan VCS akan menghemat uang, menghemat waktu, dan meningkatkan kualitas.

• Menghemat ruang disk. Sebagian besar sistem kontrol versi hanya menyimpan delta di antara file. Saat ini, Anda menyimpan seluruh salinan dari setiap versi setiap file. (Mencadangkan semua salinan itu harus memakan banyak waktu dan ruang!)

• Beberapa pengembang dapat mengerjakan file yang sama pada saat yang sama dan merekonsiliasi perbedaan tanpa terlalu banyak kesulitan. Menggabungkan perubahan tentu saja mungkin tanpa VCS, tetapi hampir tidak mungkin untuk melacak siapa yang mengubah apa, kapan, dan mengapa dalam kasus itu.

• Memberi kebebasan pengembang untuk mencoba ide baru dengan mengetahui bahwa mereka dapat memulihkan versi apa pun kapan saja.

• Proses yang lebih baik membuatnya lebih mudah untuk merekrut dan mempertahankan pengembang yang berbakat.

Apakah normal jika sekelompok ukuran ini tidak memiliki kontrol sumber?

Jelas tidak. Ketika saya mulai di perusahaan saya saat ini, ada satu orang yang Anda harus mengirim kode Anda berubah, dan dia akan menggabungkannya. Saya bisa meyakinkan semua orang dalam beberapa hari untuk menggunakan SVN.

Sejauh ini saya hanya diberikan alasan yang tidak jelas karena tidak memiliki kendali sumber - alasan apa yang Anda sarankan dapat berlaku untuk tidak menerapkan kendali sumber, mengingat informasi di atas?

Saya pikir alasan Anda hanya mendengar alasan yang tidak jelas adalah karena tidak ada alasan yang sah untuk tidak menggunakan kontrol versi.

Apakah ada alasan lagi untuk kontrol sumber yang bisa saya tambahkan ke gudang senjata saya?

Ya, ada banyak alasan.

1. Bercabang memberi Anda kemungkinan untuk mengembangkan fungsionalitas baru tanpa mengganggu perkembangan lainnya.
2. Setiap komit memberi Anda informasi tentang apa yang sebenarnya telah diubah, siapa yang melakukan perubahan itu, dan kapan perubahan itu dilakukan.
3. Anda dapat dengan mudah melakukan perbaikan bug, dan menyebarkannya ke pelanggan, dan meninggalkan fungsionalitas baru yang belum selesai.
4. Anda dapat mempertahankan versi yang berbeda, jika pelanggan takut pergi ke versi yang lebih baru.
5. Anda dapat mengerjakan proyek yang sama (bahkan file sumber yang sama!) Dengan mudah.
6. Anda dapat dengan mudah mengembalikan kesalahan, dengan mempertahankan perubahan setelah kesalahan yang dilakukan.

Beberapa orang kesulitan menyadari betapa buruknya status quo sampai mereka melihat sesuatu yang lebih baik untuk diri mereka sendiri. Yang Anda butuhkan adalah demo yang bagus . Perlihatkan beberapa contoh tugas aktual yang dapat ditingkatkan. "Ini membutuhkan waktu 4 jam untuk melacak dengan sistem kami saat ini, tetapi perintah kendali sumber yang satu ini langsung memberi tahu saya."

Tidak menggunakan kontrol sumber meminta masalah, bahkan untuk pengembang solo. Fakta sederhana bahwa Anda dapat mengedit dengan kejam tanpa risiko kehilangan apa pun merupakan upaya pembelajaran dalam beberapa minggu atau hari.

Yang mengatakan, jika Anda tidak dapat meyakinkan manajer Anda untuk memperkenalkan kontrol sumber, bantulah diri Anda sendiri dan setidaknya gunakan sesuatu seperti git atau lincah secara lokal - jika ada masalah yang meledak karena kurangnya kontrol sumber, setidaknya Anda tidak akan menjadi yang terbaik. orang yang melakukannya.

Perusahaan saya menggunakan GIT untuk kontrol versi. Perusahaan ini adalah satu pengembang, satu CEO, satu penjaga keamanan, satu wanita pembersih dan satu resepresionis. Mereka semua adalah aku. Kontrol versi sumber adalah HARUS setiap saat.

Saya mengerjakan banyak proyek sendiri dan saya masih menggunakan kontrol versi. Ukurannya tidak masalah. Selalu membantu untuk memiliki kontrol versi.

Ada alasan mengapa ini adalah # 1 di The Joel Test: http://www.joelonsoftware.com/articles/fog000000000043.html

Juga, itu memungkinkan # 2 dan # 3 dalam daftar menjadi mungkin.

Kami berada di posisi yang sama dengan tim 6 orang beberapa tahun yang lalu. Salah satu pengembang mengambil langkah menginstal SVN pada server dev di mana folder bersama itu dan baru mulai menggunakannya.

Semua orang mengikutinya, dan tidak lama sebelum kami menerapkan CI ( CruiseControl ) dan merevolusi proses pembuatan dan pelepasan kami untuk menyertakan otomatisasi dan pemeriksaan kualitas.

WTF ?! Ini mungkin pertanyaan paling konyol yang pernah saya lihat. Anda perlu mencari pekerjaan baru. 15 pengembang ?! Anda pikir itu tim kecil? Ini gila. Manajer harus segera diberhentikan. Jujur, saya akan mengalami mimpi buruk setelah membaca pertanyaan ini. Tolong beritahu kami produk yang Anda jual sehingga kita semua tahu untuk tidak membelinya! Saya tidak tahu apa yang lebih menakutkan, pertanyaan ini, atau jawaban yang mengatakan ini tidak biasa!

Saya tidak bisa membayangkan bagaimana 15 pengembang dapat bekerja tanpa kontrol sumber. Namun, dari:

(...) menggunakan jaringan berbagi untuk meng-host kode sumbernya (...)

Saya berasumsi Anda telah membuat kontrol versi orang miskin Anda sendiri seperti VSS (juga didasarkan pada folder bersama). Berisiko dan tidak efisien.

Jelaskan kepada bos Anda betapa buruknya, berinvestasilah dalam beberapa pelatihan SVN atau GIT 2 hari, dan mulailah menggunakan sistem kontrol versi nyata saat Anda masih memiliki kode Anda dalam kondisi yang wajar.

Jika saya tidak melakukan beberapa kali sehari, atau setidaknya sebelum saya meninggalkan rumah, saya merasa .. ada yang hilang, ada yang salah.

Saya pernah bekerja di sebuah perusahaan dengan hanya 2 pengembang (saya + admin berambut panjang), pada tahun 1998. Bahkan saat itu kami menggunakan svn. Sangat nyaman.

Beberapa kali dalam karir saya, saya kehilangan hari kerja karena saya melakukan sesuatu seperti mv bukannya cp dan kemudian rm-rf. Membuatku menangis dan berkeliaran di jalanan kota dengan putus asa.

Saya bekerja di 5 perusahaan selama 13 tahun saya berada di SE, berkunjung ke beberapa konferensi, dan tidak pernah menemukan perusahaan yang tidak menggunakan kontrol versi.

Namun, perusahaan desain interior favorit saya, 20 karyawan, menggunakan papan tulis untuk kolaborasi manajemen + proyek. Mereka tahu itu salah, tetapi sepertinya mereka tidak punya waktu untuk memutakhirkan. Entah bagaimana itu berhasil. Jangan tanya saya bagaimana.

Jadilah pemimpin. Menjadi seorang pemimpin berarti melakukan apa yang benar; secara proaktif memecahkan masalah. Kepemimpinan tidak melakukan apa-apa karena tidak ada cukup konsensus. Dan seorang pemimpin yang baik belajar untuk mengenali situasi ketika seseorang harus membangun konsensus dan kapan melakukannya. Ini jelas merupakan situasi yang harus dikerjakan. Kurangnya kontrol kode AKAN meledak di wajah Anda cepat atau lambat.

Pemimpin sering tidak berada dalam posisi manajemen resmi. Orang akan mengikuti pemimpin yang baik dan tegas terlepas dari jabatannya.

Jika upaya tegas Anda terhempas, terutama jika itu dari manajemen maka itu pertanda jelas bagi Anda untuk keluar dari sana. Ini hambatan pada pengembangan profesional Anda; dan Pengembang yang kompeten dan manajemen yang tidak kompeten tidak bergaul, dan yang tidak kompeten dengan kekuasaan akan mengacaukan Anda.

OK, kilas baliknya sampai ke saya. Tanda tangan. Semoga berhasil.

1. Dapatkan stopwatch,
   • Hitung waktu yang Anda habiskan di spreadsheet hanya untuk menyinkronkan versi
   • Hitung waktu yang Anda habiskan untuk memperbaiki versi yang rusak
   • hitung berapa kali orang berteriak di lorong " aku mengedit main.c !, hanya untuk memastikan tidak ada orang lain yang sekarang!" .
   • hitung jumlah keluhan yang Anda dapatkan dari pelanggan karena perbaikan bug mereka berisi perubahan lain
   • hitung waktu tunda rilis hanya karena Anda tidak dapat menyinkronkan versi
2. Buat powerpoint dengan data ini, bandingkan dengan cara kerja vcs.
3. Tampilkan manajemen

Ini hanya kecelakaan yang menunggu untuk terjadi. Anda tidak memiliki riwayat kode, dan dalam satu gerakan, salah satu pengembang Anda dapat menghapus pekerjaan berbulan-bulan. Sebagai perusahaan kecil Anda tidak mampu membayar kemunduran semacam ini.

Anda juga sangat terbuka pada drive share itu. Bahkan dengan cadangan yang bagus, berapa lama Anda mampu untuk tidak bekerja. 1 jam, 1 hari, 1 minggu. Berapa lama untuk mendapatkan server baru di tempat, memulihkan dari cadangan dll. Sekali lagi sebagai perusahaan kecil Anda mungkin tidak memiliki perangkat keras tambahan pada siaga dan mungkin tidak dapat dengan mudah menjatuhkan uang untuk mendapatkan pengiriman yang dipercepat dll.

Pikirkan juga tentang penyimpanan di luar kantor. Banjir atau kebakaran bukanlah hal yang aneh. Apa yang akan terjadi jika ada kebakaran di gedung setelah jam. Berapa bulan kerja akan hilang. Repositori kode terkelola seperti github akan sangat berharga untuk ini. Bahkan menggunakan server SVN sederhana pada layanan yang dihosting akan menjadi langkah maju dalam bidang ini.

LordScree, saya dalam kesulitan yang hampir sama dengan Anda, tim langsung saya adalah sekitar 15 pengembang. Saya tidak percaya (hampir ngeri) bahwa kontrol sumber tidak digunakan. Tanggapan awal saya untuk "kita harus menggunakan kontrol sumber" adalah "kita tidak punya waktu untuk mengimplementasikan". Bagi saya, seperti memakai pakaian dalam, kontrol sumber bukan opsional. Setelah beberapa bulan, saya juga memiliki persetujuan untuk mengimplementasikan TFS, dipilih oleh organisasi karena ini adalah MS dan dilengkapi dengan uji coba 90 hari. Intinya, sangat sulit untuk meyakinkan sebuah organisasi tentang perlunya kontrol sumber ketika mereka telah berjuang tanpa itu. Saya memberi tahu pengembang bahwa kapan pun Anda menemukan diri Anda mencadangkan file, terutama dengan tanggal di nama file atau direktori yang dicadangkan, adalah contoh ketika Anda meletakkan sesuatu di kontrol sumber. Saya tidak Saya tidak punya jawaban yang cemerlang untuk Anda, tetapi saya yakin ini tidak biasa. Saya sedang berjuang dalam pertempuran yang sama dan akan membuat Anda tetap pada kemajuan. Dan, semoga akan ada kemajuan kalau aku mencari di tempat lain karena aku tidak bisa bekerja dalam kekacauan!

kami memiliki 3 anggota staf pengembangan dan menggunakan kontrol sumber. Pada proyek pribadi saya, saya punya satu pengembang dan saya menggunakan kontrol sumber. Ini tidak hanya berguna untuk manajemen tim, ini berguna untuk dapat melakukan pekerjaan eksperimental tanpa takut Anda lakukan untuk menghancurkan sesuatu.

Cara termudah untuk meyakinkan manajemen? Ada sedikit risiko untuk keseluruhan produk, dan itu akan meningkatkan produktivitas pengembang dalam jangka panjang. Keduanya benar juga, dan keduanya menarik bagi para manajer.

Ini sama sekali bukan skenario normal dan saya pikir Anda harus berjuang keras untuk mendapatkan pengaturan ini di perusahaan Anda. Ini memiliki manfaat yang jauh dan tidak ada gunanya mewujudkan hal yang sama ketika Anda mendekati hari kiamat dan itu bukan situasi yang termasuk di dalamnya. Jika tidak rusak jangan memperbaikinya.

Alasan apa pun untuk tidak menerapkannya bisa jadi hanya alasan untuk pekerjaan yang buruk atau kesalahan besar yang menunggu untuk terjadi.

Beri tahu mereka betapa hebatnya menemukan aplikasi itu pada 1 Jan tahun ini

bagaimana kalau fungsi ini ditambahkan pada bulan Maret saya pikir kita perlu memperluas lebih lanjut tentang ini.

Wow bug ini 154256 telah diperbaiki dalam komit ini.

saya dapat membuka aplikasi dan mengirimkan penyebaran tidak masalah, Anda dapat terus bekerja.

Ini bisa terus-menerus ... (jangan lupa untuk menambahkan komentar tentang commit di lain waktu yang akan muncul sebagai pertanyaan lain)

Saya menggunakan kontrol versi untuk proyek satu orang dan proyek kerja saya, di mana kami memiliki lebih dari 30-40 orang yang mengerjakan kode yang sama sekaligus. Kontrol versi memiliki keunggulan organisasional, tetapi kemampuan untuk mengembalikan file dan menyimpan perubahan benar-benar dapat menghilangkan sakit kepala dari mengelola kode ... dan pada akhirnya itu adalah skenario terbaik untuk seorang programmer, sehingga mereka hanya dapat fokus pada pengkodean.

Alasan untuk mendukung tidak menggunakan kontrol versi cukup terbatas. Yang bisa saya pikirkan hanyalah aspek teknis dari banyak hal.

• Ada terlalu banyak kurva belajar untuk mengubah alur kerja seluruh staf Anda untuk memasukkan sistem versi menjadi efektif biaya.
• Manajer proyek Anda tidak merasa bahwa akan bermanfaat untuk memperkenalkan overhead ke dalam alur kerja mengelola dan memelihara repositori. (Terutama masalah dengan Sistem Versi yang lebih lama)

Ada banyak alasan untuk menggunakan sistem versi. Paling tidak berhenti bergerak di sekitar. Bekerja dengan tambalan. Sistem versi dapat melakukan persis apa yang Anda katakan Anda lakukan.

• Anda dapat bekerja pada versi berikutnya pada saat yang sama Anda melakukan perbaikan bug dan melepaskannya secara terpisah.
• Alih-alih memindahkan file dari satu lokasi ke lokasi lain untuk mengerjakannya, Anda dapat membuat cabang dan menggabungkannya ke master setelah selesai.
• Setiap pengembang dapat memiliki salinan kode sumbernya sendiri untuk mencegah masalah dengan proyek yang sama terbuka di beberapa mesin.
• Kecelakaan terjadi, jika kode menjadi sangat rusak semua yang perlu Anda lakukan kembalikan ke nomor revisi kerja terakhir.
• Kontrol versi berfungsi dengan baik dipasangkan dengan pelacak bug dan sistem integrasi berkelanjutan.

Saya pribadi sebagai tim satu orang menggunakan versi, pelacakan bug, integrasi berkelanjutan, tinjauan kode, pengecekan konsistensi kode, pengujian unit, tes selenium, analisis kode sumber, dan mungkin ada lebih banyak lagi yang saya lupa. Saya akui, ada sedikit kurva belajar. Ada juga tradeoff waktu administrasi tambahan yang diperlukan untuk langkah-langkah tambahan yang Anda otomatisasi. Dalam pengalaman saya, upaya yang dihemat lebih besar daripada waktu administrasi tambahan.

Pada pekerjaan serius pertama saya pada tahun 1990 saya adalah satu-satunya pengembang yang bekerja di departemen saya dan tidak tahu untuk menggunakan kontrol sumber.

Tidak lama kemudian saya belajar, sejak saat itu saya belum pernah melihat proyek yang tidak menjadikannya salah satu hal pertama yang mereka buat.

Saya hampir kehilangan semua pekerjaan saya di pekerjaan itu karena saya menghapus folder pada level yang salah. Untungnya saya telah membawa pulang salinan pada disket 5 "minggu sebelumnya dan dapat membuat kembali minggu bekerja dalam beberapa hari yang panjang.

Jadi saya kira saya akan menganggap itu dapat diterima jika itu adalah proyek pertama untuk semua orang di tim dan tidak ada yang tahu lebih baik, tetapi jika bahkan satu orang benar-benar dapat menjelaskan manfaat dan tim masih tidak mendengarkan saya akan mengkategorikan ulang saya pendapat kelompok dari "naif" hingga "sangat tidak kompeten" (Perlawanan untuk menggunakan alat dengan manfaat yang ditunjukkan secara luas seperti itu hampir bersifat kriminal - seperti jika tim Anda tidak mempercayai "Penyusun" dan bersikeras melakukan segala sesuatu dalam bahasa assembly ).

Saya telah menemukan banyak hal ini ... di perusahaan teknik / elektronik kecil di mana mereka melakukan banyak perangkat lunak / perangkat keras tertanam.

Di tempat-tempat ini SCM bukan bagian dari budaya rekayasa elektronik. Mereka biasanya memiliki satu insinyur per proyek, yang hanya perlu mencadangkan rilis terbaru.

Jadi percabangan / penggabungan dan bahkan berbagi kode dianggap tidak dapat diselesaikan. Juga, perusahaan-perusahaan ini mungkin ISO9000, jadi prosesnya, albiet aneh, mungkin didokumentasikan.

Bagaimanapun, saya / pengembang lain baru saja mulai menggunakan SCM secara pribadi.

Di tempat saya bekerja, kami memiliki masalah yang sama. Saat ini saya mencoba untuk menggeser kontrol sumber di "di bawah radar" untuk mengatasi masalah yang sama yang Anda miliki. Saya menggunakan fosil untuk proyek yang saya kembangkan secara pribadi.

Saya baru-baru ini menyiapkan server fosil di LAN perusahaan, jadi sekarang ini lebih nyaman. Saya berharap bahwa ketika saya menunjukkan kegunaan pada beberapa proyek kecil yang saya akan merusak resistensi dan menjauhkan kita dari status quo folder jaringan.

Alasan terbesar yang saya dengar untuk tidak menggunakan fosil, atau VCS lainnya adalah:

1. Banyak "programmer" adalah skrip kiddies, dan tidak akan mengerti cara menggunakannya
2. Mereka yang bisa belajar, menganggapnya sebagai gangguan untuk digunakan
3. Orang-orang ini adalah penjaga lama, nyaman dengan folder jaringan, jadi semua orang seharusnya
4. Tidak ada yang punya waktu untuk mengaturnya dengan benar, atau belajar cara menggunakannya
5. Meskipun fitur-fiturnya mungkin luar biasa, tidak ada yang diperlukan

Seperti yang Anda lihat, saya mencoba menyiasatinya dengan menunjukkan bahwa itu mudah digunakan, sudah diatur, mudah dipelajari, dan fitur-fiturnya sangat sepadan.

Akhirnya, bahkan jika Anda tidak membuat mereka menggunakan kontrol sumber, semuanya ada di pohon jaringan. Fosil dapat membuat versi semua yang ada di seluruh pohon, dan Anda dapat mengaturnya agar berjalan setiap kali terjadi perubahan file, atau setidaknya setiap jam. Saya telah melakukan itu untuk beberapa proyek kami yang "tidak memerlukan kontrol sumber" dan akhirnya memungkinkan saya untuk kembali ke versi yang baik ketika ada masalah.

Lakukan dengan benar, dan mereka bahkan tidak akan tahu Anda telah melakukannya. Maka Anda bisa menjadi pahlawan yang mengembalikan bangunan yang rusak, dan menunjukkan betapa berguna alat Anda.

Sekarang alat DVCS seperti Git dan Mercurial telah tersedia, dan sangat mudah diatur dan digunakan, benar-benar tidak ada alasan untuk bahkan tim 1 (!) Untuk tidak menggunakan kontrol sumber. Ini bukan tentang ukuran tim, ini tentang memiliki riwayat komentar tentang perubahan Anda dan kemampuan untuk mendukung alur kerja seperti memperbaiki masalah produksi saat mengerjakan rilis baru, dan melacak status kode sumber untuk versi yang berbeda.

Jika saya ditawari pekerjaan di tim yang mencapai ukuran itu, dan tidak ada pengembang yang menyarankan menggunakan VCS, atau jika "manajemen" mencegah mereka, saya akan menolaknya. Ini bukan cara kerja yang bisa diterima akhir-akhir ini.

Anda harus segera mendapatkan kontrol versi GIT. Anda dapat menggunakannya bahkan dari Google Code Project Hosting. Ketika orang lain melihat Anda melakukan perubahan hanya dalam satu klik saat mereka secara manual menyalin sesuatu, mungkin mereka berubah pikiran tentang hal itu.

Wow Hanya wow. Meskipun saya tidak berpikir itu adalah cara terbaik untuk menangani kontrol kode, itu tidak sepenuhnya aneh. Saya bekerja di sebuah perusahaan dengan 6 pengembang dan tidak ada kontrol sumber yang digunakan, mereka semacam memiliki cara internal mereka sendiri dalam mengelola file, manajer rilis dan yang lainnya akan mengawasi semua perubahan. Sebenarnya mantra adalah bahwa fungsionalitas baru dapat ditambahkan ke dalam proyek selama beberapa jenis saklar melilit fungsionalitas.

Misalnya kami sedang mengerjakan jejaring sosial kelas atas yang ditulis dalam PHP dan klien menginginkan fungsionalitas untuk dapat berlangganan profil pengguna. Pada dasarnya fungsionalitas dibungkus dengan cek seperti ini jika (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {lalu jalankan kode}

Tempat saya bekerja juga tidak pernah memiliki lebih dari satu pengembang pada suatu waktu mengerjakan file tertentu, sebagian besar semuanya modular sehingga dalam hal itu tidak perlu untuk kontrol sumber. Namun, saya percaya keuntungan dari kontrol sumber jauh lebih besar daripada kerugian karena tidak memilikinya dalam banyak kasus.

Fakta bahwa perusahaan Anda beralih ke spreadsheet yang mendokumentasikan perubahan file dan apa yang diubah ketika sesuatu seperti Git atau Subversion dapat mengatasinya bagi Anda benar-benar konyol.

Tampaknya Anda yakin, tetapi seseorang dalam organisasi tidak memberdayakan Anda untuk melakukannya. Seperti yang dapat Anda baca dari komentar lain, Anda harus melakukannya.

Anda dapat menemukan beberapa informasi di sini: http://www.internetcontact.be/scm/?page_id=358

Faktor yang paling penting adalah bahwa pelanggan Anda dipaksa ke cabang 'tidak stabil' terakhir dan jika kontrak Anda dengan pelanggan Anda membuat Anda bertanggung jawab untuk menggunakan versi tidak stabil, perusahaan Anda kehilangan uang. Anda harus benar-benar fokus pada stabilitas rilis di sini. Ini adalah alasan utama untuk kontrol sumber, dan sepertinya kegagalan utama Anda. Yang lain tidak akan ditingkatkan sebanyak itu dengan menggunakan kontrol sumber karena Anda sudah memiliki sistem alternatif.