Praktik terbaik SVN - bekerja dalam tim

Saya memulai dengan SVN. Saya tahu perintah dasar dan memahami prinsip dasarnya. Saya bertanya-tanya apakah ada yang punya tip atau praktik terbaik untuk bekerja dengan Subversion di lingkungan tim.

Saya dapat melihat manfaat menambahkan pesan yang cukup panjang saat melakukan kode, tetapi adakah hal lain yang harus saya ingat?

Terima kasih atas semua jawaban bagus - mereka telah banyak membantu.

Dorong komitmen yang sering. Rekan tim yang baru mengenal kontrol versi mungkin merasa mereka perlu menyimpan kode dari repositori sampai "berfungsi dengan benar". Ajari semua orang untuk berkomitmen sejak dini dan sering kali untuk menemukan masalah secepat mungkin. Alih-alih menahan kode 'sampai berfungsi, usulkan agar rekan tim Anda membuat cabang untuk fitur yang mungkin merusak trunk. Itu mengarah ke ...

Buat praktik percabangan dan penandaan. Selain cabang untuk fitur, dorong rekan tim Anda untuk menggunakan cabang untuk perbaikan bug besar. Tandai perbaikan bug utama di awal dan akhir pekerjaan. Pertahankan tag (dan mungkin bercabang) untuk rilis produksi / qa.

Tetapkan kebijakan untuk bagasi dan patuhi itu. Salah satu contohnya mungkin, "trunk harus selalu dibangun tanpa kesalahan." atau "trunk harus selalu lulus semua pengujian unit". Pekerjaan apa pun yang belum memenuhi standar batang harus dilakukan di cabang.

Jangan melakukan perubahan format dengan perubahan kode

Jika Anda ingin merestrukturisasi whitespace ( Control+ K+ D) file raksasa , bagus. Lakukan perubahan format secara terpisah dari perubahan logis yang sebenarnya. Hal yang sama berlaku jika Anda ingin memindahkan fungsi dalam file. Lakukan pemindahan secara terpisah dari pengeditan sebenarnya.

Salah satu konsep utama yang selalu saya pegang adalah melakukan perubahan kode terkait bersama-sama . Konsekuensinya adalah tidak melakukan perubahan kode yang tidak terkait dalam komit yang sama . Ini berarti jangan perbaiki 2 bug dalam satu komit (kecuali jika perbaikannya sama), dan jangan komit setengah perbaikan bug di masing-masing 2 komit. Juga, jika saya perlu menambahkan beberapa peningkatan baru atau sesuatu ke bagian sistem yang tidak terkait yang kemudian saya perlukan untuk beberapa pekerjaan lain, saya melakukan peningkatan secara terpisah (dan pertama). Idenya adalah bahwa setiap perubahan yang mungkin ingin dimiliki oleh siapa pun (atau memutar kembali sendiri) harus menjadi commit terpisah. Ini akan menghemat banyak sakit kepala ketika tiba waktunya untuk melakukan penggabungan atau mengembalikan fitur yang rusak.

Banyak yang telah disebutkan, dan ini beberapa lagi:

1. Jika Anda memiliki file yang tidak Anda inginkan dalam kontrol sumber (mis. Konfigurasi, file yang dikompilasi, dll.), Tambahkan file tersebut ke daftar abaikan . Dengan cara ini Anda melihat file apa pun yang Anda lupa tambahkan dengan selalu mengharapkan daftar file kosong yang ditampilkan sebagai tidak dikenal oleh SVN.

2. Tambahkan peristiwa pasca komit yang akan mengirim email ke milis pengembang Anda (atau yang spesifik untuk target ini) terkait dengan perubahan yang dilakukan dan idealnya tambalan untuknya.

3. Integrasikan dengan pelacak bug Anda sehingga referensi untuk komit muncul di bug / permintaan fitur dengan tautan ke diff. Pelacak bug seperti MantisBT mendukung ini.

4. Pertimbangkan untuk mengintegrasikan dengan integrasi berkelanjutan (mis. CruiseControl.NET ), NAnt untuk Build, dan NUnit / VS untuk pengujian unit. Dengan cara ini setelah pengguna check-in kode atau pada interval yang dijadwalkan, kode dikompilasi, pengujian unit dijalankan, dan pengembang mendapat umpan balik dari proses tersebut. Ini juga akan mengingatkan anggota tim lainnya jika repositori rusak (yaitu tidak dibangun).

Nah, dasar-dasarnya:

• Buat tag sebelum memulai QA pada suatu versi
• Buat tag sebelum perubahan berisiko (yaitu refaktor besar)
• Buat cabang untuk versi yang dirilis untuk membekukan kode.
• Pastikan orang-orang tahu untuk memperbarui sebelum mulai mengerjakan sepotong kode dan memperbarui sekali lagi sebelum melakukannya.
• SVN memungkinkan beberapa check out dari file yang sama oleh pengguna yang berbeda. Pastikan bahwa setiap orang menyelesaikan konflik yang mungkin terjadi.
• Jangan pernah menggunakan akun SVN yang sama untuk lebih dari satu pengguna. Hal-hal buruk bisa terjadi.

Jawaban yang orang berikan sangat bagus. Sebagian besar dirangkum dalam dokumen pengguna svn untuk praktik terbaik SVN .
Mengulang:

1. Siapkan struktur repositori Anda (Anda harus memiliki root proyek dengan trunk, cabang, dan tag di bawahnya)
2. Pilih pencabangan ulang kebijakan Anda (cabang pribadi, cabang per milestone / rilis / bug, dll) dan patuhi itu - Saya akan merekomendasikan lebih banyak percabangan daripada lebih sedikit, tetapi tidak perlu untuk cabang pribadi
3. Pilih kebijakan Anda menandai ulang - lebih banyak tag semakin baik, tetapi yang terpenting putuskan konvensi penamaan tag Anda
4. Pilih kebijakan Anda yang berkomitmen kembali ke bagasi - jaga agar bagasi tetap "bersih" mungkin, itu harus dapat dirilis kapan saja

Saya ingin meringkas praktik terbaik yang saya ikuti:

1. Jangan lakukan binari . Harus ada repositori terpisah untuk binari, seperti Nexus , Ivy atau Artifactory .

2. Harus ada struktur repositori . Secara pribadi saya menggunakan struktur repositori berikut:

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. Gunakan daftar jenis cabang tertentu . Daftar saya adalah sebagai berikut: eksperimental , pemeliharaan , versi , platform , rilis .
4. Gunakan jenis tag tertentu : PA(pra-alfa), A(alfa), B(beta), AR(rilis alfa), BR(rilis beta), RC(kandidat rilis), ST(stabil).
5. Minimalkan kebutuhan penggabungan . Harus ada aturan kapan penggabungan dimungkinkan / didorong dan kapan tidak.
6. Penomoran versi . Harus ada pendekatan penomoran versi yang mapan untuk dipatuhi. Biasanya ini dijelaskan dalam dokumen seperti Rencana Manajemen Konfigurasi Perangkat Lunak, ini adalah bagian dari dokumentasi proyek tingkat tinggi. Secara pribadi saya menggunakan pendekatan penomoran versi yang kompleks. Menurut pendekatan ini, versi memiliki pola berikut: Nxx (cabang pemeliharaan / dukungan), NMx (cabang rilis), NxK (build), NMK (rilis).
7. Berkomitmen sesering mungkin . Jika cenderung sulit (misalnya, ketika harus ada terlalu banyak perubahan yang harus dilakukan untuk mengimplementasikan fitur dan bahkan mengkompilasi kode), cabang eksperimental harus digunakan.
8. Batang harus berisi perkembangan terbaru . Misalnya, ketika ada pilihan di mana mengembangkan versi utama baru ( Nxx ) dari aplikasi, di trunk atau di cabang, keputusan harus selalu dibuat untuk trunk . Versi lama harus bercabang ke cabang pemeliharaan / dukungan . Ini mengasumsikan bahwa ada perbedaan yang jelas antara versi mayor dan spesifikasinya (arsitektur, kompatibilitas) muncul sedini mungkin .
9. Ketat kebijakan 'jangan hancurkan build' di cabang rilis . Sementara itu, tidak harus ketat untuk bagasi selama mungkin memiliki pengembangan eksperimental atau basis kode yang membutuhkan masalah penggabungan untuk diselesaikan.
10. Gunakan svn: externals . Ini akan memungkinkan untuk memodularisasi proyek Anda, menetapkan prosedur manajemen rilis transparan, membagi dan menaklukkan berbagai fungsi.
11. Gunakan pelacakan masalah . Anda akan dapat menunjukkan referensi masalah di dalam pesan komit.
12. Nonaktifkan pesan komit kosong . Itu bisa dilakukan dengan menggunakan kait pra-komit.
13. Tentukan cabang mana yang ingin Anda integrasikan terus-menerus . Misalnya saya lebih suka menggunakan integrasi berkelanjutan untuk cabang trunk , maintenance dan release .
14. Menetapkan kebijakan integrasi berkelanjutan untuk berbagai jenis cabang. Seperti yang saya tunjukkan sebelumnya, aturan paling ketat "jangan melanggar build" berlaku untuk melepaskan cabang, sementara cabang trunk dan maintenance terkadang rusak. Juga ada perbedaan antara daftar inspeksi yang dijalankan di cabang trunk / maintenance dan rilis .

Anda dapat menemukan garis besar praktik terbaik subversi saya dalam bentuk diagram yang menggambarkan prinsip-prinsip utama pendekatan manajemen konfigurasi perangkat lunak yang saya gunakan.

Satu hal yang menurut saya sangat berguna adalah svn: properti eksternal yang berarti Anda dapat mereferensikan direktori dari repositori lain ke dalam milik Anda. Ini memberikan cara yang sangat bagus untuk mengatur kode dan data Anda. Beberapa contohnya adalah:

1. Jika Anda memiliki repositori terpisah untuk kode modul / perpustakaan yang berbeda dan referensi dalam yang Anda gunakan. Ini berarti Anda dapat memiliki repositori meta untuk setiap yang dapat dieksekusi. Jika itu adalah executable kecil yang hanya menggunakan beberapa modul, Anda tidak perlu melakukan checkout keseluruhan. Efeknya adalah Anda mendapatkan nomor revisi SVN per modul.
2. Menambahkan data biner besar seperti versi pustaka yang dikompilasi ke repositori kode umumnya dianggap sebagai kebiasaan buruk, tetapi ini bisa sangat memudahkan. Jika Anda hanya menambahkan semua versi dari semua pustaka yang Anda gunakan ke repositori yang berbeda, Anda bisa mendapatkan yang terbaik dari dua dunia. Anda mereferensikan dalam versi pustaka yang Anda gunakan ke dalam repositori kode Anda. Saat memeriksa repositori kode Anda, Anda akan mendapatkan kode dan binari juga. Namun binari disimpan dalam repositori besar yang tidak perlu Anda backup seketat kode sumber Anda dan repositori kode sumber tetap kecil dan hanya berisi teks.

Gunakan integrasi dengan perangkat lunak pelacakan kutu Anda. Jika Anda menggunakan Bugzilla , Anda dapat mengaturnya sehingga jika komentar Anda dimulai dengan "Bug XXXX", komentar SVN Anda secara otomatis ditambahkan sebagai komentar untuk bug yang diberikan, termasuk tautan ke antarmuka web SVN Anda ke revisi tersebut.

Pelajari tentang alat dan konvensi pencabangan dan penggabungan SVN.

Cara terbaik untuk bekerja dengan anggota tim lainnya adalah dengan memecah pekerjaan menjadi fitur / perbaikan pengembangan lengkap, kemudian mengerjakan perubahan individu, masing-masing di cabang. Kemudian gabungkan perubahan kembali ke cabang / batang jalur utama saat selesai / siap / disetujui untuk digabungkan.

Dengan cara ini individu dapat bekerja menuju tujuan bersama (baik di cabang yang sama atau cabang yang terpisah) tanpa bertabrakan dengan perubahan lain.

Jarak tempuh Anda mungkin berbeda, dan ini mungkin berlebihan hanya untuk dua orang atau lebih.

Ini membuatnya lebih mudah jika Anda menggunakan alat bagus yang terintegrasi dengan baik dengan SVN. Ini memudahkan untuk melihat apa yang telah diubah dan kemudian mengkomit semua atau sebagian dari perubahan Anda dan untuk sering memperbarui copy pekerjaan Anda ke versi terbaru di SVN.

Saya merekomendasikan Tortoise SVN (Jika Anda menggunakan Windows) dan Visual SVN (jika Anda menggunakan VS).

Juga lihat apakah Anda dapat mengaturnya sehingga Anda mendapatkan email atau pemberitahuan serupa setiap kali ada perubahan (biasanya juga termasuk pesan komit dan daftar file yang diubah). Layanan seperti CVSDude menawarkan ini. Saya merasa terbantu untuk mengetahui bahwa pembaruan telah dibuat dan kemudian memiliki gagasan tentang apa yang terkandung dalam pembaruan itu sebelum memperbarui copy pekerjaan saya.

Selain kebijakan percabangan et al. (di mana satu ukuran tidak cocok untuk semua), Anda harus memiliki komitmen yang baik:

• Komit harus terkait dengan satu bagian pekerjaan jika memungkinkan; perbaikan bug, fitur baru- harus ada 'logika' untuk perubahan apa yang Anda lakukan
• Komit harus memiliki komentar deskriptif yang akan membantu Anda menemukannya dengan menelusuri riwayat repositori. Kebanyakan orang menyarankan untuk menulis satu kalimat di awal yang menggambarkan keseluruhan commit dan akun yang lebih detail di bawah
• Jika memungkinkan, Anda harus mengikat komit ke sistem pelacakan bug Anda jika memungkinkan. Trac, Redmine dkk. memungkinkan Anda membuat tautan dari bug ke komit dan sebaliknya, yang sangat berguna.

Aturan emas untuk kendali sumber: Check In Early, Check In Sering

Untuk tip bagaimana mengatur repositori Anda:

• Bagaimana Anda mengatur repositori kontrol versi Anda?
• Buku SVN Bab 5. Administrasi Repositori
• Tata letak repositori

Konsultasikan dengan tim Anda tentang perubahan mereka, atau setidaknya lihat perbedaannya dengan sangat hati-hati, sebelum memperbaiki konflik penggabungan. Minta mereka untuk meninjau sendiri kode yang digabungkan untuk memastikan penambahan mereka tidak hilang dalam penggabungan.

Satu hal yang saya lihat yang mengurangi komitmen yang rusak adalah memiliki skrip pra-komitmen yang baik. Misalnya, Anda dapat menjalankan pengujian unit apa pun sebelum perubahan dilakukan. Ini akan menyebabkan komitmen menjadi sedikit lambat, tetapi Anda menghemat waktu dengan menghindari menginjak kaki seseorang dan harus meminta maaf. Tentu saja ini menjadi jauh lebih sulit untuk dikelola ketika Anda memiliki tim pengembangan yang besar dan sangat sering berkomitmen.

Salah satu contoh integrasi dengan pelacak bug dan penegakan kebijakan komit dapat berupa skrip hook pra / pasca-komit Trac svn, yang dapat menolak komit jika pesan komit tidak merujuk tiket apa pun di pelacak bug dan menambahkan komentar ke yang ada. tiket berdasarkan isi pesan (mis. pesan komit mungkin berisi sesuatu seperti "Perbaikan # 1, # 2 dan # 8", di mana # 1, # 2, # 8 adalah nomor tiket).

Praktik terbaik untuk menggunakan SVN :

1. Ketika Anda pertama kali datang ke kantor dan membuka proyek Eclipse Anda , langkah pertama yang harus dilakukan adalah memperbarui proyek Anda.

2. Setelah mengambil pembaruan, mulailah pekerjaan Anda. Setelah Anda selesai membuat kode, periksa dengan benar, apakah aplikasi Anda berjalan dengan baik tanpa terkecuali. Setelah Anda yakin bahwa kode Anda berfungsi dengan baik, inilah waktunya untuk memasukkan kode.

Catatan: Saat memasukkan kode, jangan langsung berkomitmen. Lakukan sinkronisasi dengan server dan periksa apa saja yang perlu dilakukan. Catatan: Jangan lakukan seluruh folder satu kali. Karena Anda mungkin telah melakukan beberapa perubahan pada file untuk kebutuhan Anda atau Anda mungkin telah menghapus beberapa file di sistem lokal Anda. Tetapi pengaturannya berbeda di server. Jadi periksa file satu per satu dan lakukan kodenya.

3. Jangan lakukan / perbarui file konflik secara langsung.

4. Kapan harus mengganti dan memperbarui?

   Ketika Anda cukup yakin bahwa Anda tidak memerlukan perubahan lokal apa pun dan ingin memperbarui salinan server sepenuhnya. Catat bahwa sekali jika Anda menimpa dan memperbarui, Anda tidak akan mendapatkan perubahan lokal Anda.

   Catatan: Jangan simpan proyek tanpa memperbarui selama lebih dari satu hari. Juga jangan menyimpan kode tanpa melakukan selama beberapa hari.

5. Komunikasikan siapa yang semuanya bekerja dalam komponen yang sama dan diskusikan perubahan apa yang telah mereka buat setiap hari.

6. Jangan komit properti dan file konfigurasi kecuali ada beberapa alasan. Karena pengaturannya akan berbeda di server dan di cloud.

7. Jangan memasukkan folder target ke dalam SVN, hanya kode sumber dan folder sumber daya yang harus dipertahankan dalam repositori SVN.

8. Saat Anda kehilangan kode, jangan panik! Anda bisa mendapatkan kembali salinan sebelumnya dari riwayat SVN.

9. Jangan melakukan pembayaran proyek ke beberapa tempat di disk Anda. Lihat di satu lokasi dan kerjakan dengannya.

SVN sendiri merupakan awal yang baik dan beberapa poster lainnya telah menawarkan beberapa saran bagus tentang praktik terbaik.

Satu-satunya hal yang ingin saya tambahkan adalah Anda harus menghubungkan SVN dengan CruiseControl atau TeamCity untuk menjalankan proses Integrasi Berkelanjutan. Ini akan mengirimkan email build dan memberi tahu semua orang ketika seseorang merusak build.

Ini akan sangat memberi tahu sejak awal siapa yang mengikuti proses Anda dan siapa yang tidak. Mungkin menyebabkan beberapa gesekan tetapi tim Anda akan lebih baik dalam jangka panjang.

• Komentar yang tepat untuk setiap komit

• Jangan merusak bangunan (jalur utama)!

• Berkomitmen segera setelah unit logis berubah

• Hindari menggunakan Subversion sebagai alat cadangan

• Sedikit percabangan / penggabungan mungkin

.

Detail selengkapnya dapat ditemukan di praktik terbaik SVN .

Lakukan pekerjaan DEV di Cabang

1. Sering berkomitmen pada cabang Anda
2. Diskrit / Modular berkomitmen untuk cabang Anda ( lihat di sini )
3. Perbarui / Gabungkan dari trunk sesering mungkin. Jangan duduk di cabang Anda tanpa mendasarkan kembali

Batang Komunitas

1. Harus selalu membangun / bekerja
2. Satu masalah per komit ( sekali lagi lihat di sini ) Sebagian besar agar Anda atau orang lain dapat mundur satu per satu
3. Jangan menggabungkan perubahan refactoring / whitespace dengan perubahan logis. Rekan satu tim Anda akan kesulitan mengekstraksi apa yang sebenarnya Anda lakukan dari sebuah komitmen

Ingat bahwa semakin inkremental, modular, diskrit, dan ringkas Anda membuat komitmen, semakin mudah bagi Anda (atau kemungkinan orang lain) untuk:

• Mundur perubahan secara bertahap
• Sadari secara visual apa yang sebenarnya Anda lakukan tanpa memilah-milah banyak ruang kosong dan perubahan nama variabel.
• Pesan komit lebih berarti ketika rasio pekerjaan yang dilakukan terhadap panjang pesan lebih rendah.

Gunakan ini untuk template komentar:

[tugas / cerita xxx] [kecil / besar] [komentar] [komentar tindak lanjut] [URL ke bug]