Kiat untuk mencapai pengiriman "berkelanjutan"


14

Sebuah tim mengalami kesulitan dalam merilis perangkat lunak secara rutin (sekali setiap minggu). Yang berikut adalah garis waktu rilis yang khas:

Selama iterasi:

  • Pengembang mengerjakan cerita di backlog pada cabang fitur berumur pendek (ini diberlakukan dengan antusias) berdasarkan cabang utama.
  • Pengembang sering menarik cabang fitur mereka ke cabang integrasi, yang secara terus-menerus dibangun dan diuji (sejauh cakupan pengujian berlangsung) secara otomatis.
  • Penguji memiliki kemampuan untuk menerapkan integrasi secara otomatis ke lingkungan pementasan dan ini terjadi beberapa kali per minggu, memungkinkan terus menerus menjalankan suite pengujian mereka.

Setiap Senin:

  • ada pertemuan perencanaan rilis untuk menentukan cerita mana yang "dikenal baik" (berdasarkan karya penguji), dan karenanya akan ada dalam rilis. Jika ada masalah dengan cerita, cabang sumber ditarik keluar dari integrasi.
  • tidak ada kode baru (hanya perbaikan bug yang diminta oleh penguji) dapat ditarik ke dalam integrasi pada hari Senin ini untuk memastikan penguji memiliki basis kode yang stabil untuk memotong rilis dari.

Setiap Selasa:

  • Penguji telah menguji cabang integrasi sebanyak yang mereka bisa berikan waktu yang tersedia dan tidak ada bug yang diketahui sehingga rilis dipotong dan didorong ke node produksi perlahan.

Ini kedengarannya oke dalam praktek, tetapi kami telah menemukan bahwa itu sangat sulit untuk dicapai. Tim melihat gejala-gejala berikut

  • Bug "halus" ditemukan pada produksi yang tidak diidentifikasi pada lingkungan pementasan.
  • perbaikan terbaru menit terakhir berlanjut hingga hari Selasa.
  • masalah pada lingkungan produksi memerlukan roll-back yang menghambat pengembangan yang berkelanjutan sampai penyebaran hidup yang berhasil dicapai dan cabang utama dapat diperbarui (dan karenanya bercabang dari).

Saya pikir cakupan tes, kualitas kode, kemampuan untuk menguji regresi dengan cepat, perubahan menit terakhir dan perbedaan lingkungan berperan di sini. Adakah yang bisa memberikan saran mengenai cara terbaik untuk mencapai pengiriman "berkelanjutan"?


1
Lebih lanjut ke jawaban @ emddudley tentang buku Continous Delivery, saya akan mendorong Anda untuk menonton infoq.com/presentations/Continuous-Deployment-50-Times-a-Day presentasi yang sangat menarik tentang penyebaran yang benar-benar berkali-kali per hari ke dalam siaran langsung yang sebenarnya produksi.
sdg

Jawaban:


6
  • Bug "halus" ditemukan pada produksi yang tidak diidentifikasi pada lingkungan pementasan - di salah satu proyek dengan masalah seperti itu saya telah melihat ini cukup berhasil ditangani oleh taktik saya sebut masalah ganda. Maksud saya untuk bug seperti itu, orang-orang membuat dua tiket dalam pelacak isu: satu ditugaskan untuk pengembang untuk memperbaiki kode, satu lagi untuk penguji untuk merancang dan membuat uji regresi atau perubahan dalam lingkungan pementasan yang akan mencegah pengulangan di masa depan. Itu membantu menjaga pementasan yang cukup dekat dengan dorongan.

  • masalah pada lingkungan produksi memerlukan roll-back - jika ini sering maka rilis mingguan Anda benar-benar palsu - pertimbangkan untuk menyesuaikan frekuensi ke level yang benar-benar berfungsi. Dengan palsu saya berarti bahwa jika mengatakan salah satu dari dua rilis mingguan Anda gulungan-kembali itu berarti bahwa pengguna menghadapi baru (bekerja) rilis sekali dalam dua minggu - yang adalah semua yang penting, bukan berapa kali Anda menyebarkan.

  • cabang fitur yang diberlakukan secara antusias - apakah itu berarti bahwa beberapa waktu sebelumnya, Anda juga mencoba mengerjakan satu cabang dan merasa lebih rendah? Jika ya maka lewati sisanya. Kalau tidak, coba kerjakan satu cabang (jika perlu, google untuk strategi percabangan "cabang pengembangan" atau strategi percabangan "batang tidak stabil" untuk detail). Atau, jika Anda menggunakan Perforce, cari web untuk pedoman Microsoft tentang percabangan dan penggabungan. Coba saya katakan itu? maaf kata yang tepat harus diuji : Maksud saya, 1) rencanakan kapan dan bagaimana mengukur apakah satu cabang lebih baik atau tidak daripada yang Anda miliki sekarang dan 2) rencanakan kapan dan bagaimana Anda akan beralih kembali ke cabang fitur jika seandainya ini pengujian gagal .


PS.

Mungkin Anda dapat menemukan lebih banyak trik seperti itu dengan mencari di web untuk sesuatu seperti manajemen risiko proyek perangkat lunak


memperbarui

<salin dari komentar>

Saya menganggap perbaikan sering menjadi gejala pipa tes yang rusak - bukankah ini masalahnya? Either way, mereka membutuhkan rilis berulang untuk mendapatkan perbaikan panas membuat lebih banyak pekerjaan untuk tim ops. Selain itu, hot fix biasanya dikodekan di bawah tekanan waktu yang ekstrem, yang berarti kemungkinan besar kualitasnya lebih rendah daripada pekerjaan normal.

</ salin dari komentar>

  • hot-fix menit terakhir - masalah di atas terlihat masuk akal bagi saya, serta referensi Anda untuk pipa tes yang rusak. Dengan pembaruan ini, catatan Anda sebelumnya bahwa integrasi kode baru diblokir pada hari Senin terdengar seperti satu lagi gejala patah (saya pikir kata yang lebih tepat akan diperdebatkan ). Maksud saya maksud sebagai berikut: Anda menggunakan cabang tunggal untuk secara bersamaan melayani dua tujuan: integrasi dan rilis. Ketika rilis mendekati, kedua tujuan ini mulai berbenturan satu sama lain, mendorong untuk persyaratan yang saling bertentangan: tujuan integrasi paling baik dilayani dengan cabang terbuka terus menerus ( Gabung Dini Dan Sering ) sambil melepaskan manfaat stabilitas dari cabang yang disegel(terisolasi) selama mungkin. A-ha sepertinya bagian puzzle mulai cocok ...

.. Begini, pembekuan pada hari Senin sekarang tampak seperti kompromi yang dilakukan untuk melayani tujuan yang bertentangan: pengembang menderita blok integrasi kode baru sementara penguji menderita karena blok ini terlalu singkat, semua orang agak tidak senang tetapi kedua tujuan dilayani lebih atau kurang.

Anda tahu, mengingat di atas saya pikir taruhan terbaik Anda adalah mencoba melepaskan dari cabang khusus (selain integrasi) . Apakah cabang ini akan berumur panjang seperti integrasi atau berumur pendek seperti cabang fitur Anda (dengan "fitur", well, rilis) - terserah Anda, ia harus terpisah.

Pikirkan saja itu. Saat ini Anda menemukan satu hari tidak cukup untuk menstabilkan rilis dengan mudah, bukan? dengan strategi percabangan baru, Anda hanya dapat melakukan fork 2 hari sebelum rilis alih-alih satu, tidak ada masalah. Jika ternyata dua hari saja tidak cukup, coba forking 3 hari sebelumnya, dll. Ya, Anda dapat mengisolasi cabang rilis secepat yang Anda inginkan karena ini tidak akan memblokir lagi penggabungan kode baru ke cabang integrasi. Catatan dalam model ini, tidak perlu membekukan cabang integrasi sama sekali - pengembang Anda dapat terus menggunakannya, pada hari Senin, Selasa, Jumat, apa pun.

Harga yang Anda bayar untuk kebahagiaan ini adalah komplikasi dari perbaikan terbaru. Ini harus digabung dalam dua cabang, bukan satu (rilis + integrasi). Inilah yang harus Anda fokuskan saat menguji model baru. Lacak semua yang terkait - upaya ekstra yang Anda habiskan untuk bergabung ke cabang kedua, upaya terkait risiko yang mungkin lupa dilebur ke cabang kedua - semua yang terkait.

Di akhir pengujian, agregat saja apa yang Anda lacak dan pelajari apakah jumlah upaya ekstra ini dapat diterima atau tidak. Jika itu dapat diterima, Anda sudah selesai. Jika tidak, kembalilah ke model Anda saat ini, analisis apa yang salah dan mulailah memikirkan cara lain yang dapat Anda tingkatkan.


pembaruan2

<salin dari komentar>

Tujuan saya adalah membuat cerita diuji dan dikirim (di belakang atau di depan dinding konfigurasi) dalam iterasi, ini hanya dapat dicapai jika penguji menguji pekerjaan yang dilakukan dalam iterasi (dan tidak menstabilkan kode dari iterasi sebelumnya).

</ salin dari komentar>

Saya melihat. Yah saya tidak punya pengalaman langsung dengan cara itu tetapi telah melihat pengujian jenis in-iteration dilakukan dengan sukses dalam proyek yang terkait dengan kita. Karena proyek kami mengikuti cara yang berlawanan saya juga memiliki kemewahan perbandingan tatap muka untuk pendekatan yang berlawanan ini .

Dari sudut pandang saya, pendekatan pengujian out-of-iteration tampak lebih unggul dalam lomba itu. Ya proyek mereka berjalan dengan baik dan penguji mereka mendeteksi bug lebih cepat dari kita, tetapi entah bagaimana ini tidak membantu. Proyek kami juga berjalan dengan baik, dan entah bagaimana, kami bisa membeli iterasi yang lebih pendek daripada mereka, dan kami memiliki lebih sedikit (jauh lebih sedikit) rilis yang terlepas dari mereka, dan ada sedikit ketegangan antara dev dan penguji di pihak kami.

BTW meskipun deteksi lebih cepat di pihak mereka, kami berhasil memiliki rentang umur bug rata-rata yang sama (rentang hidup adalah waktu antara pengenalan dan perbaikan , bukan antara pengenalan dan deteksi). Mungkin kami bahkan memiliki sedikit keunggulan di sini karena dengan iterasi yang lebih pendek dan rilis yang kurang tergelincir kami dapat mengklaim bahwa rata-rata perbaikan kami menjangkau pengguna lebih cepat daripada mereka.

Kesimpulannya, saya masih percaya bahwa isolasi codeline rilis memiliki peluang lebih baik untuk meningkatkan produktivitas tim Anda.


pada pemikiran lebih lanjut ...

  • isolasi kode rilis memiliki peluang yang lebih baik - setelah membaca ulang saya merasa ini mungkin membuat kesan bahwa saya tidak menyarankan Anda untuk mencoba pengujian in-iteration . Saya ingin memperjelas bahwa saya tidak.

Dalam kasus Anda, pendekatan pengujian iterasi terlihat aman untuk dicoba (eh ... tes ) karena Anda tampaknya memiliki pemahaman yang jelas tentang bagaimana mencapainya ( pipa uji yang mulus ) dan apa saja hambatan utama. Lagi pula, Anda selalu memiliki opsi untuk mundur ke pendekatan alternatif jika Anda merasa terlalu sulit untuk memperbaiki jalur pipa itu.

BTW mengenai hambatan, hal-hal tambahan yang perlu dicatat dalam kasus ini adalah masalah seperti kegagalan mereproduksi bug di sisi dev dan terlambat menemukan / terlambat memverifikasi perbaikan di sisi penguji. Ini mungkin macet pipa Anda juga, seperti itu terjadi sekarang dengan perbaikan terbaru.


1
Terima kasih atas wawasan Anda. Mengenai percabangan, kami telah menguji tidak. pendekatan (dan memang saya telah menggunakan nomor @ org yang berbeda dalam karir saya). Kami telah menetapkan master bersih yang mewakili kode produksi, cabang integrasi (berbasiskan master) yang sering digunakan semua pengembang (idealnya beberapa kali sehari). Cabang integrasi dibangun & diuji terus menerus, dengan penyebaran pementasan otomatis yang sering. Saya telah mencoba garis kotor kotor dengan sukses besar sebelumnya. Pendekatan kami saat ini tampaknya lebih terkontrol. Kami menggunakan dinding konfigurasi untuk fungsi yang tidak diinginkan dan tidak lengkap.
Ben

1
@maple_shaft pertama kali saya melihat bug dibuka di pelacak terhadap test suite pada tahun 2002 atau 2003. Dan sepertinya ini merupakan latihan yang mapan di tim yang saya ikuti saat itu. Adapun bug yang menargetkan perbedaan antara prod dan pementasan, ini memang tampak baru bagi saya sejak pertama kali saya melihatnya (dan benar-benar terkejut) kurang dari 2 tahun yang lalu
nyamuk

1
@gnat, Sepertinya akal sehat itulah sebabnya saya bertanya-tanya mengapa saya belum pernah mendengar itu sebelumnya. Sekarang saya berpikir tentang hal itu meskipun masuk akal karena setiap kelompok QA yang pernah bekerja dengan saya tampak sangat senang untuk mengeluarkan bug tetapi menjadi cengeng berusia dua tahun setiap kali bug dibawa melawan mereka.
maple_shaft

1
@maple_shaft lol setuju dengan cara ini tampaknya jarang terjadi. Tahukah Anda bahwa seseorang dapat membuat bug tidak hanya pada penguji tetapi juga pada penulis dokumen / spec? - Build 12 of Dev Guide mengatakan "hitam" di halaman 34 baris 5; harus "putih". - Ditugaskan ke John Writer. - Perbaikan pada build 67. - Perbaikan yang diverifikasi pada build 89 oleh Paul Tester.
nyamuk

1
Tanggapan terakhir saya karena saya tidak ingin berubah menjadi sesi obrolan, tetapi dalam organisasi terakhir saya, saya menulis bug terhadap penulis spec dan seluruh divisi mundur dalam momen WTF. Saya segera diberitahu bahwa saya memiliki "masalah sikap" dan bahwa saya bukan "pemain tim" dan tidak melakukannya lagi.
maple_shaft

8

Tanpa mengetahui sifat cerita pengguna dan jumlahnya, saya harus mengatakan bahwa siklus rilis 1 minggu tampaknya ekstrem. Skenario di atas yang Anda gambarkan dirancang secara rumit dan melibatkan serangkaian cabang berbeda, titik penggabungan, penyerahan, lingkungan, dan ruang uji, kurang lebih menciptakan sistem manusia di mana satu kesalahan tunggal di tengah kerumitan rencana dapat menyebabkan pelepasan yang terlambat atau kualitas buruk. Ini dapat memiliki efek domino pada rilis berikutnya.

IMHO jadwal terlalu ketat.

Anda dapat meningkatkan cakupan kode dengan menulis tes unit yang lebih efektif dan juga tes integrasi khusus lingkungan.

Anda dapat meningkatkan kualitas kode dengan memperkenalkan pemrograman pasangan dan / atau tinjauan kode, meskipun itu memakan waktu yang lebih berharga.

Estimasi poin cerita pengguna yang lebih baik juga dapat membantu dengan secara implisit membatasi cerita pengguna yang masuk ke dalam satu rilis sehingga menurunkan penyebut pada rasio risiko Anda.

Secara keseluruhan, sepertinya Anda memiliki praktik yang baik dan Anda memiliki sistem yang baik untuk menangani siklus rilis ekstrim Anda. Anda sepertinya berada di jalan yang benar.


Iya! Satu minggu dengan produk besar dalam bahasa yang dikompilasi membutuhkan tes integrasi berangin tidak berkelanjutan, itu melemahkan . Pertahankan terlalu banyak dan Anda akan mengalami kematian pekerjaan!
ZJR

+1; kami sedang menjalankan iterasi tiga minggu saat ini & menemukan it berfungsi dengan baik.
Duncan Bayne

@ZJR, bisakah Anda memperluas apa yang Anda maksudkan dengan memperluas dalam konteks ini?
Ben

@Duncan, iterasi kami adalah 2 minggu, tapi kami mencoba kenaikan satu minggu . Ini mungkin atau mungkin tidak mungkin / ide yang buruk. Pemikirannya adalah kenaikan satu minggu akan mengandung lebih sedikit kode baru dan karenanya akan mengandung lebih sedikit masalah.
Ben

1
@Ben Aston, Jumlah kode tidak menciptakan masalah, tenggat waktu yang tidak realistis, tekanan dan harapan yang tinggi menciptakan masalah.
maple_shaft

1

Mengapa tidak menggunakan penyebaran kontinu yang sebenarnya, di mana komit (atau desakan) menyebabkan tes untuk menjalankan, dan jika tes lulus, penyebaran terjadi?

Kemudian jika Anda tidak yakin dengan perubahan, Anda melakukannya di cabang terpisah, yang masih menyebabkan tes berjalan tetapi tidak ada penyebaran.

Saya pikir ada lebih banyak tekanan dalam mencoba mendapatkan trunk / master rusak untuk stabilitas daripada yang ada, Anda tahu, hanya menjaganya agar tetap stabil.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.