Lepaskan kereta. Laporan Yandex

Proses rilis dalam tim Yandex yang berbeda (dan di perusahaan IT besar mana pun) diatur dengan cara yang serupa, tetapi berbeda dalam banyak detail. Pengembang seluler memiliki spesifikasi mereka sendiri: rilis mereka dipengaruhi oleh urutan tata letak di App Store dan Google Play. Pengembang Android Dmitry PolyakovDmpolyakov Dia berbicara tentang proses di sekitarnya - bagaimana timnya mengirimkan kereta rilis sesuai jadwal, cara meluncurkan rilis yang tidak dijadwalkan, menambahkan trailer ke rilis yang sudah ditinggalkan, dan apa yang harus dilakukan untuk tetap berada di jalur.


- Halo semuanya, saya Dmitry Polyakov, pengembang Android dari aplikasi seluler yang saya ambil.



Sekarang dalam dua tim - Android dan iOS yang saya ambil - masing-masing 13 orang. Ini memungkinkan kami untuk melakukan banyak tugas keren secara paralel dan dengan cepat menggulirkannya ke pengguna. Dalam laporan itu saya akan menceritakan bagaimana kami belajar bekerja dengan git dan hidup dalam satu repositori.

Selanjutnya saya akan memberi tahu Anda bagaimana siklus rilis kami bekerja. Manajer mendatangi kami dan mengatakan bahwa kami ingin meluncurkan fitur ini sesegera mungkin. Jadi, mungkin, manajer mana pun mau, jadi kami mengatur proses rilis sehingga kami pergi ke App Store dan Google Play setiap minggu. Saya juga akan berbicara tentang alat yang kami miliki dan yang saya sarankan Anda coba, mereka keren.

Aliran Git

Mari kita mulai dengan Git Flow. Sebagai dasar, kami mengambil Git Flow klasik, namun, itu telah banyak berubah di bawah kondisi kami, di bawah tim kami. Anda juga terlihat, dan mungkin sesuatu dari ini cocok untuk Anda, tetapi sesuatu tidak. Setiap tim memiliki pendekatan sendiri untuk bekerja dengan git.

Bagaimana cara kerjanya dengan kita? Epic adalah cabang root untuk fitur Anda, untuk beberapa fungsionalitas hebat. Untuk membuatnya lebih jelas, mari kita segera melihat contoh produk.



Manajer datang dan berkata - pengembang, buat kami fungsi daftar keinginan dengan produk yang dipilih dalam aplikasi. Pengembang memulai epik cabang baru dan menyebutnya wishlist.



Selanjutnya, ia menguraikannya menjadi tugas-tugas kecil, yang dimulai pada pelacak. Mungkin ini bekerja dengan jaringan, rendering UI, menulis tes. Untuk setiap fitur tersebut, ia memulai tugas di pelacak. Dan begitu dia mulai menyelesaikan tugasnya, dia memulai cabang fitur yang sesuai. Brunches dia dari epos yang sama.

Segera setelah ia selesai mengerjakan satu fitur seperti itu, ia menuangkannya ke dalam epik melalui permintaan kumpulan. Permintaan kumpulan adalah mekanisme ketika pengembang lain dari tim Anda memeriksa kode Anda. Jika mereka tidak menyukai sesuatu, maka kode Anda mungkin tidak mencapai epos Anda, yang berarti Anda tidak akan dibebaskan sampai Anda menemukan persetujuan dengan mereka.

Ada dua pengulas ini di tim kami. Mereka ditugaskan secara acak. Ini adalah proses otomatis, ini dipilih dari para pengembang yang baru-baru ini bekerja dengan file yang sama yang Anda ubah dalam permintaan kumpulan Anda.



Dengan demikian, ternyata beberapa epos dengan serangkaian fitur mereka sendiri hidup dalam proyek secara paralel. Epik hanya dapat memiliki satu fitur. Ini bisa terjadi jika kita ingin mengunggah fitur ini melalui permintaan kumpulan ke epik.



Segera setelah pekerjaan pada semua fitur dalam satu epik selesai, tugas pertama diserahkan kepada tim pengujian, tim QA, dan mereka secara fungsional menguji cabang. Setelah mereka menemukan bug, Anda mengeditnya sebagai bagian dari epik ini. Setelah semua bug diperbaiki, Anda mengisi epik ini menjadi berkembang. Di sini, tidak ada tinjauan kode tambahan yang sudah dilakukan oleh tim Anda, karena semua kode telah dilihat selama tahap pembekuan fitur dalam epik.

Pengembangan kami adalah cabang ke mana kode yang sudah diuji dikunjungi, karena pada tahap epik itu diuji dan kode melewati permintaan kumpulan.



Ini memungkinkan kami untuk dengan aman membuat cabang rilis baru di awal siklus rilis. Tanpa rasa takut akan ada banyak bug yang belum diuji. Oleh karena itu, kami membuat cabang rilis baru dari pengembangan, sedang diuji. Segera setelah rilis diuji dan kami siap untuk meninggalkan lebih jauh ke gerbang, cabang ini bergabung menjadi master.

Terkadang kami memiliki perbaikan terbaru, dan ada jenis cabang yang terpisah untuk itu. Ini adalah rilis yang sangat singkat yang perlu diluncurkan dengan cepat. Kami tidak punya waktu untuk menunggu tiga atau empat hari agar siklus rilis berikutnya dimulai. Biasanya ini adalah sesuatu yang kecil.

Misalnya, jika beberapa jenis bug masuk ke dalam produksi dan sangat kritis, kita perlu memperbaikinya segera. Oleh karena itu, kami menghentikan rilis saat ini, menjalankan perbaikan terbaru pada bug ini dan memperbarui rilis kami. Tetapi perbaikan terbaru tidak selalu merupakan cerita tentang bug. Terkadang kami memiliki kebutuhan produk.



Misalnya, segera setelah mode isolasi mandiri diperkenalkan di Moskow, kami memiliki kebutuhan produk sehingga pengguna dapat memesan produk tanpa kontak. Sekarang, ketika melakukan pemesanan dalam aplikasi kita, pengguna dapat memilih fungsi "Tinggalkan di pintu". Kurir tiba, meninggalkan bungkusan di bawah pintu dan menyerahkannya kepada Anda tanpa kontak.

Dengan tugas ini dalam perbaikan terbaru kami juga menyertakan berbagai widget yang mendesak Anda untuk tetap di rumah dan memesan barang melalui kurir. Jangan pergi ke titik pengambilan sekarang. Kami meluncurkan tugas-tugas ini melalui perbaikan terbaru sehingga kami dapat menyampaikannya kepada pengguna sesegera mungkin, karena kami menganggapnya penting.

Ketika kami memiliki perbaikan terbaru, kami brunch dari master. Dari pengembangan tidak dapat disantap, karena pada saat itu baru dapat mengembangkan epik, yang belum dirilis. Tapi kami tidak ingin membawa epik ini bersama kami ke perbaikan terbaru, sehingga mereka tidak akan mempengaruhi kami secara acak dan memblokir perbaikan terbaru kami. Setelah perbaikan terbaru selesai, kami menyuntikkannya ke master dan juga menambahkannya untuk dikembangkan, karena kode ini belum ada dalam pengembangan.



Master adalah basis kode yang sesuai dengan versi terbaru aplikasi, yang sekarang ada di toko pengguna. Itu bersih, tanpa bug, karena pengujian fungsional dan regresi telah berlalu di sana, ini adalah cabang cadangan.

Ketika rilis kami selesai, kami juga menuangkannya kembali ke pengembangan. Karena sebagai bagian dari rilis, bug dapat ditemukan yang tidak ditemukan dalam pengujian fungsional, dan epik yang berbeda dapat saling bertentangan. Oleh karena itu, kami juga menyuntikkan rilis ke dalam pengembangan sehingga kami memiliki perbaikan ini dalam pengembangan juga.



Banyak pekerjaan yang dapat dilakukan pada epik, dan untuk menjaga agar kode dalam pengembangan, pengembang terkadang menambahkannya ke epiknya, sehingga ada lebih sedikit konflik pembekuan.



Karena kami menambahkan pengembangan ke epik, epik untuk alasan yang sama perlu ditambahkan ke fitur Anda.



Dalam nama cabang epik dan fitur, kami memiliki nomor tiket di pelacak tugas. Ini keren, karena tepat dengan nomor tiket yang dapat kita ketahui sepenuhnya dari bagian mana pun dari aplikasi kita, di mana tiket itu berubah, siapa yang menulis kode ini dan untuk tujuan apa ditulisnya.



Cabang rilis dan perbaikan terbaru dalam namanya nomor versi rilis saat ini dari aplikasi. Beberapa tim menggabungkan nomor perbaikan terbaru dengan nomor rilis, membenarkan ini dengan fakta bahwa perbaikan terbaru adalah sesuatu yang kecil dan mungkin tidak terlalu penting bagi pengguna. Oleh karena itu, mereka tidak menambah versi aplikasi. Kami tidak menggunakan pendekatan ini, karena berbagai laporan kerusakan dari produsen datang kepada kami, dan kami ingin memahami dengan tepat apakah laporan ini sedang dalam perbaikan terbaru atau dalam rilis, untuk mengetahui ke mana harus mencari masalah.



Menguasai dan mengembangkan adalah cabang-cabang yang terus-menerus tinggal di repositori kami. Setelah dibuat, dan hidup. Oleh karena itu, mereka diberi nama dengan ringkas.

Itulah cara kita hidup. Sekarang kami nyaman, nyaman.

Lepaskan kereta

Kami lolos ke proses rilis kami. Tetapi sebelum kita berbicara tentang rilis dan bagaimana kita membangunnya, saya akan berbicara tentang peran yang kita miliki untuk mendukung rilis.

Kami memiliki pengembang sesuai panggilan yang dalam waktu satu minggu kerja tidak lagi berurusan dengan tugas-tugas produk dan memperbaiki bug dari rilis saat ini. Jika ia tidak memiliki tugas untuk rilis saat ini, ia akan memperbaiki beberapa hutang teknis yang telah kami akumulasikan, mengambil tugas dari backlog dan memperbaikinya.

Ada juga tester yang bertugas. Dia juga berhenti menguji tugas produk dalam satu minggu kerja dan memeriksa rilis saat ini. Jika ia tidak memiliki tugas untuk rilis saat ini, ia menguji apa yang telah dikoreksi sebagai bagian dari hutang teknis.



Rilis dimulai pada hari Jumat. Pada hari inilah kita memiliki tenggat waktu yang sulit. Pada pukul 18 malam, penguji yang bertugas mengklik tombol "Start Release". Setelah momen ini, segala sesuatu yang akan dituangkan ke dalam pengembangan tidak akan lagi jatuh ke dalam rilis saat ini, karena setelah mengklik tombol cabang rilis telah dibuat, berkembang telah bergabung dan lebih banyak tidak akan dituangkan di sana.

Proses penting lainnya terjadi pada hari Jumat, item lain pada rilis saat ini, yang akan saya bahas nanti.



Kami beristirahat di akhir pekan, jadi hari rilis kedua adalah hari Senin. Pengembang yang bertugas memulai hari dengan analisis. Dia melihat apa yang telah diubah dalam rilis saat ini dalam hal kode. Mengambil git diff antara cabang rilis saat ini dan master. Dan dengan perbedaan ini dia melihat komponen mana yang terpengaruh. Ini dapat memengaruhi proses checkout atau keranjang, dan bekerja dengan tumpuan tidak terpengaruh.

Dengan demikian, ia membentuk daftar berbagai kasus yang akan diuji selama pengujian. Ini membantu kami mempercepat regresi, bukan memeriksa seluruh aplikasi. Ketika daftar dikompilasi, tim pengujian memeriksa aplikasi, dan pengembang yang bertugas memperbaiki bug. Jika ia memiliki banyak bug, ia dapat mendelegasikan bagiannya ke pengembang lain yang baru-baru ini bekerja dengan potongan kode ini.



Pada hari Selasa, kami terus menguji rilis kami dan memperbaiki bug rilis. Menjelang sore, pengujian regresi kami berakhir dan kami siap berangkat ke gerbang. Kami meluncurkan kereta rilis kami - bahkan beberapa kereta rilis, karena kami baru-baru ini memasuki pasar baru untuk kami. Saya juga menyarankan Anda mencoba menerbitkan tidak hanya di Google Play, tetapi juga di beberapa lainnya. Nilai tambahnya bukan hanya Anda mendapatkan pemirsa setia baru.

Entah bagaimana, kami menerbitkan rilis kami dan setelah beberapa jam menemukan bahwa jumlah bug di antara pengguna telah tumbuh secara signifikan. Kami melihat bug ini, menganalisisnya dan melihat bahwa itu hanya terjadi pada perangkat Huawei. Kami tidak segera mengerti apa yang terjadi, tetapi kami memiliki Huawei, kami mengujinya, menemukan bug, memperbaikinya dan pergi untuk memperbarui.

Segera setelah kami tiba dengan pembaruan di Google Play, kami melihat spanduk besar, yang mengatakan bahwa karena situasi saat ini di dunia, Google Play memiliki beban yang sangat berat dan mereka tidak punya waktu untuk memeriksa aplikasi secepat biasanya. Ternyata kami belum punya waktu untuk memeriksa aplikasi kami, kami tidak menjangkau pengguna Google Play, tetapi diterbitkan hanya di Huawei AppGallery. Dan itulah alasan mengapa kami hanya memiliki bug di Huawei. Dengan demikian, dimungkinkan untuk mendeteksi dan memperbaiki bug kritis bahkan sebelum dipublikasikan di Google Play.

Selanjutnya, saya akan memberi tahu Anda bagaimana publikasi diatur melalui Google Play, karena kami memiliki pangsa pengguna yang sangat besar di sana. Dan di Huawei AppGallery, kami baru-baru ini pergi dan masih berusaha memahami bagaimana semuanya diatur di sana.

Kami tidak segera mempublikasikan ke semua pengguna di Google Play, sehingga beberapa jenis bug acak tidak memengaruhi seluruh pemirsa kami. Kami menerbitkan hanya untuk semua penguji yang berlangganan fakta bahwa mereka mungkin memiliki bug, tetapi mereka akan menjadi yang pertama menerima perubahan dan rilis kami. Selain itu, kami menerbitkan hanya lima persen dari penonton.



Pada hari Rabu, pengembang yang bertugas menonton rilis baru yang bebas kecelakaan. Penting bagi kita bahwa tidak ada kecelakaan baru dan tidak ada banyak kecelakaan lama. Jika semuanya normal, ia masih memeriksa metrik produk. Misalnya, agar jumlah pesanan tidak turun dibandingkan periode yang sama. Jika metrik produk kami dan bebas gangguan bagus, kami meluncurkan 5% lagi, total 10%.



Pada hari Kamis, pengembang yang bertugas memeriksa ulasan di toko. Bahkan, dia mengawasi mereka pada hari Rabu. Benar, pada hari Rabu kami masih memiliki audiensi kecil, satu atau dua ulasan. Tetapi pada hari Kamis ada lebih banyak ulasan untuk menilai rilis. Mungkin ada 10-15 potong.

Mengapa dia bahkan melihat ulasan jika kita memiliki banyak metrik dan grafik? Aplikasi mungkin tidak macet, bahkan metrik mungkin berurutan. Tetapi mungkin saja pengguna memiliki font atau mungkin beberapa filter tidak berfungsi untuknya. Kami mencoba membuat penggunaan aplikasi untuk pengguna senyaman mungkin dan menganalisis ulasan tersebut, memperbaiki bug atau masalah yang ditemui pengguna.

Jika ulasannya berurutan, bebas macet juga normal dan metrik produk belum merosot, kami sudah meluncurkan sebesar 20%.



Dan itu dimulai hari Jumat, hari peluncuran rilis kami. Poin ketiga yang ingin saya bicarakan adalah bahwa pada hari Jumat kami akan menyelesaikan rilis saat ini. Kami menggulungnya dari 20% segera menjadi 100%. Tampaknya menjadi lompatan yang sangat besar dan sangat berisiko. Tetapi itu tergantung pada tim dan audiens Anda.

20% dari audiens kami memungkinkan kami dengan probabilitas tinggi untuk menilai stabilitas rilis. Dan jika semuanya baik-baik saja sebesar 20%, dan pada hari Jumat kami tidak melihat masalah, maka kami akan langsung menuju yang keseratus.

Saya tahu tim yang menggunakan life hack di Google Play - mungkin dia akan membantu Anda juga. Anda dapat meluncurkan tidak pada 100%, tetapi pada 99,9%. Ini akan memberi Anda tombol di Google Play untuk segera menghentikan rilis. Dan jika Anda meluncurkan 100%, tombol ini menghilang. Tetapi, seperti yang saya katakan, oleh dua puluh persen dari audiens kami, kami dapat secara akurat menilai stabilitas rilis. Karena itu, kami dengan tenang meluncurkan hingga 100%, ini menyelamatkan kami dari langkah-langkah tambahan. Dan kemudian Anda perlu menggulung 0,01% lagi.

Ini adalah proses kami, jadi kami berkendara setiap minggu dan berusaha untuk tidak tersesat.


Alat apa lagi yang kita miliki untuk mendukung kehidupan pengguna yang baik di sisinya? Ini adalah Pembaruan Paksa, Pembaruan Lunak dan Toggle Fitur.



Force Update - mekanisme yang memblokir penggunaan aplikasi jika versinya sudah sangat ketinggalan zaman. Versi yang dianggap usang diatur di panel admin di server. Dan segera setelah nomornya diubah di sana, beberapa aplikasi akan memiliki kotak yang tidak akan membiarkan Anda pergi. Hanya akan ada tombol Refresh, pengguna akan dipaksa untuk memperbarui.

Kami mencoba menggunakan mekanisme ini sesedikit mungkin, tetapi terkadang ini sangat penting. Misalnya, jika kami merusak kompatibilitas ke belakang, meluncurkan fitur baru yang tidak didukung dalam kode lama. Kemudian pengguna aplikasi versi lama mungkin berakhir dalam keadaan tidak konsisten. Dia akan pergi ke keranjang, dan misalnya, dia tidak akan memiliki pesanan. Dia tidak akan mengerti mengapa, meskipun dalam versi baru semua kesalahan terdaftar dan akan menjadi jelas mengapa tidak mungkin untuk melakukan pemesanan.



Untuk membantu Force Update ada Soft Update. Ini adalah hal asli dari Google, yang hanya tertanam di aplikasi Anda dan tidak memblokir penggunaan. Namun dia mengatakan - ada pembaruan di Google Play, instal dan Anda akan memiliki hal-hal keren yang baru.

Awalnya, ini dilaksanakan dengan dialog semacam itu. Ini adalah desain asli dari Android. Dan kemudian itu bisa tertanam dalam aplikasi Anda. Misalnya, kami menerapkannya di widget kami "Perbarui aplikasi" dalam skema warna kami.

Soft Update memungkinkan kami untuk sangat mengurangi jumlah versi, dan ini dilaksanakan hanya sesuai dengan dokumentasi. Cobalah jika Anda memiliki banyak rilis.



Alat penting lainnya adalah Feature Toggle. Ini memungkinkan Anda untuk menyesuaikan bagian dari fungsi di sisi pengguna, mengubahnya di panel admin. Ada serangkaian fitur yang dapat kita hidupkan dan nonaktifkan dari server kami tanpa pembaruan aplikasi tambahan.

Mari kita bicara tentang bagaimana Fitur Toggle bekerja pada contoh aplikasi pihak ketiga - kendaraan. Awalnya, pengembang hanya memiliki sepeda seperti itu, yang sudah memiliki dua Fitur Toggle: motor dan ukuran besar. Pelanggan menggunakan sepeda, kemudian tim penguji mengatakan: kami menguji motor, ia bekerja, mengemudi, keren, mari kita hidupkan untuk pengguna.



Kami pergi ke panel admin, nyalakan Fitur Toggle dan sepeda tanpa memperbarui pengguna, saat bepergian berubah menjadi moped. Pengguna nyaman, ini memungkinkannya bergerak lebih cepat dan lebih nyaman.

Produk berkembang, audiens tumbuh, tidak lagi cocok dengan satu sepeda motor. Pengguna ingin membawa keluarga mereka, naik bersama. Pengembang dan manajer telah menyediakan Toggle Fitur tambahan - ukuran besar. Kami mengaktifkannya di panel admin, dan kendaraan pengguna menjadi lebih besar saat bepergian.



Tampaknya keren: Fitur Toggle membantu kami. Ini benar, tetapi ada masalah yang mungkin Anda temui. Misalnya, Anda perlu memantau kompatibilitas ke belakang dan kompatibilitas Fitur Toggle. Misalkan, pada titik tertentu, aplikasi merusak motor, terjadi crash atau bug. Atau motor ini akan memakan banyak sumber daya kami, dan kami tidak akan dapat mendukung terlalu banyak pengguna dengan motor. Maka kita harus mematikannya.

Tetapi kami tidak ingin aplikasi pengguna menghilang. Kami ingin memberinya kesempatan untuk menggunakan aplikasi, meskipun faktanya ia masih memiliki Toggle dengan ukuran besar. Karena itu, ketika kita mematikan motor, kita harus memiliki mekanisme mundur untuk mengendalikan kendaraan. Dalam hal ini, ini adalah hibrida.



Mungkin perlu dipertimbangkan bahwa atapnya bersandar. Mungkin pengemudi akan merasa tidak nyaman duduk di kursi seperti itu. Tapi dia masih bisa mengendarai kendaraan, menggunakan aplikasi, dan tidak berjalan.

Bagaimana lagi kita menggunakan Fitur Toggle? Misalkan backend masih dikembangkan dan belum siap untuk dirilis. Kemudian kita dapat mengembangkan bagian dari fungsionalitas, mendukung kontrak API untuk semua komunikasi dengan backend, mendukung UI dan meluncurkan dengan fitur Toggle dimatikan. Segera setelah backend siap, kami akan menguji apakah semuanya berfungsi dengan baik, dan jika demikian, aktifkan Fitur Toggle. Maka pengguna tidak perlu diperbarui untuk mendapatkan fitur baru. Artinya, kita sudah memiliki audiensi, kita akan segera muncul di audiens ini. Sangat bagus juga.



Sekarang, seperti yang telah saya katakan, kami memiliki 13 orang di masing-masing tim pengembangan Android dan iOS. Kami bekerja pada satu Git Flow, dalam satu repositori, mengatur proses rilis yang direncanakan, mengurangi waktu untuk memasarkan dan berkendara setiap minggu. Kami baru-baru ini merilis Huawei AppGallery, dan melihat di toko lain. Kami mempelajari cara mengubah aplikasi pengguna tanpa pembaruan karena Feature Toggle. Terimakasih atas perhatiannya.