Apa cara realistis untuk menangani tambalan perangkat lunak khusus pelanggan?

16

Saya mencoba mengumpulkan cara-cara efektif yang orang lain telah memecahkan masalah berikut. Di tempat kerja, kami terpaksa merilis tambalan perangkat lunak (untuk dipasang pada sistem pengguna akhir) yang hanya ingin terlihat oleh pelanggan tertentu. Kode kustom di cabang kontrol sumbernya sendiri. Masalahnya adalah kita memiliki dua baris kode paralel (dan membuat skrip) untuk tetap sinkron, dan setiap kali kita menambal kode asli kita harus menambal dan menguji kode khusus pelanggan.

Saya ingin tahu, bagaimana organisasi lain menangani skenario ini? Kami terbuka untuk solusi bisnis dan bukan hanya solusi teknis (yang berhubungan dengan kontrol sumber). Misalnya, kami telah berbicara tentang memberi tahu pelanggan bahwa mereka tidak dapat menerima pembaruan di cabang itu.

Strategi percabangan kami adalah seperti ini (berdasarkan Panduan Pencabangan Visual Studio TFS , meskipun kami menggunakan Subversion untuk itu) masukkan deskripsi gambar di sini

version-control business release-management

— Vimes
sumber

Jika Anda menggunakan hgatau gitsaya mungkin menyarankan agar Anda melihat menggunakan Patch Antrian ( Ekstensi Antrian Mercurial atau Stacked Git ) tetapi saya tidak tahu apakah TFS memiliki sesuatu yang serupa.

— Mark Booth

Mungkin saya harus menentukan, kami menggunakan Subversion walaupun kami menggunakan strategi percabangan yang menyarankan TFS: P Apakah Patch Queue mengurangi pengujian yang diperlukan? Sepertinya ini untuk patch kontrol sumber? Kami sedang berhadapan dengan tambalan yang dipasang pelanggan ke sistem pengguna akhir.

— Vimes

2

Solusi bisnis adalah: Jangan lakukan itu.

— JeffO

@JeffO panggilan bagus =) Dalam kasus apa pun, apakah ada cara Anda dapat menjadikan ini sebagai saklar runtime yang digerakkan oleh data?

— Patrick Hughes

1

@ JohnB - Maaf, saya tidak tahu, tetapi jika Anda memiliki tambalan sumber maka sistem build Anda harus dapat mengotomatiskan pengujian, ditambah menjaga tambalan per pelanggan di luar svncara mereka tidak mengacaukan alur kerja normal Anda. Jika Patch Queue terlihat berguna, Anda bisa mencobanya menggunakan git-svn atau hgsubversion . Menggunakan ujung depan DVCS untuk memperlancar alur kerja yang rumit svnbahkan mungkin mendorong orang untuk mempertimbangkan pindah ke grosir DVCS, untuk mendapatkan semua manfaat lainnya.

— Mark Booth

5

Ketika Anda mulai memberikan tambalan khusus pelanggan, Anda telah segera membuat versi baru dari produk Anda yang harus dipertahankan di sampingnya. Itu berarti perubahan harus disebarkan antara kedua versi. Biasanya tambalan khusus pelanggan adalah penyesuaian yang harus dimiliki oleh pelanggan, termasuk kode sumber.

Tampaknya tidak mungkin bahwa tambalan untuk memperbaiki sesuatu tidak akan membuatnya menjadi cabang arus utama kecuali jika ini adalah perbaikan sementara yang kurang optimal untuk masalah segera. Jika demikian, maka tambalan hanya perlu dipertahankan sampai perbaikan yang diharapkan berhasil masuk ke jalur utama.

— Charles Lambert
sumber

5

Menurut saya kuncinya adalah "terlihat" - bagaimana dengan tidak memiliki cabang kode yang terpisah sama sekali, tetapi lebih merupakan opsi konfigurasi yang mengubah perilaku?

— Loren Pechtel
sumber

Ini bisa berfungsi untuk kustomisasi sederhana, tetapi yang lebih kompleks dapat membuat produk lebih canggung dan tidak stabil untuk semua pelanggan.

— FrustratedWithFormsDesigner

3

@FrustratedWithFormsDesigner Kustomisasi kompleks untuk klien tunggal merupakan kelalaian besar dalam manajemen dan desain produk. Solusi apa pun yang memerlukan cabang terpisah untuk satu pelanggan untuk suatu produk mewakili ketidakmampuan kotor dalam produk untuk memenuhi semua kebutuhan pelanggan dan pelayanan yang buruk di pihak pemilik produk.

— maple_shaft

2

Saya juga melihat ini menggigit majikan saya sebelumnya berulang kali. Ini hanya praktik buruk, tetapi biasanya itu adalah sesuatu yang manajemen inginkan dan tidak akan mundur. Khususnya jika Anda menggunakan Subversion, ini hanya mimpi buruk yang tidak akan hilang - menjaga kode dalam sinkronisasi akan sakit, waktu dan waktu lagi.

— Steve Hill

1

@maple_shaft - Tetapi apakah Anda berpikir untuk mengajukan pertanyaan "apakah Anda pernah menggunakan percabangan kode untuk mengimplementasikan internasionalisasi"?

— psr

3

@maple_shaft - Saya bercanda, tetapi, sebenarnya, itulah maksud saya, menggunakan percabangan untuk menangani internasionalisasi setidaknya sama buruknya dengan cabang khusus pelanggan. Ini tidak bisa diperdebatkan dalam arti bahwa Anda mungkin tidak ingin bekerja di tempat seperti itu juga. Ini diperdebatkan bahwa saya akan cukup dari topik.

— psr

3

Apakah Anda melihat ini sebagai hal jangka pendek atau jangka panjang? Faktanya adalah bisnis telah memutuskan untuk mengakomodasi pelanggan ini sehingga dalam jangka pendek ini sudah merupakan keputusan bisnis yang harus diselesaikan terutama dengan praktik bisnis (menerima biaya tambahan / membebankan biaya kepada pelanggan).

Jika dalam jangka panjang maka Anda mungkin akan melihat penghematan jika Anda memfaktorkan ulang perangkat lunak untuk dengan mudah mengakomodasi kebutuhan pelanggan melalui konfigurasi (atau pengaturan, dll.).

Jika itu berarti jangka pendek, Anda akan segera menggabungkan perubahan-perubahan itu kembali ke cabang utama / pengembangan dan semua pengguna juga akan melihat perubahan maka mungkin akan dapat diterima untuk bekerja dalam keterbatasan situasi Anda saat ini. Seperti yang saya katakan, keputusan apa yang harus dilakukan harus dibuat ketika keputusan untuk mengakomodasi pelanggan dibuat.

Singkat cerita. Perbaiki jangka panjang secara teknis, Kesepakatan jangka pendek dengannya.

Tentu saja ada titik di mana itu adalah lemparan koin. Jika Anda pada titik itu maka saya akan melakukan apa pun yang disukai pengembang.

— ElGringoGrande
sumber

2

Kami menggunakan subversi juga - dan kami menemukan skenario yang tepat.

Berikut adalah beberapa poin penting yang perlu diingat:

Meskipun perlu, seseorang harus menghindari cabang tertentu untuk pelanggan, kebutuhan harus diminimalkan; selalu bertanya apakah mungkin untuk menggeneralisasi solusi yang mungkin hanya bekerja untuk semua.
Cabang khusus pelanggan harus berasal dari rilis baru. Misalkan Anda memiliki versi 1.2 dan daripada yang Anda peroleh dari versi 1.2.1 hingga 1.2.11 - cabang pelanggan harus diizinkan semua tambalan sehingga cabang pelanggan harus tetap kompatibel dengan versi utama.
Cabang khusus pelanggan perlu dibuat baru ketika Anda memulai versi baru yang tidak kompatibel. Bagian yang disayangkan adalah bahwa entah bagaimana Anda mungkin perlu melakukan kembali pekerjaan. Salah satu solusinya adalah dengan membuat semua tambalan dari cabang pelanggan perlu diekstraksi dan apa pun yang terjadi masih kompatibel dapat diterapkan ke cabang pelanggan baru.
Selalu, dalam keadaan apa pun, jika Anda tidak mendorong perubahan spesifik pelanggan untuk melepaskan cabang atau trunk. Namun, idealnya seseorang harus mencoba untuk menggeneralisasi pekerjaan sedemikian rupa sehingga pekerjaan spesifik pelanggan tersebut tetap berkurang.

Saya telah mencoba menyatukan ide ini untuk ditampilkan di diagram di bawah ini :

— Dipan Mehta
sumber

1

Bagaimana kalau memperkenalkan mekanisme ekstensi ke dalam kode Anda?

Kode utama Anda memiliki:

class Foo
{
}

Ketika program diluncurkan, ia memeriksa DLL / setara moral, dalam folder startup untuk kustomisasi lokal. Jika menemukannya, ia dimuat dan mungkin berisi Foo versi spesifik perusahaan

class FooForABC : Foo
{
}

FooForABC mengimplementasikan perilaku yang sama seperti Foo tetapi mengesampingkan fungsi yang diperlukan untuk menyediakan perilaku spesifik yang dibutuhkan ABC. Teknik ini harus cukup fleksibel untuk menangani setiap skenario yang Anda butuhkan untuk mendukung.

— Winston Ewert
sumber