Apa kunci untuk berhasil mengatur Pengiriman Berkelanjutan pada proyek? Pekerjaan pengembangan, pengujian dan insinyur infrastruktur terkoordinasi dengan baik. Terima kasih, cap, seperti kata mereka :) Tapi bagaimana mempraktikkannya? Dalam artikel ini kami akan membagikan praktik terbaik kami tentang cara mengatur dan mengimplementasikan semua ini.
Kami telah meringkas dasar-dasar dasar menjadi satu lembar contekan untuk kami sendiri dan berbagi dengan Anda:
Insinyur berpengalaman tidak mungkin mempelajari hal baru dari artikel ini, tetapi kami berharap informasi ini bermanfaat bagi pemula.
Apa saja persyaratannya dan bagaimana karakteristiknya
Setiap proyek memiliki sejumlah persyaratan. Penting untuk memahami mereka semua dan tidak membingungkan mereka.
Persyaratan bisnis menentukan apa yang harus dilakukan sistem dari perspektif bisnis.
Sebagai contoh: aplikasi harus memungkinkan pengguna untuk menjual tiket dan layanan tambahan untuk meningkatkan penjualan agen.Persyaratan pengguna menggambarkan tujuan dan sasaran pengguna yang akan bekerja dalam sistem untuk mengimplementasikan persyaratan bisnis. Persyaratan pengguna sering disajikan sebagai Kasus pengguna.
Sebagai contoh: sebagai pengguna, saya perlu menjual layanan untuk mil.Persyaratan fungsional - apa yang harus dilakukan sistem. Menentukan fungsionalitas (perilaku) sistem yang harus dibuat oleh pengembang sehingga pengguna dapat memenuhi persyaratan pengguna.
Persyaratan non-fungsional - bagaimana sistem harus bekerja. Ini termasuk persyaratan untuk kinerja, kualitas, batasan, kegunaan, dll.
Jenis tugas dan urutan uraiannya dalam Pelacak masalah
Jadi, kami telah menjelaskan jenis-jenis persyaratan. Sekarang kita akan membaginya menjadi beberapa jenis tugas, menguraikan masing-masing jenis dan memberitahu cara menggambarkannya dengan benar.
Mari kita mulai dengan yang paling epik, yaitu, dengan Epic.
Epic adalah tugas umum, di mana semua Cerita Pengguna dikumpulkan dengan mempertimbangkan waktu pengembangan layanan. Ini menjelaskan tujuan utama suatu produk atau layanan. Tujuan utama Epic adalah mengumpulkan tugas dan menyimpannya di satu tempat, apa pun persyaratan baru yang diajukan untuk produk tersebut. Epik selalu lebih dari sekadar cerita pengguna dan bahkan mungkin tidak muat dalam satu iterasi.
Solusi dari masalah Epic memungkinkan Anda untuk membuat
MVP (Minimal Viable Product) - produk minimum yang layak. Dengan kata lain, apa yang perlu dirilis untuk mempelajari dan mengadaptasi produk berdasarkan umpan balik dari pengguna akhir.
Apa bedanya Epic dengan User Story?
- Epic hanyalah kisah pengguna yang besar, ciri khasnya adalah keberadaan nilai yang jelas bagi pengguna.
- Mulai membentuk cerita pengguna, mis., Mengumpulkan persyaratan untuk suatu proyek, kami biasanya berpindah dari umum ke tertentu - pertama kami menentukan konsep proyek, memilih orang utama (pengguna sistem), membuat daftar fitur utama, dan kemudian fitur ini dirinci dalam keinginan terpisah - Kisah pengguna.
Deskripsi Epic adalah sebagai berikut:
- Judul / Judul Ringkasan - nama fungsi baru.
- Deskripsi / Deskripsi - ditulis sesuai dengan pola:
Peran pengguna (seperti pengguna, saya ...) / Tindakan pengguna (Saya ingin melakukan sesuatu ...) / Hasil dari tindakan (untuk mendapatkan hasil seperti itu ...) / Minat atau manfaat (akan memungkinkan saya untuk mendapatkan manfaat ini dan itu ...). - Contoh rencana implementasi atau deskripsi singkat dari Cerita Pengguna utama yang akan diimplementasikan sebagai bagian dari Epic with MVP.
- Lampiran / Lampiran - lampirkan korespondensi, teknologi, dan informasi lain yang diperlukan.
Cara membuat kisah Pengguna dan kisah Teknologi
Perbedaan antara kisah Pengguna dan kisah Tech adalah bahwa Tech Story mengacu pada persyaratan fungsional yang harus diperhitungkan dan dijelaskan dalam tugas saat mengembangkan produk. Dan dalam peran konsumen di sini adalah bagian dari sistem.
Menggambarkannya itu mudah. Hal utama yang perlu diingat adalah mengapa semua ini dilakukan.
Urutan deskripsi cerita pengguna cukup standar:
- Judul / Ringkasan / Judul - deskripsi singkat tentang fungsionalitas baru atau peningkatan dalam bahasa yang dapat dimengerti oleh pelanggan.
- Deskripsi / Deskripsi meliputi tujuan utama dan hasil yang diinginkan. Seperti, <peran pengguna>, saya <ingin dapatkan>, dengan tujuan <hasil tindakan>.
- Kriteria Penerimaan adalah daftar kriteria produk prioritas. Artinya, definisi terukur dari apa yang harus dilakukan dengan produk sehingga diterima oleh para pemangku kepentingan proyek.
- Catatan teknis, model, tata letak, tata letak halaman.
- Lampiran / Lampiran - semua teknologi, dokumen, korespondensi dengan pelanggan yang diperlukan.
Cara menjelaskan bug
Informasi apa yang harus ditunjukkan ketika melaporkan bug:
1.
Judul / Ringkasan / Judul secara singkat menjelaskan esensi kesalahan dan menunjukkan lokasi masalah.
2. Deskripsi berisi langkah-langkah berikut:
• cara mereproduksi langkah-langkah kesalahan / pemutaran,
• hasil saat ini,
• hasil yang diharapkan.
3.
Lampiran / Lampiran - semua log, screenshot, tautan ke Kibana dan file lainnya yang diperlukan.
4.
Lingkungan - tanda di mana lingkungan kesalahan direproduksi, dan kategori di mana masalah berada. Misalnya, kesalahan UI, kesalahan INTI, kesalahan SWS, dll.
5.
Prioritas akan memungkinkan setiap anggota tim untuk menilai tingkat keparahan masalah, dan manajer melihatnya dalam daftar kandidat pertama untuk sprint.
Dan jangan lupa untuk mengatur level prioritas yang benar :)
Sekarang setelah kami memahami prinsip-prinsip kerja umum, kami akan memberi tahu Anda cara mengatur pipa penempatan.
Konfigurasi Pipa Penerapan
Untuk mempercepat pengiriman layanan kami ke produksi, kami memperkenalkan pipa penyebaran baru dan menggunakan GitFlow untuk bekerja dengan kode.
Untuk melakukan ini dengan cepat dan dinamis, kami mengerahkan beberapa pelari GitLab yang menjalankan semua tugas dorong pengembang. Berkat pendekatan GitLab Flow, kami memiliki beberapa server: Develop, QA, Release-kandidat dan Produksi.
Integrasi berkelanjutan mulai mengumpulkan dan menjalankan tes untuk setiap komit, menjalankan tes unit dan tes integrasi, menambahkan artefak ke pengiriman aplikasi.
Pengembangan berlangsung seperti ini:
- Pengembang menambahkan fungsionalitas baru di cabang terpisah (cabang fitur). Setelah itu, ia membuat permintaan untuk menggabungkan cabangnya dengan cabang utama pengembangan (Menggabungkan Permintaan untuk Mengembangkan cabang).
- Pengembang lain melihat permintaan penggabungan, menerimanya (atau tidak) dan mengoreksi komentar. Setelah penggabungan, lingkungan khusus dibuka di cabang trunk, di mana tes untuk meningkatkan lingkungan dilakukan.
- Ketika semua langkah ini selesai, insinyur QA melakukan perubahan pada cabang "QA" dan melakukan pengujian.
- Jika insinyur QA menyetujui pekerjaan yang dilakukan, perubahan akan pergi ke cabang Calon Rilis dan menyebar ke lingkungan yang dapat diakses oleh pengguna eksternal. Dalam lingkungan ini, pelanggan menerima dan memverifikasi teknologi. Lalu kami menyaring semuanya menjadi Produksi.
Jika pada beberapa tahap ada kesalahan, maka di cabang inilah kami menyelesaikannya, setelah itu kami memposting hasilnya di Develop.
Kami juga membuat plugin kecil sehingga Redmine dapat memberi tahu kami pada tahap apa fitur ini berada. Ini membantu penguji untuk mengevaluasi pada tahap apa Anda perlu terhubung ke tugas, dan pengembang untuk memperbaiki kesalahan. Jadi mereka melihat pada tahap apa kegagalan itu terjadi, bisa pergi ke cabang tertentu dan memainkannya di sana.
Kami harap Anda merasa terbantu.