Siklus pelepasan perusahaan yang aneh: Go Control Sumber Terdistribusi?

Maaf tentang postingan yang panjang ini, tapi saya pikir itu sepadan.

Saya baru saja mulai dengan toko .NET kecil yang beroperasi sedikit berbeda dengan tempat-tempat lain yang telah saya kerjakan. Tidak seperti posisi saya sebelumnya, perangkat lunak yang ditulis di sini ditargetkan pada banyak pelanggan dan tidak setiap pelanggan mendapatkan rilis perangkat lunak terbaru pada saat yang sama. Dengan demikian, tidak ada "versi produksi saat ini." Ketika seorang pelanggan mendapatkan pembaruan, mereka juga mendapatkan semua fitur yang ditambahkan ke perangkat lunak sejak pembaruan terakhir mereka, yang mungkin sudah lama sekali. Perangkat lunak ini sangat dapat dikonfigurasi dan fitur dapat dihidupkan dan dimatikan: apa yang disebut "fitur toggle." Siklus rilis sangat ketat di sini, pada kenyataannya mereka tidak sesuai jadwal: ketika fitur selesai perangkat lunak digunakan untuk pelanggan yang relevan.

Tim yang tahun lalu baru saja pindah dari Visual Source Safe ke Team Foundation Server. Masalahnya adalah mereka masih menggunakan TFS seolah-olah itu VSS dan memberlakukan kunci Checkout pada cabang kode tunggal. Setiap kali perbaikan bug dimasukkan ke lapangan (bahkan untuk satu pelanggan) mereka hanya membangun apa pun yang ada di TFS, menguji bug itu diperbaiki dan menyebar ke pelanggan! (Saya sendiri berasal dari latar belakang perangkat lunak farmasi dan perangkat medis, ini sulit dipercaya!). Hasilnya adalah bahwa kode dev setengah dipanggang dimasukkan ke dalam produksi tanpa diuji. Bug selalu menyelinap ke rilis build, tetapi seringkali pelanggan yang baru saja membangun tidak akan melihat bug ini jika mereka tidak menggunakan fitur bug tersebut. Direktur tahu ini adalah masalah karena perusahaan mulai menumbuhkan semua tiba-tiba dengan beberapa klien besar datang dan lebih kecil.

Saya telah diminta untuk melihat opsi kontrol sumber untuk menghilangkan penyebaran kode buggy atau yang belum selesai tetapi untuk tidak mengorbankan sifat yang agak tidak sinkron dari rilis tim. Saya telah menggunakan VSS, TFS, SVN dan Bazaar dalam karir saya, tetapi TFS adalah tempat di mana sebagian besar pengalaman saya.

Sebelumnya, sebagian besar tim yang pernah bekerja sama dengan saya menggunakan dua atau tiga cabang solusi Dev-Test-Prod, di mana selama sebulan pengembang bekerja langsung di Dev dan kemudian perubahan digabung menjadi Uji kemudian Prod, atau dipromosikan "bila sudah selesai" daripada pada siklus tetap. Bangun otomatis digunakan, menggunakan Cruise Control atau Team Build. Dalam pekerjaan saya sebelumnya Bazaar digunakan duduk di atas SVN: devs bekerja di cabang fitur mereka sendiri kemudian mendorong perubahan mereka ke SVN (yang diikat ke TeamCity). Ini bagus karena mudah untuk mengisolasi perubahan dan membaginya dengan cabang orang lain.

Dengan kedua model ini ada cabang dev pusat dan prod (dan kadang-kadang menguji) di mana kode didorong (dan label digunakan untuk menandai build di prod dari mana rilis dibuat ... dan ini dibuat menjadi cabang untuk perbaikan bug untuk melepaskan dan bergabung kembali ke dev). Ini tidak benar-benar sesuai dengan cara bekerja di sini, namun: tidak ada urutan kapan berbagai fitur akan dirilis, mereka didorong ketika mereka selesai.

Dengan persyaratan ini, pendekatan "integrasi berkelanjutan" seperti yang saya lihat rusak. Untuk mendapatkan fitur baru dengan integrasi berkelanjutan, ia harus didorong melalui dev-test-prod dan yang akan menangkap setiap pekerjaan yang belum selesai di dev.

Saya berpikir bahwa untuk mengatasi ini kita harus turun model bercabang fitur besar dengan tidak ada cabang dev-test-prod, bukan sumber harus ada sebagai serangkaian cabang fitur yang ketika pekerjaan pengembangan selesai dikunci, diuji, diperbaiki, dikunci , diuji dan kemudian dirilis. Cabang fitur lainnya dapat mengambil perubahan dari cabang lain saat mereka membutuhkan / inginkan, sehingga akhirnya semua perubahan dapat diserap ke semua orang. Ini sangat sesuai dengan model Bazaar murni dari apa yang saya alami di pekerjaan terakhir saya.

Sefleksibel ini kedengarannya aneh rasanya tidak memiliki dev batang atau cabang prod di suatu tempat, dan saya khawatir tentang cabang forking tidak pernah mengintegrasikan kembali, atau perubahan kecil terlambat dibuat yang tidak pernah bisa ditarik ke cabang lain dan pengembang mengeluh tentang gabungkan bencana ...

Apa pendapat orang tentang ini?

Pertanyaan terakhir kedua: Saya agak bingung tentang definisi yang tepat dari kontrol sumber terdistribusi: beberapa orang tampaknya menyarankan itu hanya tentang tidak memiliki repositori pusat seperti TFS atau SVN, beberapa orang mengatakan ini tentang terputusnya hubungan (SVN adalah 90% terputus dan TFS memiliki mode offline yang berfungsi sempurna) dan yang lain mengatakan ini adalah tentang Branching Fitur dan kemudahan penggabungan antara cabang tanpa hubungan orangtua-anak (TFS juga memiliki penggabungan tanpa dasar!). Mungkin ini pertanyaan kedua!

Apa yang mendefinisikan DVCS?

The didistribusikan di DVCS berarti bahwa setiap clone dari repositori memiliki semua informasi yang diperlukan untuk melakukan, pembaruan, cabang, menggabungkan atau mencari setiap revisi dalam repositori itu, tanpa pernah menyentuh server . Satu-satunya hal yang dapat Anda lakukan secara offline svnsebenarnya adalah mengedit file - Anda memerlukan akses server untuk hampir semua svnperintah, termasuk melakukan sesuatu yang sederhana seperti grepping svn log, sehingga sebenarnya mendekati 0% daripada 90%!

Setiap repositori pusat otoritatif yang mungkin diatur dalam DVCS alur kerja adalah hanya lain clone , dan satu-satunya waktu yang Anda butuhkan untuk berinteraksi dengan itu adalah ketika Anda pull down update orang lain atau ketika Anda mendorong perubahan Anda sendiri sehingga orang lain dapat melihat mereka , hampir semuanya bisa dilakukan secara off-line.

Model percabangan apa yang cocok?

Saya sudah dalam situasi Anda sekarang. Sistem seperti itu bisa sangat menyakitkan tetapi Anda harus memahami alasan pragmatis mereka menjadi seperti ini dan menyadari bahwa mereka tidak dapat ditebus . Banyak alat telah dikembangkan yang dapat membantu mengelola kompleksitas semacam ini .

Pertama-tama, apa pun yang Anda lakukan, jangan menunjukkan kepada orang-orang model percabangan git yang sukses , itu hanya akan membingungkan mereka dan mematikannya. Alih-alih, kembangkan model Anda sendiri yang mencerminkan alur kerja Anda saat ini , namun selesaikan masalah dengan alur kerja Anda yang ada .

Beberapa sumber daya yang mungkin ingin Anda pertimbangkan mencakup hal-hal seperti git submodules yang akan memungkinkan pelepasan pelanggan yang berbeda untuk menentukan kombinasi berbeda dari konfigurasi pelanggan, modul aplikasi dan perpustakaan. Pilihan lain adalah penggunaan sistem manajemen tambalan untuk menerapkan antrian tambalan khusus produk / pelanggan.

Kedua opsi ini akan memberikan fleksibilitas, transparansi, dan keamanan yang jauh lebih besar daripada alur kerja Anda saat ini, dan bisa lebih mudah digunakan daripada strategi hanya cabang yang lebih kompleks. Saya tentu berharap saya memiliki akses ke alat-alat ini ketika saya berada dalam situasi Anda.

Untuk informasi lebih lanjut tentang opsi-opsi ini, lihat jawaban saya pada Strategi untuk menggunakan kontrol versi pada sistem modular , Bagaimana Cara Menggunakan Subversion Repository Di Dalam Repositori Git? dan kontrol Sumber / Versi untuk aplikasi yang digunakan oleh banyak perusahaan .

Pada akhirnya, ini benar-benar sesuatu yang harus Anda kembangkan bersama anggota tim lainnya. Jika Anda memiliki visi untuk mengusulkan sesuatu yang bekerja lebih baik dari apa yang sudah Anda miliki, dan dapat memperoleh dukungan dari sesama pengembang, maka Anda akan memiliki waktu yang jauh lebih mudah.

Yang paling penting adalah menunjukkan kepada kolega Anda bagaimana apa yang Anda usulkan akan membuat hidup mereka lebih mudah . Setelah mereka yakin, Anda memiliki peluang yang jauh lebih baik untuk mendapatkan manajemen untuk membuang investasi mereka di TFS dan mulai menggunakan model yang lebih sesuai dengan metode kerja Anda.

Pertama, DVCS adalah red-herring untuk masalah yang Anda miliki - alat kontrol versi yang digunakan bukanlah akar dari masalah yang harus diselesaikan. Mungkin ada aspek-aspek solusi DVCS yang "lebih baik" daripada TFS tetapi bukan itu yang perlu diperbaiki pada saat ini.

Anda telah mengidentifikasi bahwa Anda memerlukan struktur percabangan yang bisa diterapkan yang sesuai dengan organisasi Anda - saya pikir Anda akan menemukan Anda masih memiliki bagasi, ketika fitur selesai digabung kembali ke bagasi dan ditutup. Ada beberapa pemikiran bagus tentang bagaimana Anda menerapkan dependensi bersama juga.

Anda juga perlu mendapatkan integrasi yang terus menerus berfungsi (tidak ada alasan untuk tidak memiliki build otomatis untuk setiap dan setiap cabang aktif untuk memberi Anda keyakinan bahwa Anda dapat membangun cabang itu dan bahwa ia melewati tes yang relevan). Saya merasa tidak nyaman ketika komit (atau setidaknya "dorongan") tidak memicu build untuk saya.

Dan Anda perlu memulai pengujian otomatis di semua tingkatan, tetapi terutama pengujian unit dan pengujian integrasi untuk mulai mengurangi kemungkinan bug baru keluar ke alam liar. Yang terakhir ini sangat besar dan sesuatu yang masih saya perjuangkan tetapi jelas sekali Anda tahu bahwa Anda dapat membangun semuanya, ini akan memiliki nilai paling tinggi.

Anda harus menggabungkan ini dengan memastikan bahwa paket penempatan Anda berasal dari Anda membangun server dan penyebaran yang otomatis sejauh mungkin (Anda harus dapat pergi dari membangun artefak server untuk hidup menggunakan kode yang dikerahkan dengan upaya minimal dan tekanan minimal).

Hmm, saya berasumsi bahwa ada pengaturan pelacakan masalah yang dipesan dengan baik ... Anda juga perlu dan yakin bahwa itu digunakan dengan benar. Idealnya Anda ingin aplikasi langsung Anda untuk memberi umpan balik kesalahan ke sistem ini (atau untuk triase) secara otomatis.

Terakhir, jangan mencoba menyelesaikan semua masalah Anda sekaligus - membangun dan menguji bagi saya adalah tempat yang harus Anda fokuskan terlebih dahulu.

Pertanyaan kedua lebih mudah dan lebih pendek, jadi saya akan mencoba memulainya

DVCS adalah sistem, di mana tidak ada satu pun sumber kode "otoritatif" (kecuali "berdasarkan perjanjian", ketika digunakan) dan pertukaran data P2P dimungkinkan tanpa tingkatan tambahan (definisi pribadi, non-kanonik)

Pada topik pertanyaan pertama

Saya khawatir, perusahaan harus merekonstruksi alur kerja dan memikirkan kembali gaya untuk mendapatkan "kode entah bagaimana dikelola dan dapat diprediksi". Saya tidak dapat mengatakan tentang TFS (kecuali pendapat dan perasaan pribadi, bahwa itu adalah sistem yang lemah di bagian Kontrol Versi / penggabungan tanpa dasar adalah jahat /), tetapi untuk setiap VCS dalam situasi Anda ("Produk" diatur "Modul" independen, setiap "Pelanggan" mendapatkan "Produk" yang berbeda - apakah asumsi ini benar?) Saya lebih suka membagi pengembangan modul menjadi cabang-cabang terpisah, memiliki Produk sebagai "Supermodule" (juga cabang?), di sana setiap modul terkait dengan revisi modul-spesifik. cabang, pengembangan modul menggunakan paradigma cabang-per-tugas (dan modul-cabang hanya terdiri dari gabungan).

Dengan cara ini Anda selalu dapat mengetahui, "Koleksi" mana (yaitu kumpulan modul dan revisi terkait) yang membentuk masing-masing "Produk", memiliki kemungkinan untuk melakukan CI (untuk cabang-cabang tugas yang selesai dan digabungkan ), Pengujian unit dan Pembuatan

Pertanyaan utama iklan: Saya yakin apa yang Anda bicarakan adalah model percabangan git yang berhasil (dan alat bantu git flow untuk mendukungnya). Memiliki cabang master, yang selalu dalam status dapat digunakan dan melakukan semua pekerjaan pada cabang fitur.

Anda juga dapat menggunakan proses yang digunakan oleh git itu sendiri, yang diturunkan dari prinsip dasar yang sama. Dalam pengembangan git-core, semua pekerjaan terjadi pada cabang fitur. Cabang fitur diajukan ke integrator, yang menjalankan skrip untuk menggabungkan semuanya untuk membuat cabang bernama pu(pembaruan yang diusulkan). Berbagai orang mengambil cabang ini dan bekerja dengannya untuk mengujinya.

Alih-alih integrator, Anda dapat meminta server integrasi terus-menerus melakukan penggabungan ini di awal pembuatan. Dengan begitu setiap kali ada anggota tim yang mendorong perubahan ke repositori pusat sebagai cabang fitur (mungkin menggunakan beberapa konvensi penamaan untuk memberi tahu cabang mana yang harus dipilih).

Dalam git cabang fitur daripada hasil next,master atau mainttergantung pada rilis yang ditargetkan di (mempertahankan adalah untuk memperbaiki bug saat ini rilis, master untuk rilis saat ini dalam persiapan dan berikutnya untuk yang setelah itu), tetapi Anda tidak akan memiliki banyak.

Sementara fitur dalam pu("memasak" dalam terminologi git maintainer), mereka digulung danpu cabang dibuang dan dibuat lagi setiap kali, yang membuatnya lebih mudah untuk ditinjau, tetapi tidak cocok untuk mendasarkan pekerjaan lain. Ketika cabang fitur digabungkan ke dalam salah satu garis utama, ditutup untuk mundur dan perbaikan lebih lanjut dilakukan sebagai komitmen baru.

Saya pribadi akan merekomendasikan yang gitterbaik. Awalnya agak sulit untuk belajar, karena tumbuh lebih organik, tetapi pada akhirnya tampaknya paling fleksibel. Tetapi salah satu dari tiga sistem terdistribusi, git, mercurial, dan bazaar akan melayani Anda dengan baik (dan Anda bahkan sering dapat mencampurnya, misalnya mercurial dapat menarik dan mendorong ke / dari repositori git dan saya percaya begitu juga dengan bazaar).

Pertanyaan kedua dari iklan: Saya diajari bahwa "didistribusikan", secara umum, berarti Anda dapat memindahkan objek dan mereka menjaga identitas mereka. Yang persis seperti yang dilakukan kontrol versi terdistribusi: Anda mengkloning repositori dan berisi komit yang sama dan memungkinkan melakukan hal yang sama dengannya. Kemudahan percabangan dan operasi yang terputus adalah fitur tingkat pengguna utama yang mengikuti dari prinsip komit bergerak dan tata letak grafik terarah yang memungkinkannya.

Sayangnya, tidak ada solusi yang diketahui untuk bug dalam kode :)

Jadi, Anda hanya ingin menghentikan checkin yang belum selesai dari terperangkap dalam rilis utama, dan satu-satunya jawaban untuk itu adalah penggabungan-kerja-cabang untuk setiap pengembang. Saya melakukan ini di perusahaan sebelumnya menggunakan Clearcase, itu bekerja cukup baik (meskipun kami harus memiliki selusin admin clearcase).

Sekarang, saya berasumsi juga bahwa Anda melakukan perbaikan bug pada versi produk yang dimiliki masing-masing pelanggan saat ini ... sehingga Anda memiliki masalah penggabungan yang membawa perbaikan bug dari versi A hingga versi Z. Tidak ada cara mudah untuk menangani ini, tetapi Anda harus memiliki cabang untuk setiap versi yang dikirimkan. Cara terbaik untuk mengatasinya adalah dengan mempertahankan cabang fitur pada versi terbaru saja, dan membuat pelanggan meningkatkan untuk mendapatkan fitur baru, pada saat yang sama, melakukan perbaikan bug langsung pada cabang rilis dan menggabungkannya ke atas ke semua cabang rilis lainnya saat selesai.

Tidak terlalu bagus, tetapi bisa bekerja dengan sangat baik. Anda menjaga kode terorganisir dan terpisah dengan baik. Ini juga mudah dimengerti untuk pengembang lain - perbaikan bug kecil langsung pada "kode", apa pun lebih dari beberapa baris dilakukan pada cabang khusus di mana mereka dapat memakan waktu selama mereka ingin menyelesaikannya. (Anda harus memilah masalah penggabungan dan meyakinkan mereka bahwa tidak masalah jika 2 devs bekerja pada 2 fitur pada saat yang sama !!)

Setelah beberapa saat Anda dapat memperkenalkan cabang fitur pada cabang rilis juga, di mana bug diperbaiki kemudian digabungkan, tetapi IMHO ini biasanya lebih banyak upaya daripada yang dibutuhkan. Jika Anda perlu menambahkan fitur ke rilis lama, maka Anda harus mengikuti pendekatan ini - bercabang dari cabang rilis, kemudian menggabungkan kode kembali ke rilis itu, dan menggabungkan perubahan ke atas untuk rilis selanjutnya juga. Itu akan membuat tim pengujian Anda sangat tidak senang karena rilis akan sangat tertunda karena kebutuhan untuk menguji beberapa versi berulang kali, dan tim pengembang tidak senang karena mereka harus melakukan banyak penggabungan sebelum mereka dapat mulai dengan kode baru (di perusahaan saya saat ini) ini terjadi, terutama karena jumlah pekerjaan yang kita miliki yang selalu harus diselesaikan secepatnya).

DVCS:

pada dasarnya sebuah DVCS adalah di mana setiap orang memiliki salinan sendiri dari server repo. Ini memiliki beberapa kelebihan (terutama dalam tim terdistribusi dengan komunikasi terbatas), tetapi juga memiliki beberapa kelemahan, jadi periksalah sebelum Anda beralih ke DVCS. Jika Anda seorang toko Windows maka Anda mungkin akan menemukan Mercurial adalah DVCS terbaik untuk Anda.