Saya selalu ingin membuat sesuatu yang baru dan perlu dalam layanan saya. Apalagi jika pengguna menyukai layanan ini. Tapi dari mana Anda mendapatkan ide? Bagaimana memprioritaskan? Dan bagaimana cara cepat membawa ide ke suatu produk tanpa kehilangan sesuatu yang penting di sepanjang jalan?
Nama saya Alexander, saya memimpin salah satu grup pengembangan antarmuka di Yandex.Market. Hari ini saya akan memberi tahu pembaca Habr tentang pengalaman kami dalam memecahkan masalah ini. Kami juga mempertimbangkan contoh pengiriman fitur ke produksi.
Tim
Yandex.Market adalah sumber daya terbesar Rusia untuk memilih barang dan membandingkan harga. Setiap hari, 3,5 juta orang menggunakannya - mereka merencanakan pembelian di masa depan di sini, mendiskusikan produk, dan membantu orang lain membuat pilihan yang tepat.
Sekarang Yandex.Market mempekerjakan 40 pengembang front-end, dan jumlah mereka terus bertambah. Ya, 40 orang - ini hanya bagian depan Pasar, dan ada juga bagian depan dari dua proyek kami yang lain - pasar Beru dan Bringly. Pada 2005, hanya ada 5 pengembang di Pasar, bayangkan?
Gagasan lahir di wilayah kita. Jadi kami memanggil tim yang terdiri dari spesialis yang berbeda. Biasanya, rangkaian meliputi: proyek (alias insinyur produk), back-end, front-end, analitik, desainer, dan penguji. Tim semacam itu dapat secara mandiri mengembangkan sesuatu dalam layanan dan memecahkan masalah dengan kompleksitas apa pun. Selain itu, setiap sirkuit memiliki batas tanggung jawab yang jelas - “sirkuit fungsional” tertentu dalam produk yang digunakannya.
Kami punya, misalnya:
- loop konversi - berkaitan dengan alat UX, pencarian, pemfilteran dan penyortiran;
- sirkuit komunikasi - bekerja di buletin dan promosi untuk pengguna kami;
- kontur manfaat - penawaran diskon, cashback, kode promosi;
- Sirkuit komunitas - bertanggung jawab atas ulasan, ulasan, diskusi, pencapaian, mekanisme permainan dan UGC lainnya.
Gagasan
Setiap anggota sirkuit dapat menawarkan ide. Kami menyambut semua opsi, bahkan sepele atau benar-benar gila. Biasanya orang-orang menghasilkan ide dalam rapat umum - ini membebani seluruh tim untuk bekerja.
Agar tidak kehilangan apa pun, kami menempatkan semua pikiran kami secara terpisah di Pelacak - bank ide kami. Gagasan yang dikumpulkan dievaluasi sesuai dengan kerangka GIST + ICE. Kami mengevaluasi potensi setiap ide dan biaya tenaga kerja implementasi untuk memutuskan apa yang layak diambil. Rincian lebih lanjut tentang metode ini
diberitahukan oleh kolega saya.
Ide-ide yang mendapat poin terbanyak berubah menjadi proyek dengan pelanggan dan pemain. Satu set tugas desain yang luar biasa muncul di Pelacak. Tugas didistribusikan oleh ketua tim untuk sprint dan masuk ke tim.
Poin penting adalah bahwa ide tersebut diimplementasikan oleh sirkuit yang menyarankannya. Artinya, penulis ide juga merupakan pelaku. Cobalah untuk mengerjakan tugas Anda, dan bukan pada tugas yang diluncurkan dari atas - perbedaannya akan mudah dirasakan.
Prosesnya
Misalkan kita memutuskan untuk mengembangkan korsel barang untuk pengguna, dengan mempertimbangkan minatnya.
Misalkan loop backenders telah melakukan pekerjaannya, jaringan saraf dilatih, API siap, diuji dan digunakan dalam lingkungan pengujian. Tata letak dari desainer kontur diterima dan terlihat seperti ini:
Tetap melakukan pekerjaan di ujung depan dan mengirimkan komidi putar kami kepada pengguna.
Frontend of the Market adalah klien web dan server NodeJS yang tidak memiliki kewarganegaraan, di belakangnya terdapat lusinan backend lainnya: pencarian, layanan konsultasi, analisis, konten UGC, dan banyak lagi. Frontend hidup di awan Yandex di beberapa DC. Aplikasi NodeJS dieksekusi dalam wadah, dan karena sifatnya stateless, aplikasi ini dapat diskalakan secara horizontal sesuai kebutuhan:
Pengembang front-end pasar sedang mengembangkan sisi server pada NodeJS dan klien pada React + Redux. Berkembang dalam satu bahasa dan dalam satu ekosistem sangat efektif. Jika Anda masih berpikir tentang menyatukan tumpukan teknologi antara server dan klien, coba - itu masuk akal.
Untuk menyelesaikan korsel, kita perlu menambahkan kode untuk menerima barang di server dan mengimplementasikan bagian klien. Anda dapat membuat korsel malas - muat sebelum muncul di layar. Untuk melakukan ini, Anda harus mengimplementasikan titik akhir di API klien.
Ketika ini selesai, pengembang membuat permintaan kumpulan dan mengirimkan kodenya ke tinjauan kode. Ulasan kode kami adalah suatu keharusan. Agar tidak hang, kami bahkan memiliki SLA yang direkomendasikan untuk implementasinya. Anda dapat
membaca tentang bagaimana kami mempercepat ulasan kode di
sini .
Kami sedang mengembangkan front-end di GitHub Enterprise, yang hanya tersedia di jaringan internal. Ada bot di Github kami yang membantu mengatur ulasan kode. Bot itu sendiri menemukan pengulas, menghubungi mereka di messenger, menambahkannya ke GitHub, mengontrol status tiket di Pelacak dan, jika perlu, memanggil pembuat kode.
Pada saat membuat permintaan kumpulan di GitHub, banyak yang terjadi: di lingkungan uji coba, demo berdiri dengan Pasar yang diperbarui dimunculkan, dan tautan akses ke kios ini dikirimkan ke tiket tugas. Banyak pemeriksaan otomatis dilakukan: linter, formatter, unit-test. Tes E2E dijalankan, metrik aplikasi klien dianalisis secara otomatis. Jika ada degradasi terdeteksi, laporan rinci tentang itu segera dikirim ke tiket tugas:
Jika semua cek telah lulus secara normal, tiket secara otomatis ditransfer ke status "Anda dapat memeriksa", dan tugas tersebut muncul di dasbor tim QA.
Setelah insinyur QA datang ke tiket tugas dan memastikan bahwa fungsionalitas baru siap untuk perjalanan lebih lanjut, tiket tersebut ditandai dengan label rilis. Rilis berikutnya akan mencakup semua tiket dengan tag ini.
Pasar sering dirilis, 1-2 kali sehari, dan kami berupaya meningkatkan frekuensi rilis kami. Orang yang bertugas dari tim QA terlibat dalam persiapan dan rilis rilis, dan proses rilis sepenuhnya otomatis. Sebelumnya, paket rilis sudah dirakit dengan tangan, butuh banyak waktu. Sekarang pengembang dapat menghabiskan waktu ini untuk mengembangkan produk. Ini mempercepat pengiriman fungsionalitas baru kepada pengguna kami.
Jadi, komidi putar produk kami yang direkomendasikan akan dirilis. Bagaimana kabarnya?
Insinyur QA yang bertugas menekan tombol pelepas. Pipa rilis mulai bekerja. Presentasi dari laporan proses rilis dapat dilihat di
sini . Tiket rilis dibuat di Pelacak, dan cabang rilis di GitHub. Semua permintaan kumpulan yang telah lulus cek secara otomatis dituangkan ke dalamnya. Dalam lingkungan pengujian, dudukan dengan versi baru Pasar naik. Di stand ini, semua cek otomatis di atas lulus, ditambah banyak cek tambahan. Misalnya, uji beban dengan beban konstan dan meningkat hingga aplikasi uji di-debug. Semua log audit dianalisis dengan cepat, laporan yang jelas dihasilkan, yang segera dikirim ke tiket rilis:
Insinyur QA melihat semua tahapan, dengan satu pandangan dia dapat mengevaluasi hasil dari massa inspeksi. Dalam lingkungan pengujian di stand dengan rilis baru, QA juga menjalani pengujian manual. Kami sering melakukan pengujian A / B atas fungsionalitas baru dan tidak menulis tes E2E di atasnya.
Beginilah tampilan pipa rilis (dapat diklik):
Ketika rilis telah lulus semua cek di lingkungan pengujian, itu dikirim ke yang layak. Prestable adalah lingkungan lain, tetapi dengan backend tempur, tertutup dari pengunjung Pasar sungguhan. Beberapa perusahaan menyebutnya pementasan. Dalam lingkungan ini, serangkaian pemeriksaan khusus dan pengujian fungsional manual juga terjadi. Jika tidak ada masalah yang ditemukan, versi baru Pasar dikirimkan kepada pengguna kami, itu mulai terungkap pada kluster produksi.
Pada saat tata letak untuk pertempuran, pekerjaan robot berlanjut. Mereka secara independen menganalisis log aplikasi, mencari anomali dan degradasi dalam pekerjaan layanan, dan memantau metrik klien. Pemantauan log berlanjut untuk beberapa waktu setelah rilis, dan versi Pasar berikutnya sudah menjalani pengujian di lingkungan pengujian.
Kesehatan Pasar setelah rilis juga dipantau oleh QA yang bertugas. Ia memiliki sejumlah besar grafik yang dapat digunakannya - kami menggunakan Graphit dan Grafana. Grafik memiliki segalanya: dari latar belakang 500-k umum hingga kesalahan aplikasi NodeJS saat berkomunikasi dengan berbagai backend yang dihancurkan oleh DC. Kami juga memiliki kelompok orang yang terpisah - kelompok kesehatan Pasar. Dia memantau metrik Pasar 24/7.
Jika masalah terdeteksi, rilis secara otomatis akan kembali dari cluster tempur. Masalahnya dibongkar dan rilis dikembalikan ke pertempuran. Jika tidak ada masalah, rilis selesai, kode bergabung menjadi master, tiket yang masuk ke rilis ditutup, dan cabang proyek dihapus. Semua ini juga terjadi secara otomatis.
Pada saat ini, pengguna kami sudah melihat produk yang dipilih untuk mereka, dan sirkuit sedang bekerja pada ide baru.
Inilah korsel kami di layanan:
Alih-alih sebuah kesimpulan
Buat tim Anda fleksibel dan mandiri, biarkan mereka menghasilkan ide, urus ide-ide ini, analisis mereka - pasti ada berlian di antara mereka. Ingatlah bahwa ide yang diungkapkan oleh seseorang dengan suara yang tenang dan tidak pasti selama rapat dapat menjadi kunci bagi produk Anda dan penggunanya.
Biarkan penulis mereka mewujudkan ide sebanyak mungkin - sehingga pekerjaan berjalan lebih cepat dan lebih baik. Otomatiskan rutinitasnya. Luangkan waktu untuk menerjemahkan ide menjadi kenyataan, biarkan robot melakukan sisanya.
Jika pembaca tertarik untuk membicarakan sesuatu secara lebih rinci, menulis komentar, saya akan menjawab dengan senang hati, atau mungkin saya akan menggambarkannya di artikel baru.