Pertanyaan Cara yang lebih baik untuk menangani percabangan dan penggabungan?


Kami menjalankan toko pengembangan web dengan ~ 20 pengembang bekerja di ~ 30 situs yang berbeda pada waktu tertentu dan kami tenggelam dalam jumlah yang luar biasa waktu untuk mengelola repositori subversi kami - harus ada cara yang lebih baik.

Situs klien kami umumnya memiliki 3 lingkungan penyebaran terpisah: pengembangan (trunk), pementasan (cabang), dan produksi (cabang).

Fitur baru ditinjau secara internal pada pengembangan, kemudian digabungkan dengan pementasan untuk peninjauan dan persetujuan klien, dan akhirnya digabungkan ke produksi.

Alur kerja kami saat ini: Setiap pengembang yang mengerjakan fitur baru utama untuk klien akan membuat cabang dari trunk, bekerja pada fitur mereka, sambil memperbarui secara teratur dari trunk, dan kemudian menggabungkan perubahan kembali ke trunk (pengembangan) untuk tinjauan internal. Pengembang yang mengerjakan perubahan kecil atau perbaikan, akan membuatnya langsung di bagasi.

Setelah tanda internal, perubahan kemudian digabungkan ke pementasan. Jika perubahan perlu dilakukan, mereka akan sering dibuat di bagasi, dan kemudian digabungkan ke pementasan. Setelah disetujui, perubahan akan digabungkan dengan produksi dan kemudian diterapkan.

Fitur-fitur baru tidak ditinjau secara berurutan secara internal atau oleh klien, dan semuanya menjadi agak berantakan. Sepertinya kita menggunakan proses yang salah - harus ada cara yang lebih baik untuk melakukan ini. Kami sangat tertarik untuk mempelajari cara memanfaatkan kontrol versi lebih baik, tetapi kami tidak memiliki pengalaman untuk memulai prosesnya.

Apa praktik terbaik untuk skenario ini? Selain forum ini, kami tertarik untuk melibatkan konsultan yang berpengalaman, yang dapat membantu kami meningkatkan proses kami.

Terima kasih!


5
2017-08-02 20:52


asal


Jawaban:


kupikir bercabang menurut fitur (atau tim) akan lebih baik daripada bercabang oleh pengembang. Fitur ini dapat diuji dan dipratinjau sebelum menggabungkan melalui Pengembangan (Trunk) dan ke dalam cabang Staging.

Tim saya memiliki struktur "Cabang dengan Kualitas / Lingkungan" serupa yang saya habiskan beberapa bulan untuk meneliti cara terbaik mengonversi sehingga pengembang bekerja sama dan kami dapat mengurangi pajak penggabungan. Saya akan menyarankan yang berikut:

  • Development (Trunk / Main / Root branch)
    • (FeatureName1 [Version]) - menggantikan cabang untuk setiap Pengembang.
    • Staging (jika Anda menyimpan semua rilis dalam satu cabang)
    • Produksi
    • (ReleaseName) (MajorVersion) Staging - Preferensi saya untuk mengisolasi rilis yang berbeda meskipun dilepaskan ke lingkungan yang sama
    • (ReleaseName) (Versi) Produksi

Perbaikan pementasan dilakukan langsung di cabang Staging (atau cabang anak pendek Staging jika QA dan / atau risiko isolasi mandat), kemudian bergabung kembali ke Pengembangan (Trunk) segera setelah perbaikan diterima. PERINGATAN: Perhatikan setiap penggabungan dari Pengembangan sementara perbaikan Staging sedang berlangsung.

Dari Perspektif QA, saya sangat memilih bentuk akhir yang teruji dan terbukti menjadi binari / file identik yang dirilis untuk produksi. Satu-satunya perubahan adalah file konfigurasi (dengan pengaturan konfigurasi yang berbeda yang dicentang masuk ke repositori). Ini berarti saya biasanya membuat versi final di "Staging" dan cabang "Produksi" atau ReleaseVersion adalah arsip hanya-baca yang tidak dibuat oleh siapa pun. (Label atau tag dapat digunakan sebagai pengganti cabang penyimpanan ini jika label tersebut tidak dapat diubah ... yang tidak berlaku untuk TFS 2010 :-(.)

Lihat diagram keren di Visual Studio TFS Percabangan dan Panduan Penggabungan  Artikel MSDN mulai Februari 2011. Untuk memperbesar ini, lihat Bercabang untuk Scrum dan Tim Fitur Paralel bekerja pada beberapa rilis dalam pengembangan. Rilis bulanan untuk produksi.. Keduanya datang dengan beberapa diagram yang sangat bagus yang berlaku untuk sistem kontrol versi apa pun.

Saya juga menyarankan untuk melihat Panduan Cabang TFS dan forum diskusi di lokasi yang sama ini untuk tambahan pola dan panduan yang baik. (Metodologi percabangan sebagian besar tidak bergantung pada perkakas dengan pengecualian saat menghindari kelemahan alat.)

Saya melihat setidaknya satu kekurangan mendasar dalam proses percabangan awal:

Setelah tanda internal, perubahan kemudian digabungkan ke pementasan. Jika perubahan perlu dilakukan, mereka akan sering dibuat di bagasi, dan kemudian digabungkan ke pementasan.

Jika perubahan pada Staging dibuat dalam Development dan kemudian digabungkan ke Staging lagi, maka Anda baru saja mewarisi semua perubahan lain yang dibuat ke cabang Development sejak penggabungan terakhir ke Staging. ATAU jika Anda memilih cherry-pick (menyisakan semua perubahan lain untuk digabungkan nanti). Alat SCM menjadi lebih baik dalam menangani skenario ini, tetapi gabungan ceri masih memperkenalkan risiko yang signifikan.

FYI: Pola awalnya digambarkan mirip dengan "Cabang Dengan Kualitas" seperti yang dijelaskan oleh Jeff Levinson. Ini bisa bekerja, tetapi Anda harus melihat dengan hati-hati bagaimana mengelola hotfix / qfe percabangan dan menggabungkan perubahan kembali ke Trunk.


3
2017-08-06 02:09



Anda mungkin mempertimbangkan untuk mengganti ke Git daripada Subversion. Git mendukung model percabangan semacam ini dengan sangat baik dan sangat ringan. Dibutuhkan sedikit membiasakan diri, terutama jika Anda bergerak dari Subversion, tetapi pada akhirnya itu membelikan Anda banyak.

Alur kerja Git yang disarankan untuk fitur baru dapat berupa:

  1. Buat cabang dari batang.
  2. Menerapkan fitur, termasuk iterasi ulasan internal, pada cabang fitur.
  3. Ketika klien menandatangani fitur baru menggabungkan cabang ke dalam kedua batang dan produksi dan (opsional) menghapus cabang.

Anda tidak perlu memiliki cabang pementasan untuk alur kerja ini. Anda juga tidak perlu menyimpan cabang-cabang fitur setelah digabungkan - Git akan mengingat riwayat perubahan.

Model ini mendukung pengembangan fitur asynchronous / out-of-order dan meninjau dengan cukup baik, karena setiap cabang fitur pada dasarnya independen.

Cabang-cabang sangat murah di Git dan penggabungan biasanya cukup sepele.


4
2017-08-02 21:31



Anda tidak benar-benar mengatakan bagaimana itu menjadi berantakan, tapi saya menduga itu ketika semua orang menggabungkan kembali fitur mereka kembali ke bagasi. Saya akan menyarankan ini sebagai alur kerja:

  1. Setiap orang yang bekerja menuju penyebaran berikutnya bekerja di bagasi dan melakukan secara teratur; hanya fitur yang mengambil lebih dari satu siklus atau yang mungkin tidak disertakan dalam pengiriman berikutnya yang harus dikerjakan pada cabang yang terpisah. Kami menyebutnya cabang-cabang pembangunan dan mereka harus bergabung pada awal siklus pengembangan - tidak pada akhirnya.

  2. Saat Anda siap ke panggung, buat cabang rilis. Lanjutkan batang sebagai rilis berikutnya, gabungkan di setiap cabang pengembangan yang ditargetkan pada rilis berikutnya. Pada titik ini perbaikan bug mungkin harus digabung dari cabang kembali ke batang, tetapi hanya perbaikan bug dan tidak pengembangan fitur harus ditambahkan pada cabang, jadi seharusnya tidak terlalu buruk. Dalam praktiknya, untuk mengurangi penggabungan yang tidak perlu, kami biasanya menunda pembuatan cabang rilis hingga kami benar-benar siap untuk mulai mengerjakan fitur baru.

  3. Ketika saatnya tiba untuk memindahkan kode ke dalam produksi, cukup beri tanda pada cabang rilis dan tetap menggunakannya. Gunakan cabang ini untuk mempertahankan versi kode ini dengan tambalan sampai semua situs klien Anda menggantinya dengan versi berikutnya.

Model ini di mana Anda mengembangkan pada batang dan setiap rilis disimpan pada satu cabang bekerja sangat baik bagi kita di lingkungan di mana kita kadang-kadang memiliki pelanggan yang menginginkan perbaikan untuk versi yang sangat lama dari perangkat lunak kami.


2
2017-08-03 13:20



Daripada memiliki cabang terpisah untuk pementasan dan produksi, Anda mungkin ingin mempertimbangkan pendekatan berikut:

Setiap pengembang selalu bekerja di luar bagasi dan ketika saatnya untuk memasukkannya ke dalam staging, Anda membuat tag yang menunjukkan cuplikan kode yang masuk ke lingkungan staging.

Jika klien Anda menyetujui, maka Anda dapat melanjutkan dan mendorong tag yang sama ke produksi.

Jika mereka tidak menyetujui (katakanlah, mereka menemukan bug), maka Anda tetap bekerja dari trunk dan membuat tag lain dengan perbaikan bug.

CATATAN: karena SVN tidak memiliki konsep 'tag' yang diberlakukan, 'tag' pada dasarnya adalah cabang tempat Anda masih dapat melakukan kode. Namun, kamu tidak harus ubah (mis., komit) tag yang Anda buat dari bagasi.


1
2017-08-02 21:00