Apakah ada yang salah dengan cara kami melakukan kontrol versi?

Saya bekerja dengan tim programmer sebagai analis bisnis. Kami baru saja merilis versi 2.0 dari produk kami dan sedang mengerjakan versi berikutnya yang akan dirilis dalam 3 bulan (ini adalah produk perangkat lunak internal). Sayangnya versi 2.0 memiliki beberapa masalah yang harus diperbaiki dan kami akan menerapkan perbaikan tersebut dalam beberapa minggu. Masalahnya adalah bahwa kami juga tidak ingin menerapkan perubahan yang masih dikerjakan dan tidak dijadwalkan untuk dirilis selama 3 bulan lagi.

Programmer memutuskan bahwa cara untuk mengelola ini adalah bahwa hanya kode untuk cacat akan diperiksa, dan kode untuk peningkatan baru akan disimpan pada mesin lokal pengembang sampai selesai. Saya harus mendapatkan build lokal dari mesin mereka untuk menguji karena jika mereka memeriksa kode dan kita harus mendorong patch lain untuk memperbaiki cacat, kita belum ingin memasukkan perangkat tambahan itu dulu. Ada juga masalah di mana file kode yang sama berisi perbaikan cacat dan perangkat tambahan, sehingga mereka harus menyalin file kode secara lokal, kemudian membuat perubahan untuk memperbaiki bug dan memeriksa yang ada di dalamnya, kemudian melanjutkan bekerja pada perangkat tambahan dengan mengambil salinan lokal yang mereka buat.

Tampaknya berbelit-belit - apakah ada cara yang lebih baik untuk menangani skenario seperti ini? Kami menggunakan Team Foundation Server dan Visual Studio 2010.

V2.0 seharusnya memiliki apa yang kami sebut sebagai 'steady-state branch' (kami menggunakan Perforce, bukan TFS) yang dibuat untuk itu setelah dirilis. Setiap perbaikan untuk v2 akan dilakukan ke cabang ini dan kemudian disebarkan kembali ke cabang pengembangan v3 sementara fitur v3 juga sedang dikerjakan, yaitu cacat pada v2 akan menghasilkan cacat juga pada v3.

Memiliki perubahan pada mesin pengembang untuk waktu yang lama kemungkinan akan menghasilkan mimpi buruk integrasi.

Yah ada beberapa cara untuk menangani masalah seperti itu, umumnya ditutupi oleh tag 'bercabang' , masing-masing dengan serangkaian manfaat dan kelemahannya sendiri.

Tetapi pendekatan yang dipilih oleh pengembang Anda ... wah saya akan mengutipnya secara lisan untuk memastikan bahwa saya tidak salah membaca ...

kode ... akan disimpan di mesin lokal pengembang sampai selesai ...

... cara seperti di atas mungkin satu-satunya yang benar-benar salah!

Apa yang membuatnya berbatasan dengan kriminal bagi saya adalah bahwa untuk TFS, ada Panduan Cabang Server Microsoft Team Foundation yang luar biasa, mudah dipahami - dokumen besar dan terperinci dengan rekomendasi strategi percabangan yang dirancang dan dijelaskan dengan cermat untuk semua jenis proyek yang berbeda ( versi HTML di sini ).

1. Pengembang Anda memiliki kesalahpahaman mendasar tentang cara menggunakan kontrol versi.
2. Jangan berdiskusi tentang perangkat lunak kontrol versi yang "benar". Ini bukan masalahnya.
3. Setiap perubahan kode membuat masalah semakin sulit untuk diperbaiki.
4. KETIKA Anda memutuskan untuk melakukan hal yang benar, Anda tidak dapat melanjutkan perubahan kode saat Anda memperbaiki berbagai hal. Anda HARUS menghentikan semua pengembangan dan mendapatkan kode ke kontrol versi.
5. Dev harus merasakan rasa sakit yang cukup untuk setidaknya duduk dan membicarakannya.
6. Semua perangkat lunak kontrol versi mendukung konsep dasar:
   • SEMUA kode masuk ke repositori kontrol versi.
   • Semua file kode memiliki nomor versi. Angka-angka ini bertambah secara otomatis ketika kode diperiksa ulang.
   • TAG menandai semua file kode dari (dan pada) versi tertentu. Jadi kita bisa TAG rilis perangkat lunak versi 1, misalnya.
   • CABANG adalah "berpaling" dari bagasi utama .
     • Setiap dan semua perubahan yang dilakukan pada cabang tidak mempengaruhi trunk.
     • Anda bisa menggabungkan perubahan cabang kembali ke bagasi utama di beberapa titik.
     • Dengan demikian, kita dapat bereksperimen tanpa takut mengacaukan "hal-hal baik."
7. Kalian harus mendapatkan kontrol versi "lompatan iman" seperti yang saya sebut. PERCAYA bahwa mengikuti aturan dasar akan membuat segalanya menjadi lurus. Kurang pengalaman membuat kita berpikir sebaliknya, percayalah.
8. Ini tutorial yang bagus. Itu umum dan cukup lengkap sehingga Anda tidak perlu menjelajahi banyak sumber lain
   • Kontrol Versi, Lebih Baik Dijelaskan

sunting

• Letakkan kontrol versi di komputer kantor Anda.
  • Anda dapat melakukan ini sekarang tanpa koordinasi tim
  • Bahkan dengan kontrol versi tim, saya sangat merekomendasikan ini
  • Jika tim Anda menggunakan Git atau Mercurial, Anda menggunakan repositori lokal yang independen. Begitulah cara kerja kontrol versi terdistribusi.
  • Anda dapat menggunakan perangkat lunak VC berbeda dari tim Anda. Tim kami menggunakan Subversion, saya menggunakan Mercurial secara lokal. Metafile perangkat lunak VC (".svn", ".mg", folder tersembunyi) tidak mengalami konflik.

Anda tidak bertindak sebagai repositori tim de-facto. Ini untuk mengelola pekerjaan Anda sendiri, upaya refactoring, dll. Dan menyerahkan diri Anda saat tim terus MEMUBAH basis kode.

akhiri edit

Apa yang Anda gambarkan adalah cara yang mengerikan untuk menggunakan kontrol versi. Seharusnya ada cabang yang dibuat untuk rilis 2.0, atau tag atau pengenal. Dengan begitu, modifikasi pada rilis itu dapat ditampung dan pengembangan lebih lanjut dapat terus terjadi.

Artikel ini dapat memberi Anda beberapa ide. Itu ditulis dengan gitpikiran, tetapi tidak ada alasan bahwa itu tidak dapat bekerja dengan mercurialbaik. Saya menyadari bahwa Anda tidak menggunakan keduanya, tetapi itu juga masalah yang harus Anda pertimbangkan untuk memperbaikinya.

Jawaban Cepat: Tim pengembang harus memiliki cabang Produksi terpisah untuk menjaga kode-basis V2.0 yang digunakan terpisah dari trunk Utama .

Semua perbaikan bug perlu dilakukan di cabang itu terlebih dahulu kemudian diuji dan disebarkan ke cabang lain, agar kode tetap sinkron .

Proyek Anda juga harus memiliki beberapa lingkungan for health developmentseperti Prod, Staging, QA, dan Dev (terkadang UAT). Lingkungan ini harus diatur sebelum pergi ke rilis Produksi.

Secara keseluruhan, siap untuk bug dan modifikasi adalah cara untuk mendukung aplikasi yang dirilis.

Karena TFS disebut sebagai kontrol versi, saya juga telah menyusun daftar artikel yang akan membantu untuk mengatur lingkungan pengembangan kesehatan:

• Menerapkan Team Foundation Server dengan tim pengembangan kecil
• Selamat datang di Platform Integrasi TFS!
• Pengembangan Tim dengan Panduan TFS
• Menyiapkan Lingkungan Pengembangan

Tidak, karena saat Anda menggunakan VCS, Anda tidak melakukan kontrol versi.

Konsep sentral untuk kontrol versi melacak perbedaan dari waktu ke waktu, Anda berencana untuk merekam beberapa perbedaan, tetapi saat ini sebagian besar perubahan Anda tidak direkam.

Seperti yang orang lain katakan, Anda harus menggunakan cabang. Setelah Anda memiliki pengaturan itu, Anda harus memeriksa semua perubahan fungsional (yaitu tidak setiap penekanan tombol, tetapi setiap kali Anda memperbaiki bug, menambahkan fitur, menghapus fitur, atau menyelesaikan perubahan sedemikian rupa sehingga masih dibuat dan berfungsi).

Saya seorang pengembang dan kami diberi kode cabang dan db yang berbeda untuk perbaikan versi saat ini dan yang berbeda untuk peningkatan dan untuk versi selanjutnya berturut-turut.

Setelah perbaikan kami selesai mereka digabungkan dengan produksi dan dikerahkan kami mendapatkan cabang baru yang baru untuk bekerja kembali ke perangkat tambahan.

Selain itu kami mengikuti praktik seperti jika saya memiliki 10 perbaikan untuk versi saya saat ini

Saya menulis sebagai

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

Demikian pula untuk perbaikan lainnya, saya hanya melakukan ini untuk setiap baris yang saya ubah atau tambahkan untuk perbaikan. Dan bandingkan dan komit saja. Demikian pula jika mereka melakukan paralel pada cabang yang sama yang bisa mereka gunakan

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+Fperintah dan ketik //Start Iteration 2, Fix No-1, Branch No-"ABC" untuk mencari di seluruh solusi banyak membantu untuk mengetahui lokasi yang tepat, file di mana kode diubah dan mengambil kode baru hanya bagian yang dapat digunakan untuk melakukan.