Halo! Nama saya Mikhail Bulgakov (tidak, bukan kerabat), saya bekerja sebagai insinyur rilis di Badoo. Lima tahun yang lalu, saya mengambil otomatisasi rilis aplikasi iOS, yang saya jelaskan secara rinci dalam artikel ini . Dan kemudian dia mengambil aplikasi Android.
Hari ini saya akan merangkum beberapa hasil: Saya akan memberi tahu Anda apa yang telah kami lakukan selama ini. Singkat cerita: setiap karyawan yang terlibat dalam proses dapat merilis setidaknya semua aplikasi kami di kedua platform dalam beberapa klik - tanpa sakit kepala, memakan waktu, pendaftaran dan SMS. Jadi, departemen insinyur rilis kami untuk 2019 menghemat sekitar 830 jam.
Untuk detail - selamat datang di bawah luka!
Apa yang ada di balik rilis ponsel ini
Rilis aplikasi di Badoo terdiri dari tiga tahap:
- Pengembangan.
- : , — , App Store Google Play.
- , -.
Ketika aplikasi sudah benar-benar siap dan tahap pertama telah berlalu, penting untuk tidak memperbaikinya pada tahap rilis dan membawa produk ke "counter". Langkah terakhir ini tampaknya paling mudah, tetapi sebenarnya butuh banyak waktu dan keberhasilannya tergantung pada beberapa orang.
Sebagian besar waktu dihabiskan untuk menyiapkan jendela aplikasi di App Store atau Google Play: Anda perlu mengisi tangkapan layar yang indah, membuat deskripsi yang menarik dioptimalkan untuk pengindeksan yang lebih baik, pilih kata kunci untuk pencarian. Popularitas aplikasi secara langsung tergantung pada kualitas pekerjaan ini, yaitu, pada kenyataannya, hasil dari kegiatan pengembang, penguji, perancang, manajer produk, pemasar - semua orang yang terlibat dalam penciptaan produk.
Jika aplikasi ada dalam beberapa bahasa, setidaknya diperlukan orang yang terpisah atau bahkan beberapa karyawan untuk menyiapkan showcase: seorang manajer produk yang akan menulis teks deskripsi, mengatur terjemahan ke dalam semua bahasa dan menyiapkan spesifikasi teknis untuk membuat tangkapan layar, perancang yang akan mengambil tangkapan layar dari teks overlay, garis besar perangkat, dll., dan, tentu saja, penerjemah yang akan menerjemahkan semua tangkapan layar dan teks ke berbagai bahasa.
Bagian terakhir dari pekerjaan adalah proses rilis itu sendiri. Dibutuhkan banyak waktu untuk tim rekayasa rilis kecil. Pada tahap yang krusial namun agak rutin ini, kami berusaha meminimalkan jumlah kesalahan dan pengaruh faktor manusia. Untuk melakukan ini, pertama-tama, adalah perlu untuk mengotomatisasi pemuatan metadata (teks dan desain grafis dari jendela aplikasi): ini dapat secara signifikan mengurangi biaya waktu dan dengan cepat melakukan rilis bisnis (misalnya, merancang aplikasi untuk Hari Valentine).
Karena keputusan tentang kesiapan aplikasi untuk rilis di Badoo dibuat oleh tim QA-engineer, kami memutuskan untuk memberi mereka hak untuk menekan tombol "merah" untuk meluncurkan rilis. Pada saat yang sama, kami ingin agar dapat diakses bahkan dari perangkat seluler (dengan tampilan visual dari kemajuan skrip).
Langkah Pertama Menuju Otomasi: Memuat Metadata
Cara kerjanya di awal: untuk setiap rilis, sebuah tabel dibuat di Google Sheets, di mana manajer produk mengunggah teks master terverifikasi dalam bahasa Inggris, setelah itu para penerjemah mengadaptasinya untuk negara tertentu, dialek dan audiens, dan kemudian insinyur rilis mentransfer semua informasi dari tabel ini di App Store atau Google Play.
Langkah pertama yang kami ambil menuju otomatisasi adalah mengintegrasikan terjemahan teks ke dalam proses terjemahan keseluruhan kami. Saya tidak akan membahas ini - ini adalah sistem besar yang terpisah, yang dapat Anda baca di artikel terbaru kami. Poin utamanya adalah bahwa penerjemah tidak membuang-buang waktu di tablet dan bekerja dengan antarmuka untuk memuat yang nyaman dengan tangan (baca: ctrl + c ctrl + v) dari opsi yang diterjemahkan di halaman. Selain itu, ada peluang untuk membuat versi dan fondasi untuk Infrastruktur sebagai Kode.
Pada saat yang sama, kami menambahkan bongkar terjemahan yang sudah jadi dari database dan menanamkannya dalam file IPA yang dikumpulkan (ekstensi file aplikasi iOS). Aplikasi ini dibangun dengan TeamCity. Dengan demikian, setiap versi aplikasi selalu memiliki terjemahan baru tanpa intervensi manual dalam proses pembuatan.
Untuk sementara kami hidup seperti itu, dan secara keseluruhan, semuanya cocok untuk kami. Tetapi jumlah aplikasi meningkat, dan dengan itu waktu untuk mempersiapkan setiap rilis.
Realitas kami pada 2015
Rata-rata, rilis satu aplikasi dengan versi screenshot saat ini memakan waktu sekitar satu setengah hingga dua jam kerja dari insinyur rilis dalam kasus iOS dan sekitar setengah jam dalam kasus Android. Perbedaannya adalah karena kenyataan bahwa aplikasi iOS harus melalui apa yang disebut Pemrosesan, yang membutuhkan waktu (tidak mungkin untuk mengirim aplikasi untuk Tinjau sebelum Pemrosesan berhasil selesai). Selain itu, App Store sendiri jauh lebih lambat daripada Google Play untuk sebagian besar operasi pada saat itu.
Menjadi jelas bahwa kami membutuhkan alat tambahan untuk mengirimkan aplikasi ke toko. Dan tepat pada saat itu, sebuah produk bernama Fastlane mulai mendapatkan popularitas di pasar open-source. Terlepas dari kenyataan bahwa dia masih lembab saat itu, dia sudah bisa memecahkan lapisan besar masalah kita ...
Saya akan mengatakan beberapa kata tentang dia untuk memperjelas apa yang akan dibahas lebih lanjut.
Sekilas tentang Fastlane
Saat ini, Fastlane adalah produk yang hampir sepenuhnya dapat mengotomatiskan semua tindakan mulai dari saat pengembangan hingga rilis aplikasi di App Store dan Google Play. Dan ini bukan hanya tentang mengunduh teks, tangkapan layar, dan aplikasi itu sendiri - di sini adalah manajemen sertifikat, pengujian beta, penandatanganan kode, dan banyak lagi.
Kami mengenal Fastlane selama "masa muda" dan ketidakstabilannya. Tetapi sekarang ini adalah komponen yang bekerja dengan percaya diri dan tidak terpisahkan dari banyak tim pengembangan aplikasi seluler yang menghadapi masalah biaya waktu yang sangat besar untuk mengirimkan produk mereka kepada pengguna. Hal yang paling menarik tentang itu adalah kemampuan untuk menulis plugin Anda sendiri untuk komponen utama dan menggunakan plugin yang ditulis oleh komunitas... Untuk produk spesifik seperti ini, ini adalah solusi yang baik, yang (yang penting) membantu untuk tidak menghasilkan teknologi "ekstra" di DevTools.
Keyakinan juga terinspirasi oleh fakta bahwa pendiri dan kepala pengembang Fastlane dipekerjakan oleh Google: sekarang komponen tidak hanya mendukung komunitas, tetapi juga Sam.
Seiring waktu, kami telah mengimplementasikan sebagian besar kemampuan Fastlane ke dalam sistem build, sign, fill, dan banyak lagi aplikasi kami. Dan sangat senang akan hal itu. Mengapa menemukan kembali roda, dan bahkan mempertahankan bentuknya yang benar, ketika Anda dapat menulis skrip terpadu sekaligus yang akan berputar sendiri dalam sistem CI / CD?
Otomatis rilis iOS
Karena Google Play lebih bersahabat dengan pengembang, perlu waktu sangat sedikit untuk merilis aplikasi Android: tanpa memperbarui teks, video, dan tangkapan layar - beberapa menit. Karenanya kurangnya kebutuhan untuk otomatisasi. Tetapi dengan App Store, masalahnya sangat nyata: butuh terlalu banyak waktu untuk mengirimkan aplikasi ke Ulasan. Oleh karena itu, diputuskan untuk memulai otomatisasi dengan iOS.
Kami merenungkan kemiripan sistem otomatisasi interaksi kami dengan App Store (dan bahkan membuat prototipe), tetapi kami tidak memiliki sumber daya untuk menyelesaikan dan memperbarui. Juga tidak ada API yang kurang lebih memadai dari Apple. Nah, paku terakhir di peti mati solusi khusus kami didorong oleh pembaruan App Store dan mekanismenya. Jadi kami memutuskan untuk mencoba Fastlane - yang masih versi 2015.
Langkah pertama adalah menulis mekanisme untuk mengunggah teks yang diterjemahkan untuk aplikasi ke struktur yang diinginkan sebagai komponen dari sistem internal AIDA (Automated Interactive Deploy Assistant) kami yang umum. Sistem ini adalah sejenis hub, penghubung antara semua sistem, teknologi, dan komponen yang digunakan di Badoo. Ini bekerja pada sistem antrian yang ditulis sendiri diimplementasikan di Golang dan MySQL. Mempertahankan dan meningkatkannya terutama Departemen Rilis Rekayasa. Kami membicarakannya secara lebih rinci dalam sebuah artikel di tahun 2013, sejak itu banyak yang telah berubah. Kami berjanji untuk menceritakannya lagi - AIDA luar biasa!
Pada tahap selanjutnya, teks yang diunduh dimasukkan oleh Fastlane, yang mengunggahnya ke App Store. Setelah itu, saya harus masuk ke antarmuka App Store, secara manual memilih versi yang diunduh yang diinginkan dan mengirim aplikasi untuk verifikasi jika Pemrosesan sudah selesai saat itu.
Ini mengurangi waktu persiapan untuk rilis dari beberapa jam menjadi sekitar 30 menit, yang mana hanya satu setengah menit harus dilakukan dengan tangan! Sisa waktu adalah menunggu. Tunggu akhir Pemrosesan. Mekanisme itu merupakan terobosan pada waktu itu justru karena hampir sepenuhnya menyelamatkan kami dari pekerjaan manual saat mempersiapkan AppStore untuk rilis. Kami membuat repositori untuk skrip, yang diberi akses ke orang-orang yang terkait langsung dengan rilis (manajer proyek, insinyur rilis).
Kami hidup dalam mode ini selama beberapa waktu. Tetapi pada titik tertentu, skema ini menyebabkan akumulasi banyak "pengetahuan suci", pemiliknya dan, sebagai hasilnya, gambaran umum peristiwa menjadi satu orang, dan ini tidak baik. Khusus untuk orang ini sendiri: Anda bahkan tidak bisa berlibur tanpa laptop.
Selain itu, ada banyak komponen infrastruktur yang tersebar di sekitar mekanisme ini, praktis tidak terkait satu sama lain.
- Kami harus pergi ke TeamCity untuk membangun yang baru, mengunduh file IPA dari sana, mengunggahnya ke App Store melalui Manajer Aplikasi.
- Lalu pergi ke antarmuka dengan terjemahan dalam AIDA, lihat apakah semua terjemahan siap, jalankan skrip, pastikan itu berfungsi dengan benar (setelah semua, pada saat itu Fastlane masih lembab).
- App Store , Processing.
- Review.
Demikian juga dengan setiap aplikasi. Biarkan saya mengingatkan Anda, pada saat itu kami memiliki delapan dari mereka.
Langkah selanjutnya adalah mentransfer skrip ke AIDA kami, pada saat yang sama menggabungkan dan mengotomatiskan semua langkah sampai aplikasi dikirim: memeriksa kesiapan terjemahan, mengumpulkan data dari TeamCity, notifikasi, logging dan semua manfaat lain dari abad ke-21. Sejalan dengan ini, kami mulai mengunggah semua versi bawaan ke TestFlight pada tahap pembuatan.
TestFlight adalah aplikasi pihak ketiga, yang pernah dibeli oleh Apple untuk menguji aplikasi yang sudah selesai oleh penguji eksternal dalam lingkungan produksi yang praktis, yaitu dengan pemberitahuan push dan sebagainya.
AIDA dilakukan dengan baik, jadilah seperti AIDA!
Semua ini mengarah pada pengurangan waktu dari setengah jam menjadi satu setengah menit untuk segala sesuatu tentang segala sesuatu: file IPA punya waktu untuk melalui Pemrosesan bahkan sebelum saat ketika tim teknik QA memberikan lampu hijau untuk meluncurkan rilis. Namun, kami masih harus pergi ke App Store, pilih versi yang kami inginkan, dan kirimkan ke Tinjau.
Plus, antarmuka sederhana dibuat: kita semua suka klik-klik.
Jadi, tab demi tab, Ctrl + C Ctrl + V ...
Otomasi Rilis Android
Kemudian muncul pertanyaan tentang otomatisasi rilis aplikasi Android. Meskipun proses ini jauh lebih cepat, perlu dilakukan cukup banyak dengan tangan:
- Buka konsol Google Play untuk memastikan bahwa versi sebelumnya diluncurkan ke 100% pengguna atau dibekukan.
- Buat versi baru dari rilis dengan teks dan tangkapan layar yang diperbarui (jika ada).
- Unggah file APK (Paket Android), unggah file Pemetaan.
- Buka HockeyApp (digunakan untuk mencatat kerusakan pada waktu itu), unggah file APK dan file Pemetaan di sana.
- Buka obrolan dan berhenti berlangganan tentang status rilis.
Demikian juga dengan setiap aplikasi.
Ya, Google Play memiliki API sendiri. Tetapi mengapa membuat pembungkus, memantau perubahan dalam protokol, mempertahankannya dan memunculkan entitas yang tidak perlu jika kita sudah menggunakan Fastlane untuk rilis iOS? Selain itu, ada nyaman di server kami, diseduh dalam jus sendiri dan umumnya diperbarui. Dan pada saat itu, ia juga telah belajar cara merilis aplikasi Android secara memadai. Bintang-bintang datang bersama!
Pertama-tama, kami memotong semua yang lama dari mana saja yaitu: skrip individual, sketsa otomasi, pembungkus tua untuk API - ini dibuat sekali sebagai percobaan dan bukan dari nilai tertentu. Segera setelah itu, kami menambahkan tim ke AIDA, yang sudah tahu cara mengambil apa yang dibutuhkan dari TeamCity, mengunggah apa yang diperlukan di HockeyApp, mengirim pemberitahuan, aktivitas log, dan secara umum ia adalah anggota tim.
Fastlane menangani pengisian APK dan Memetakan file di Google Play. Saya harus mengatakan bahwa jauh lebih mudah untuk berjalan di sepanjang jalur yang sudah dilalui: itu cukup cepat direalisasikan dengan upaya minimum.
Pada tahap tertentu dalam implementasi otomatisasi, terjadi transisi dari arsip APK ke AAB (Bundel Aplikasi Android). Sekali lagi, kami beruntung bahwa pada tumit kami cepat berhasil memperbaiki segalanya, tetapi "hiburan" ditambahkan sehubungan dengan transisi ini. Sebagai contoh, ia merusak HockeyApp, yang tidak tahu cara menggunakan arsip AAB sehubungan dengan persiapan untuk menggergaji diri. Jadi agar dapat terus menggunakannya dengan nyaman, setelah merakit AAB, perlu membongkar arsip yang dirakit, mendapatkan file Pemetaan dari sana, yang akan terbang ke HockeyApp, dan dari AAB itu perlu secara terpisah mengumpulkan file APK dan hanya kemudian mengunggahnya ke HockeyApp yang sama. Terdengar menyenangkan. Pada saat yang sama, Google Play sendiri secara sempurna membusuk AAB, mengeluarkan file pemetaan dan menyisipkannya di mana diperlukan. Jadi kami menyingkirkan satu langkah dan menambahkan beberapa langkah, tetapi tidak ada jalan lain.
Antarmuka ditulis (sekali lagi, dengan analogi dengan iOS), yang dapat mengunduh versi baru, memeriksa rilis di sepanjang dan di seluruh, mengelola rilis aktif saat ini (misalnya, meningkatkan persentase peluncuran). Dalam formulir ini, kami memberikannya kepada anggota tim Android QA yang bertanggung jawab untuk rilis, mulai mengumpulkan umpan balik, memperbaiki bug, memperbaiki logika (dan apa lagi yang terjadi setelah rilis 1.0?).
Omong-omong, di masa depan, otomasi memberi kami kesempatan untuk mengunggah versi beta aplikasi ke Google Play secara otomatis sesuai jadwal, yang, pada gilirannya, mempercepat proses pengujian otomatis dan regresi cukup banyak.
Penyatuan aliran rilis seluler
Pada saat rilis Android diotomatisasi, Fastlane akhirnya belajar cara mengirimkan versi aplikasi iOS untuk ditinjau. Dan kami telah sedikit memperbaiki sistem pemeriksaan versi di AIDA.
Saatnya untuk memberikan rilis iOS atas belas kasih tim insinyur QA. Untuk melakukan ini, kami memutuskan untuk menggambar bentuk yang indah yang akan sepenuhnya menutupi kebutuhan yang timbul selama rilis aplikasi iOS: itu akan memungkinkan untuk memilih build yang diinginkan di TeamCity sesuai dengan parameter yang telah ditentukan, memilih opsi teks yang dimuat, memperbarui atau tidak bidang opsional (misalnya, Teks Promosi) ...
Tidak lebih cepat dikatakan daripada dilakukan. Cetakan ternyata sangat bagus dan sepenuhnya memenuhi semua permintaan. Selain itu, dengan pengenalannya, dimungkinkan untuk segera memilih semua aplikasi yang diperlukan dengan semua parameter yang diperlukan, sehingga interaksi dengan antarmuka diminimalkan. Sesuai perintah, AIDA mengirimkan tautan ke build log, yang dengannya Anda dapat melacak kesalahan yang terjadi, memastikan semuanya berjalan dengan baik, mendapatkan beberapa jenis informasi debug seperti versi file IPA yang diunduh, versi rilis, dll. Ini adalah betapa indahnya rilis iOS. dan dipindahkan ke tim QA iOS.
Apakah ini imut?
Kami sangat menyukai ide dengan cetakan sehingga kami memutuskan untuk membuat yang serupa untuk rilis Android. Padahal kami memiliki aplikasi yang sepenuhnya ditulis dalam React Native dan tim QA dari aplikasi itu bertanggung jawab atas rilis iOS dan Android.
Antarmuka yang sudah digunakan oleh tim Android QA diintegrasikan dengan perubahan dalam bentuk yang serupa, prosesnya disesuaikan dengan realitas baru - semuanya sedekat mungkin dengan proses tim iOS. Ini memberikan insentif untuk akhirnya membuat sketsa versi final atau kurang lebih final untuk kedua platform (dalam proses perubahan konstan, kami pasti tidak ingin melakukan ini), dan juga untuk memisahkan proses rilis dari semua pembatasan buatan yang telah berkembang secara historis dan menyebabkan gerakan yang tidak perlu dalam situasi non-standar, yang membutuhkan. tim aksi insinyur rilis.
Keluaran
Dengan cara yang menyenangkan selama sekitar lima tahun (dari saat kami mulai mengembangkan bisnis seluler hingga hari ini), kami sepenuhnya mengotomatiskan proses perakitan, pengujian dan rilis, menjadikannya seefisien mungkin dan mengalihkan tanggung jawab untuk rilis kepada anggota tim QA yang menerima keputusan tentang tingkat kesiapan aplikasi.
Selain keuntungan yang jelas, kami benar-benar menyingkirkan skrip yang tersebar, dari segala macam "pengetahuan rahasia" yang dikaitkan dengan satu orang, mengintegrasikan komponen baru ke dalam ekosistem kami, yang didukung oleh tim kecil insinyur rilis.
Sangat bagus bahwa sekarang ada peluang untuk mengotomatiskan sebagian besar tindakan rutin, bahwa insinyur dapat menulis kode kapan pun mereka inginkan, dan pengembang pihak ketiga dapat mendukung kode apa pun tanpa membuang waktu berharga untuk menggali ke dalam antarmuka yang kompleks. Sangat sulit untuk mengetahui hal-hal seperti "Di mana saya harus mencentang?", Ketika jam tengah malam, tidak ada seorang pun di kantor, dan perbaikan terbaru perlu diunggah di sini dan sekarang.
Lima tahun. Mengapa lama sekali? Pertama, rilis seluler jauh dari satu-satunya bidang tanggung jawab untuk tim kecil kami. Kedua, tentu saja, butuh waktu untuk mengembangkan proyek open-source Fastlane baru; sistem rilis kami berkembang dengan itu.
Kami telah menempuh perjalanan panjang di bidang ini. Mungkin itu bukan yang paling efektif, mungkin beberapa menyapu bisa diramalkan dan dielakkan. Tapi memang seperti itu. Ketika kami memulainya, tidak ada artikel serupa semacam ini - kami membuat jalan kami sendiri. Dan jika Anda dihadapkan dengan tugas yang sama sekarang dan artikel ini akan membantu Anda dengan sesuatu, saya akan sangat senang. Tetapi bahkan jika Anda belum mempelajari informasi baru yang fundamental, saya harap setidaknya menarik untuk dibaca di waktu luang Anda. Dan, mungkin, bandingkan dengan pengalaman Anda. Dan jika Anda memiliki sesuatu untuk dikatakan tentang topik ini, selamat datang di komentar!