Kapan waktu yang tepat untuk mulai menggunakan revisi alat berikutnya saat dogfooding?

Secara khusus, saya sedang mengerjakan alat yang mengintegrasikan DVCS dan membangun sistem, tetapi saya membayangkan tantangan yang saya hadapi akan muncul bagi siapa pun yang mengembangkan alat "meta" (kompiler, VCS, sistem bangun, uji pelari, dll.) Yang mereka ingin berkembang melalui "dogfooding" .

Pertanyaan saya adalah: dalam proses rilis scrum-style menggunakan alur kerja percabangan , pada titik apa saya mulai menggunakan versi alat yang lebih baru dalam siklus pengembangan alat?

Saya mencari proses untuk menciptakan keseimbangan antara:

• terus-menerus menggunakan developversi alat ini: Saya menemukan saya merusak perkembangan saya sendiri ketika perubahan dimasukkan.

• terus menggunakan masterversi alat: setiap masalah yang saya temukan melalui dogfooding adalah masalah yang telah dirilis.

Hal pertama yang harus dilakukan adalah melakukan tes regresi offline otomatis yang sangat menyeluruh. Jadikan lulus tes itu persyaratan minimum untuk apa yang Anda gunakan secara resmi.

Kedua, Anda membutuhkan cara sederhana yang mati untuk kembali ke versi kerja sebelumnya, untuk masalah yang tidak dapat dites oleh tes otomatis Anda.

Sebagai contoh, kernel Linux saya ditambal untuk sementara waktu. Saya akan menambal dan mengkompilasi kernel saya di komputer yang sama yang saya maksudkan untuk menggunakannya, yang berarti saya bisa kehilangan lingkungan pengembangan saya jika saya membuat kernel yang salah. Jadi saya memastikan untuk selalu menyimpan kernel yang dikenal baik di menu GRUB saya, jadi jika saya membuat kesalahan, saya kembali ke lingkungan pengembangan yang baik dengan reboot sederhana.

Mengkoordinasikan hal itu dengan tim itu sulit, tetapi saya kira itu sebagian besar masalah membiarkan siapa pun untuk memulai mundur dan mengomunikasikan alasannya. Di kontrol versi, salah satu cara untuk menunjuk itu akan dengan sesuatu seperti last_known_goodcabang, di suatu tempat antara developdan masterdalam alur kerja Anda. Tidak ada yang didorong di sana sampai Anda berhasil membangun dogfooded.

Jika alat ini digunakan untuk menghasilkan perangkat lunak berkualitas produksi (terutama jika digunakan secara rekursif, yaitu untuk mengembangkan sendiri), saya akan meningkatkan upaya pengujian di muka Anda, dan menunggu dogfooding sampai rilis cukup stabil sehingga Anda dapat cukup yakin Anda tidak akan melanggar kode produksi dengan menggunakannya.

Jika Anda harus menunggu versi master untuk memiliki tingkat kepercayaan itu, maka jadilah itu.

Git juga alat seperti itu dan jelas juga tidak dogfooding. Tetapi ia melakukannya pada tingkat yang berbeda di lingkungan yang berbeda. Server publik hanya menjalankan rilis sementara pengembang biasanya bekerja dengan salah satu next(itu nama proyek git untuk "mengembangkan") atau pu(bahkan lebih berkembang daripada mengembangkan). Setiap pengembang yang diblokir oleh beberapa masalah dapat kembali ke nextatau masteratau merilis terakhir setiap kali mereka diblokir oleh sesuatu dan repositori utama tidak terpengaruh, sehingga masalah dapat dibersihkan dengan merujuk padanya.

Model percabangan mirip dengan yang di atas dengan nama yang sedikit berbeda. masteradalah apa rilis besar dilakukan, maintadalah cabang rilis untuk rilis titik berikutnya, nextmirip dengan mengembangkan dengan sedikit perbedaan bahwa fitur dapat digabungkan untuk dikuasai secara terpisah setelah berada di berikutnya bukannya seluruh berikutnya digabungkan.

Ada cabang tambahan pu,. Ini dibuat dengan menggabungkan semua cabang fitur yang dipertimbangkan untuk diintegrasikan bersama next(cabang dibuang dan diciptakan kembali setiap kali). IIRC hanya diterbitkan jika melewati test suite. Terakhir saya melihat Junio, pengelola, menjalankan skrip untuk membangunnya secara manual dengan tangan, tetapi skrip tersebut dapat dijalankan dengan integrasi terus menerus setiap malam dan saya yakin Gerrit bahkan membuatnya secara otomatis.

Jadi itu adalah jawabannya. Anda menggunakan versi pengembangan terbanyak yang Anda miliki di lingkungan pengembangan, tetapi gunakan rilis sebelumnya untuk membuat rilis.

Berdasarkan jawaban yang diterima , saya akan memperluas alur kerja percabangan untuk mempertahankan cabang yang serupa dengan yang berikut:

• master: bergabung dengan release-*pada saat penutupan
• dogfood: cabang dari master; termasuk perbaikan yang diidentifikasi saat dogfooding; menggabungkan dari developketika perangkat lunak dianggap "stabil" untuk penggunaan internal; kepala cabang ini dapat dipindahkan kembali ke masa jika diperlukan
• develop: cabang dari master; termasuk perubahan yang sedang berlangsung, perbaikan bug, dan gabungan dari dogfooddan feature-*cabang
• feature-*: cabang dari develop; termasuk perubahan untuk fitur baru tertentu
• release-*: cabang dari dogfoodsaat perangkat lunak ini dianggap "stabil" untuk penggunaan eksternal; termasuk pembaruan dokumentasi dan perbaikan bug kecil sebelum bergabung denganmaster