Cara sederhana untuk meningkatkan kualitas rilis di lingkungan RAD

Sedikit latar belakang di sini - kami adalah tim kecil (dari 5) pengembang RAD yang bertanggung jawab untuk pengembangan perangkat lunak internal di perusahaan non-perangkat lunak besar. "Perangkat lunak internal" bervariasi dari aplikasi desktop .NET menggunakan server MSSQL sebagai backend ke skrip Python yang berjalan di latar belakang ke dokumen dan templat MS Word - sebuah kebun binatang teknologi.

Seluruh tim terdiri dari semua yang mampu mendapatkan persyaratan dari pengguna, menyusun kode, mengujinya, dan menyebar ke dalam produksi. Setelah perangkat lunak dalam produksi itu sedang dirawat oleh tim lain tetapi biasanya mudah bagi kita untuk campur tangan jika terjadi kesalahan.

Semua terdengar bagus sejauh ini, tetapi ada masalah - sebagai tim RAD kita harus sering merilis, dan tidak ada hari berlalu tanpa kita merilis versi baru dari satu atau dua aplikasi (atau itu bisa berupa skrip, dokumen kata yang diperbarui , Aplikasi C ++ konsol, dll) ke dalam produksi. Kami melakukan pengujian pengembangan dan juga melibatkan pengguna akhir dengan membiarkan mereka menjalankan perangkat lunak di lingkungan UAT ...

... tapi bug tetap masuk ke produksi. Pengguna memahami bahwa bug ini dan ketidakstabilan yang terjadi sesekali adalah harga yang mereka bayar untuk mendapatkan apa yang mereka inginkan dengan sangat cepat, tetapi pada saat yang sama itu membuat kami berpikir - mungkin kami dapat meningkatkan pengembangan kami atau melepaskan praktik untuk meningkatkan stabilitas perangkat lunak dan mengurangi jumlah bug yang kami perkenalkan saat menambahkan fungsionalitas baru.

Hal yang baik - kami tidak benar-benar memiliki banyak proses di tempat pertama, jadi itu harus mudah untuk mulai meningkatkan, hal yang buruk - menjadi tim RAD kecil kami tidak benar-benar memiliki banyak waktu dan sumber daya untuk mengimplementasikan sesuatu yang besar, tetapi kami telah memikirkan inisiatif berikut ini dan akan menyambut umpan balik, tip, petunjuk dan saran.

1. Saat ini beberapa aplikasi sedang dirilis ke dalam produksi langsung setelah pengujian pengembang, melewati pengujian penerimaan pengguna. Praktik itu harus dihentikan dan bahkan perubahan kecil harus diuji oleh pengguna akhir. Setiap aplikasi akan memiliki beta-tester khusus yang dipilih dari pengguna akhir. Hanya setelah beta-tester menyetujui rilis baru itu dipromosikan dari pengujian ke lingkungan produksi.

2. Kami tidak melakukan tinjauan kode - tetapi kami akan mulai melakukan tinjauan kode sebelum salah satu dari kami checkin perubahan tersebut. Saya juga berpikir tentang "rollout review" - pada dasarnya salah satu pengembang harus duduk di sebelah yang lain mengawasinya melakukan peluncuran perangkat lunak (menyalin binari, memperbarui konfigurasi, menambahkan tabel baru ke database, dll) - biasanya hanya membutuhkan 5-10 menit sehingga tidak akan memakan banyak waktu "tinjauan peluncuran".

3. Cara meniru waktu rollback ketika rilis baru terbukti cukup buggy untuk ditarik dari produksi dan digantikan oleh versi sebelumnya yang bagus. Kami menyimpan riwayat semua rilis (sebagai binari) untuk membuatnya mudah untuk kembali satu versi - dan meskipun cepat "menimpa binari yang baru dirilis dengan binari versi sebelumnya" itu masih merupakan proses manual yang rawan kesalahan dan kadang-kadang menuntut "bagaimana jika rollback akan gagal dan akan membuat sistem tidak dapat digunakan alih-alih buggy".

Di sinilah kami kehabisan ide-ide kami dan kami ingin mendapatkan tanggapan Anda tentang ini dan jika Anda bisa berbagi beberapa saran perbaikan proses rilis / dev sederhana - itu akan luar biasa.

+1 untuk menyentuh subjek yang hebat. Ketika kita melakukan "Lepaskan rilis awal sering" garis pengembangan, hal-hal mengambil langkah nyata dan sebagai momentum membangun banyak masalah seperti itu muncul (seperti yang Anda jelaskan) yang sebaliknya kita tidak siap untuk mengatasinya. Ketakutan terburuk adalah ketika orang melihat kecepatan sebagai musuh dari pekerjaan yang baik.

Saya telah melihat literatur yang sangat terbatas tentang ini, ini adalah apa yang kami latih yang pasti membantu:

1. Pelacakan Bug yang efektif
Jadikan pelacakan bug lebih efektif - apa yang kita lakukan tidak hanya menyimpan daftar bug dan tanda centang, tetapi ketika ditutup, kita harus mendefinisikan hal-hal tertentu seperti "apakah masalah dapat direproduksi?", "Apakah ini solusi permanen atau perbaikan pekerjaan? "," apa akar penyebab "dari masalah? Ini memungkinkan pengetahuan tentang apa yang terjadi, kapan bug ini terlihat terakhir kali. Ini adalah kunci untuk memastikan bahwa bug tidak sering diulang.

2. Tentukan titik jatuh kunci utama
Kita semua tahu bahwa bug akan datang, jadi kita perlu memberikan langkah mundur yang efektif yang paling sering bekerja. Berulang kali kami menyelesaikan (dengan rasio sekitar 1 dari setiap 10 dalam kasus kami) rilis paling umum yang bekerja di mana-mana dengan cara yang paling dapat diandalkan. Jumlah total rilis bisa banyak, tetapi jika ada yang salah, back back pilih beberapa dan Anda tidak perlu mundur lagi. Salah satu cara paling sederhana untuk mengetahui kemunduran terbaik adalah dengan melihat rilis paling awal mana yang telah berjalan paling lama dalam produksi tanpa banyak masalah.

3. Bedakan rilis perbaikan bug yang berisiko dan stabil atau kecil.
Ketika kita tahu bahwa kita memiliki perubahan algoritma utama, lebih besar kemungkinan bug akan masuk ke dalam skenario yang tidak semuanya diramalkan. Dimana ada kalanya masalah sangat kecil (atau dipahami dengan baik) serta risiko yang kecil. Apakah TIDAK klub fungsi tersebut dan bug sederhana dalam rilis yang sama. Selalu perbaiki bug yang lebih kecil terlebih dahulu, yang harus pergi ke mana pun diperlukan. Buat rilis khusus untuk set fitur khusus yang terbaik yang dapat Anda hilangkan fitur itu tetapi tetapi semua bug penting lainnya masih tersedia diperbaiki pada rilis sebelumnya.

4. Cabang untuk pengembangan fitur yang signifikan
Apa pun yang mengaitkan perubahan yang memiliki pengaruh desain harus dilakukan secara terpisah pada cabang. Pengembangan yang lebih besar tidak dapat diselesaikan dengan cepat dibandingkan dengan bug yang lebih kecil. Jika kami memperkenalkan komit perantara di mana pekerjaan 'parsial' terkait dengan fitur yang masih belum digunakan - adalah wilayah pengenalan bug potensial; bug yang tidak akan muncul jika kerja penuh untuk fitur akan selesai secara atom - maka ini adalah bug yang kita tidak harus menyelesaikannya jika ada cabang.

5. Selalu rencanakan rilis yang berbasis tema.
Seringkali banyak bug yang berbeda tiba dari rilis yang berbeda -tapi yang terbaik adalah mengatur bug (dan fitur) yang mempengaruhi modul serupa memudahkan pekerjaan berulang dan meminimalkan jumlah bug yang berasal dari pekerjaan itu. Selalu persiapkan peta jalan rilis jauh-jauh hari sebelumnya; bug terus mengalir - dan itu jatuh ke dalam rilis target yang berbeda untuk secara optimal memiliki kelompok bug yang baik untuk ditembak bersama dalam rilis yang baik. Ketika bug serupa digabungkan bersama, itu selalu memberikan wawasan yang lebih baik tentang skenario yang bertentangan.

6. Perpanjang rilis baru terlebih dahulu ke beberapa pelanggan.
Dalam kasus kami, kami melihat mengujinya di beberapa situs terlebih dahulu dan semua situs lain menerapkan rilis hanya ketika ada permintaan untuk itu. Banyak kali beberapa (atau sebagian besar) pengguna hanya akan melompat dari rilis stabil ke rilis stabil lainnya saja.

7. Pengujian Regresi
Sepanjang garis bug yang dikumpulkan - membangun gugatan regresi. Juga jika memungkinkan tandai bug kritis dan uji menjadi yang paling penting yang menjadi kriteria kualifikasi minimum untuk diuji sebelum kandidat rilis menjadi rilis.

8. Jeda dan pantulkan
Ketika banyak hal berjalan dalam kecepatan penuh, harus ada waktu untuk istirahat - jeda dan lepaskan yang secara fungsional tidak lebih baik. Bahkan memiliki liburan rilis untuk beberapa waktu. (durasi berbanding terbalik dengan frekuensi). Sebagai contoh, sering kali kita memiliki rilis yang disebut "pembersihan" ini yang tidak menghasilkan hal baru dari sudut pandang fungsionalitas - tetapi itu sangat membantu dalam menjaga kode tetap terpelihara. Sebagian besar rilis tersebut adalah poin mundur yang hebat yang hampir tidak pernah Anda ingat sejarah sebelumnya.

9. Mungkin yang paling aneh menurut
saya yang ini sering sulit diimplementasikan tetapi merupakan trik yang baik. Tukar pemilik modul tertentu. Ketika orang-orang diminta melakukan review kode, tidak banyak yang keluar dari praktik ini. Tetapi ketika Anda harus secara serius menangani kode baru itu, ketika Anda menukar penulis, penyakit "buruk" yang potensial akan segera diketahui sebelum mereka mulai mencemari kode tersebut. Tentu saja, ini mengurangi kecepatan - tetapi jika Anda sering melakukannya, kemungkinan orang menguasai berbagai bagian kode dan mempelajari seluruh produk yang bijak lain yang sangat sulit untuk diajarkan.

10. Terakhir tetapi tidak sedikit
Belajarlah untuk sering kembali ke papan tulis. Semakin Anda berpikir ulang seolah- olah fitur ini akan menjadi bagian dari desain awal kami, bagaimana kami memikirkan desain pada saat itu? Terkadang, tantangan terbesar dengan pekerjaan tambahan hanyalah bahwa kita terlalu dibatasi oleh urutan fungsi yang kita bangun pertama kali dan seringkali tidak dapat kembali ke dasar. Kuncinya adalah tetap melihat bagaimana kita menggeneralisasi daripada mengakomodasi fitur atau skenario baru ini. Ini menuntut agar desain tetap terkini, dan itu hanya terjadi jika kita sering pergi menggambar. Juga, ketika programmer generasi baru bergabung, mereka menjadi bagian dari think tank daripada hanya menempatkan tambalan di sekitar.

EDIT
11. Melacak work-around dan celah desain
Cukup sering kami berada di bawah tekanan jadwal untuk memperbaiki bug dan rilis dalam produksi. Namun, ketika bug berada pada tingkat desain cukup banyak hal yang perlu diubah tetapi seringkali orang akan memperbaiki dengan beberapa jalan pintas untuk memenuhi tenggat waktu. Ini tidak masalah . Namun, ketika beberapa solusi tersebut meningkat, kode menjadi rapuh. Pantau terus jalur khusus pada berapa banyak celah desain yang sudah masuk. Biasanya, ketika Anda menegosiasikan jadwal dengan manajer proyek, yang terbaik adalah membuatnya berkomitmen bahwa kami akan mengirimkannya dalam cara pintas untuk menghemat produksi tetapi kami juga harus memiliki garis waktu dan sumber daya untuk mendapatkan solusi permanen.

Saya bekerja di tim pengembang kecil juga (hanya kami berdua) dan kami mengalami masalah serupa yang telah Anda sebutkan. Masalah utama bagi kami adalah bahwa kami berdua cenderung mengerjakan tugas yang terpisah dan sudah terlalu umum bagi kami untuk menyelesaikan tugas / fitur, mengujinya (hanya diuji oleh pengembang) dan dirilis dengan cepat. Ini menghasilkan banyak rilis kecil dengan pengguna yang melaporkan bug kecil yang seharusnya mudah diambil dalam pengujian.

Untuk meningkatkan proses kami, saya mulai dengan memperkenalkan papan Kanban . Papannya sangat sederhana untuk memulai dan hanya memiliki beberapa kolom (pengaturan menggunakan papan tulis, kartu indeks dan magnet berwarna):

Tumpukan | Yang Harus Dilakukan | Selesai

Namun, ini dengan cepat berkembang untuk mencerminkan proses kami yang sebenarnya:

Tumpukan | Pengembangan | Dev. Tes | UAT | Selesai | Dirilis

Bersama dengan papan kami memiliki aturan bahwa setiap Tugas / Fitur harus diuji oleh pengembang lain (serta oleh pengembang yang mengimplementasikan fitur). Jadi pada saat kartu mencapai kolom 'Selesai', kartu tersebut seharusnya telah diuji oleh setidaknya 2 pengembang dan juga Penerimaan Pengguna yang Diuji.

Ada banyak manfaat lain untuk menggunakan Kanban. Bagi kami, komunikasi telah meningkat dan membantu kami berbagi pengetahuan karena kami berdua terlibat pada tingkat tertentu dalam setiap tugas. Ini juga meningkatkan proses rilis kami karena kami sekarang dapat melihat dengan tepat tugas / fitur apa yang siap untuk dirilis / dilakukan dan kadang-kadang dapat menunda rilis jika kami tahu taks lain akan segera dilakukan. Untuk orang-orang di luar tim, dewan juga bertindak sebagai referensi cepat untuk melihat tugas apa yang telah kami jadwalkan, pekerjaan saat ini dalam proses dan apa yang baru-baru ini dirilis.

Selain itu, kami menggunakan magnet berwarna (satu per pengembang) untuk menandai kartu yang sedang kami kerjakan, tetapi opsi lain adalah menambahkan jalur berenang (baris), satu per pengembang dan menempatkan kartu Kanban di jalur berenang yang relevan. Sekali lagi ini membantu sebagai referensi cepat untuk melihat apa yang sedang dikerjakan setiap pengembang.

Tautan lain yang menurut saya berguna:

Kanban Diterapkan untuk Pengembangan Perangkat Lunak: dari Agile ke Lean

Sistem Kanban untuk Rekayasa Perangkat Lunak - Video

Semoga Kanban akan membahas poin 1. dalam pertanyaan Anda. Sehubungan dengan ulasan kode, kami melakukan ini pada tahap pengujian dev sehingga setiap perubahan yang diperlukan setelah tinjauan akan diuji lagi sebelum pergi ke UAT. Rolling kembali tergantung pada lingkungan Anda, tetapi kami menyebarkan file aplikasi ke Terminal Server menggunakan file batch yang mengubah nama file saat ini dan menyalin di seluruh file baru dari server pusat dan kami dapat memutar kembali dengan cukup mudah dengan menempatkan cadangan (file sebelumnya) di lokasi pusat dan menjalankan kembali skrip.

Anda telah mengidentifikasi bahwa Anda tahu ada masalah dengan proses Anda yang memengaruhi kualitas perangkat lunak Anda, dan sementara pertanyaan ini akan memancing berbagai jawaban, saran saya adalah melihat topik rekayasa perangkat lunak dan mencoba dan mempelajari apa pengembang di utama menemukan diri mereka melakukan lebih banyak di bidang itu. Saya sarankan Anda mulai membaca beberapa sumber yang bagus untuk memulai diri Anda. Beberapa yang terlintas dalam pikiran:

• Pengembangan Perangkat Lunak Ramping oleh Mary dan Tom Poppendeick memberikan bacaan yang bagus untuk orang-orang yang tertarik mempelajari cara mengidentifikasi "limbah", dan apa yang harus dilakukan untuk mengubah proses menjadi lebih ramping dan lebih efisien.
• Sekilas Kepala Pengembangan Perangkat Lunak oleh Dan Pilone dan Russ Miles agak seperti salah satu dari buku-buku "untuk boneka" pada pandangan pertama, tetapi dengan melihat sedikit melewati gaya presentasi kacau, itu berisi sebagian besar informasi yang berkaitan dengan dasar-dasar rekayasa perangkat lunak dan memiliki tulisan singkat tentang Test Driven Development.
• Memperkenalkan BDD adalah halaman Dan North tentang masuk ke Bevenor Driven Development, atau mungkin Anda lebih suka BDD Wiki . Ini adalah referensi pemula untuk BDD dan Anda mungkin ingin melihat ke dalam alat dan kerangka kerja untuk membantu Anda. Yang penting untuk dipahami adalah bahwa BDD secara efektif TDD dibawa ke tingkat konseptual yang lebih tinggi. Ini memungkinkan Anda untuk berpikir tentang pengujian saat Anda memikirkan spesifikasi, dan untuk menguji dalam bahasa yang sama yang Anda gunakan saat Anda menulis spesifikasi. Kerangka kerja umumnya berintegrasi dengan kerangka kerja unit pengujian lain, sehingga Anda mendapatkan yang terbaik dari kedua dunia jika Anda memutuskan bahwa pengujian Anda mungkin tidak selalu mendapat manfaat dari sintaks BDD.
• Artikel Pengembangan Perangkat Lunak Agile Wikipedia adalah primer yang baik tentang pengembangan perangkat lunak tangkas, dan menyediakan sejumlah referensi dan tautan yang bermanfaat ke artikel oleh beberapa orang komunitas pengembangan yang lebih dihormati.

Untuk meningkatkan BAGAIMANA Anda bekerja, Anda harus membiarkan diri Anda benar-benar berpikiran terbuka, dan bersedia melangkah dengan baik di luar zona nyaman Anda untuk belajar meningkatkan hal-hal yang Anda lakukan tanpa melekat pada konsep-konsep tertentu yang mungkin Anda temukan. lebih nyaman untuk bertahan. Berbicara dari pengalaman pribadi, ini mungkin hal yang paling sulit untuk dilakukan, atau untuk mendorong orang lain.

Perubahan itu sulit pada saat-saat terbaik, bahkan jika Anda merasa Anda secara aktif mencari perubahan, maka saran terbaik yang dapat saya berikan kepada Anda adalah dengan melihat berbagai metodologi Agile yang telah dikembangkan selama bertahun-tahun untuk membiasakan diri dengan praktik-praktik tersebut. yang dianggap paling penting (misalnya: Pengujian Unit, Integrasi Berkelanjutan, Refactoring, dll ...), dan kemudian pilih metodologi yang tampaknya paling dekat dengan apa yang Anda dan tim Anda akan merasa paling nyaman dengannya. Setelah Anda membuat keputusan, sesuaikan praktik dan proses pengembangan Anda agar sesuai dengan bagaimana tim Anda lebih suka bekerja, dengan mengingat para kepala sekolah yang ramping dan bagaimana Anda ingin bekerja sehingga tim Anda dapat menghasilkan nilai terbesar dengan paling tidak limbah. Akhirnya,

Jika Anda merasa proses Anda hanya perlu mengutak-atik, namun Anda khawatir rantai alat Anda tidak cukup sesuai dengan kebutuhan Anda, maka mungkin cari perbaikan di sana. Minimal, produk integrasi integrasi berkelanjutan (seperti Continuum, Cruise Control atau Hudson), dan sistem Pelacakan Masalah (seperti Jira, atau Redmine) harus menjadi prioritas untuk membantu Anda mengotomatisasi beberapa proses build dan release Anda, dan untuk tetap memeriksa bug dan permintaan fitur Anda.

Kenyataannya adalah bahwa tidak peduli seberapa RAD proses Anda, jika Anda tidak menginvestasikan waktu untuk mendapatkan hal-hal yang "tepat" untuk tim Anda, masalah Anda hanya akan terus tumbuh seiring waktu, dan persepsi Anda tentang waktu yang tersedia akan menyusut sesuai. Perubahan besar biasanya keluar dari pertanyaan ketika berada di bawah tekanan waktu yang berat, tetapi cobalah dan beri diri Anda sedikit "ruang gerak" untuk menempatkan sistem pada tempatnya untuk membantu Anda mengambil langkah kecil menuju visi tim Anda tentang metodologi yang ideal.

Setiap kali saya mendengar tentang cacat, pertanyaan pertama saya adalah tentang di mana cacat berasal dan di mana mereka terdeteksi dan dihapus. Efisiensi Penghapusan Cacat adalah cara yang baik untuk mengukur dan melacak ini. Dengan mengetahui di mana cacat berasal dan bekerja untuk meningkatkan proses pada fase-fase itu, Anda dapat mengurangi waktu dan biaya proyek. Sudah diketahui bahwa lebih murah untuk memperbaiki cacat lebih dekat ke titik injeksi mereka, jadi setelah Anda tahu dari mana cacat itu berasal, Anda kemudian dapat melihat perubahan kegiatan untuk meningkatkan fase-fase tersebut.

Setelah Anda memiliki informasi tentang dari mana cacat itu berasal, Anda dapat melihat dengan tepat teknik dan teknologi apa yang ingin Anda terapkan. Tinjauan persyaratan, desain, dan kode, pengujian otomatis, analisis statis, integrasi berkelanjutan, dan pengujian yang digerakkan pengguna yang lebih luas mungkin merupakan opsi yang harus Anda perhatikan, tergantung pada fase apa yang menghasilkan cacat.

Untuk memperluas keinginan Anda untuk tinjauan kode, Anda juga harus mempertimbangkan berbagai tingkat ulasan kode berdasarkan prioritas dan risiko modul. Modul risiko rendah, prioritas rendah mungkin tidak memerlukan peninjauan kode sama sekali, atau mungkin hanya pemeriksaan meja sederhana, di mana pengembang lain hanya membaca kode sendiri dan memberikan komentar, akan bekerja. Teknik peninjauan kode lainnya termasuk pemrograman pasangan, penelusuran, kritik, dan inspeksi dengan berbagai jumlah pengembang.

Untuk tujuan memutar kembali, saya akan mengotomatisasi proses yang menggunakan beberapa jenis skrip untuk membuatnya lebih cepat dan lebih sedikit kesalahan rawan. Di dunia yang sempurna, saya ingin meningkatkan kualitas produk yang dikirim sehingga tidak perlu dibatalkan, dan Anda dapat mencapainya. Memiliki kemampuan, meskipun, mungkin ide yang baik, tetapi membuatnya tanpa rasa sakit mungkin.

Seperti yang telah ditunjukkan orang lain, menambahkan pengujian regresi akan membantu untuk menghindari cacat yang sama muncul di masa depan. Namun, jika Anda menemukan cacat baru, maka mungkin sudah saatnya untuk menambahkan pernyataan (alias kontrak) ke kode yang menentukan pra-kondisi, pasca-kondisi, dan invarian dari kelas dan metode.

Misalnya, jika Anda memiliki kelas di mana metode hanya dapat menerima angka antara 10 dan 25 (ini disebut pra-kondisi), Anda akan menambahkan pernyataan tegas di awal metode. Ketika pernyataan ini gagal, program akan crash segera dan Anda akan dapat mengikuti rantai metode yang menyebabkan kegagalan itu.

Python, PHP, dan bahasa pemrograman lainnya diketik secara dinamis dan tidak menambahkan banyak kondisi ke metode. Semua yang diperlukan untuk sesuatu untuk bekerja adalah mengimplementasikan metode tertentu. Saya menduga bahwa Anda memerlukan lebih banyak kondisi pada metode Anda. Anda perlu mendefinisikan dan menguji untuk memastikan bahwa suatu metode benar-benar dapat bekerja di lingkungannya.

Untuk program C / C ++, saya menemukan bahwa menambahkan pernyataan untuk menguji alokasi memori sangat membantu dalam mengurangi jumlah kebocoran memori dalam program.