Hai Saya Valery Laptev, Kepala Pengembangan LM di Rusia. Selama dua tahun saya perlu meningkatkan departemen besar, dan itu adalah pengalaman yang agak menarik.
Faktanya adalah bahwa Leroy Merlin ada di banyak negara. Perusahaan induk di Perancis disebut ADEO. Mereka menulis kode untuk Perancis, Italia, Spanyol dan Rusia. Model bisnis kami berbeda: jika kami mempertahankan harga terendah di pasar Rusia (di bawah semua pesaing dalam pengawasan), maka di Eropa semuanya berbeda. Faktanya, laut berbeda - dari karakteristik lokal ke undang-undang lainnya. Ada fitur infrastruktur Rusia (penundaan yang sangat besar untuk Khabarovsk) dan siklus hidup lain untuk melakukan pemesanan. Semua ini menimbulkan kode neraka seperti itu yang terdiri dari blok IF besar:
Dua tahun lalu, kami memiliki 60 toko dan banyak, banyak fitur Wishlist. Mereka berputar dalam waktu sekitar enam bulan dan tidak selalu benar. Sedotan terakhir setelah banyak fitur yang ditolak oleh prioritas rendah adalah permintaan untuk memasukkan bidang baris dalam pesanan, sehingga kami akan menguraikannya nanti. Ini diperlukan untuk fitur pengiriman di Rusia, karena negara ini lebih besar daripada negara lain yang memiliki LM. Mereka menolak kami, atau lebih tepatnya, mereka mengatakan akan berada di suatu tempat dalam tujuh hingga delapan bulan.
Siklus setengah tahun dari perusahaan induk yang santai tidak cocok untuk kita. Secara alami, kami menyarankan untuk menulis kode kami sendiri, mengirimkannya ke ulasan dan menunggu implementasi ... Benar, tidak ada yang baik dari ini.
Mengapa fitur diimplementasikan secara lambat?
Ceritanya sangat sederhana: meskipun kami memiliki puluhan toko, kami bukan yang pertama di dunia. Ada kebutuhan Prancis (di mana organisasi induknya), ada kebutuhan negara lain. Mereka diprioritaskan menurut kemungkinan laba atau pengurangan biaya untuk sekelompok perusahaan dan dieksekusi dalam urutan ini. Artinya, fitur kami dibuat hampir tidak pernah, kecuali sangat beruntung dan dalam beberapa jenis sprint seseorang akan menyelesaikan bagian mereka lebih awal dan pergi untuk membongkar bagian bawah jaminan.
Fitur kedua adalah ketika Anda menggulirkan fitur apa pun ke cabang master (di sini, dalam kode IF-IF-IF Legacy), Anda perlu memeriksa bagaimana perilakunya di negara lain. Izinkan saya mengutip
441869 dari Bash:
Programmer: Baiklah, bayangkan Anda adalah seorang penulis dan mendukung proyek "War and Peace." Anda memiliki TK - tulis bab tentang bagaimana Natasha Rostova berjalan di taman di tengah hujan. Anda menulis - "hujan", kecuali, pesan kesalahannya terbang: "Natasha Rostova telah mati, kelanjutan tidak mungkin." Kenapa dia mati? Anda mulai mengerti. Ternyata sepatu Pierre Bezukhov yang licin, ia jatuh, senjatanya menyentuh tanah dan menembaki sebuah tiang, dan peluru dari pilar memantul ke Natasha. Apa yang harus dilakukan Mengisi daya nganggur? Ganti sepatu? Kami memutuskan untuk menghapus pilar. Kami mendapat pesan: "Letnan Rzhevsky telah meninggal." Ternyata di bab selanjutnya dia bersandar pada pilar yang tidak lagi ...
Secara umum, ketika kami memperkenalkan sesuatu untuk box office Rusia, di suatu tempat di Brasil, seseorang mungkin pulih.
Ini berarti cakupan tes yang sangat besar, prosedur pra-rilis yang panjang, dan umumnya enggan mempertahankan kode yang berkembang pesat. Oleh karena itu, semakin sedikit fitur - semakin baik. Tapi Anda bertahan di sana.
Posisi secara keseluruhan sangat dimengerti, dan saya akan melakukan hal itu di situs perusahaan induk. Karena itu rasional.
Pemecahan masalah
Pendekatan pertama ada di dahi: kami menyarankan membuka kode bagi kami untuk melakukan permintaan tarik di sana. Seharusnya akan ada sekitar 10 pengembang yang duduk di sana yang dengan cepat dan cepat mengkodekan fungsi-fungsi bisnis kritis, memberikannya ke Prancis, dan mereka akan menguji sesuai dengan prosedur mereka sendiri, dan semuanya akan baik-baik saja.
Sebenarnya, orang-orang ini sudah: kami terlibat dalam memotong logika bisnis ekstra yang kami dapatkan dari negara lain, seperti berbagai diskon kumulatif dan stok tidak biasa (yang tidak mungkin dengan model bisnis kami), dan menempatkan boneka di tempat ini.
Prancis di ADEO menginginkan siklus rilis untuk menggulung dan menginstal versi baru melalui diri mereka sendiri. Menerima tawaran kami tentang satu cabang untuk percobaan.
Memberi akses, mulai mengambil kode untuk ditinjau. Ternyata lambat sekali. Peluncuran selama beberapa bulan - ini tidak terjadi. Yah menang beberapa minggu, tapi tetap saja prosesnya tidak pas.
Kemudian, selama enam bulan, fitur yang penting bagi kami di bagian konten (mengelola data produk yang dilihat klien) tidak keluar. Kami duduk selama enam bulan tanpa rilis. Entah fitur mereka tidak pergi, atau tes tidak lulus, maka mereka tidak menyadari persis apa yang kami butuhkan. Akibatnya, kami duduk di sistem kunci untuk waktu yang lama tanpa pembaruan. Ada NodeJS + PostgreSQL + Couchbase + Elasticsearch + Angular di bagian depan. Dalam kode, karena sejumlah lapisan arkeologi, hal-hal telah ditemukan, seperti penyalahgunaan database SQL dan database non-relasional. Di salah satu tempat, sepotong besar data master diambil, dimasukkan ke dalam satu bidang database SQL, dan kemudian dipecah menjadi entitas dalam database NoSQL. Pada satu halaman situs dengan pajangan barang ada puluhan dan ratusan permintaan seperti itu. Dengan membaca lebih lanjut tentang warisan ini, rambut di berbagai bagian tubuh mulai bergerak. Kami memahami apa kekhasan warisan yang melapisi bagian kepala yang dihadapi.
Pengembangan sendiri
Ide pertama adalah melakukan fitur bersama. Di tempat, yaitu di Perancis. Kami berempat pergi ke Prancis dan mulai duduk di sebelah kolega kami untuk memahami semuanya bersama dan melakukan apa yang kami butuhkan.
Itu tidak berhasil. Semua sama, semuanya sangat lambat.
Gagasan kedua adalah untuk memotong semua yang sudah ada dan secara bertahap menyelesaikannya. Kami duduk oleh komite arsitektur, mengevaluasi prospek, menghitung perkiraan rencana pengembangan dan menyadari bahwa kami perlu memilih metode yang berbeda. Secara khusus, ya, untuk bercabang, tetapi tidak untuk mengembangkan kode yang ada, tetapi untuk memecah monolith menjadi bagian-bagian dan menempatkan layanan microser di mana diperlukan.
Artinya, kami berencana untuk menulis ulang seluruh blok logika dalam bentuk kode kami. Dan untuk ini mereka mulai beralih bagian dari layanan ke apa yang bisa dilakukan dengan kami. Kami mulai merekrut pengembang. Kemudian kami benar-benar mengikuti tumpukan perusahaan induk - Java, Spring dan semuanya ada di dekatnya, bukannya Couchbase adalah Mongo (ini adalah basis NoSQL serupa).
Seiring perkembangan proyek, kami menyadari bahwa kami perlu melakukan banyak hal dengan cara kami sendiri (karena lebih cepat dan lebih mudah agar tidak mendukung warisan yang tidak kami butuhkan, khususnya), dan mulai memperluas ke teknologi lain. Kemudian ada Java 7, Wildfly (sebelumnya JBoss) dan SVN. Kami bertanya mengapa mereka tidak bermigrasi ke Java 8, GIT, dan Tomcat. Ternyata mereka tidak akan keberatan, tetapi setelah beberapa tahun. Sementara itu, yang tersayang, tulis di tumpukan lama. Jadi kami kata demi kata dan memutuskan untuk berpisah sepenuhnya. Bisnis memilah pertanyaan, apa pro dan kontra, dan sepenuhnya mendukungnya.
Hampir segera melemparkan sekitar 30 persen dari kode, menulis banyak layanan microser mereka sekitar. Dari kenyataan bahwa mereka tidak menyentuh, hampir seluruh inti dari transaksi proses bisnis untuk uang.
Secara alami, hal pertama yang kami pikirkan adalah bagaimana membedakan antara bidang pembangunan. Saya juga akan membicarakan ini secara terpisah, tetapi secara umum, skemanya adalah sebagai berikut:
Horisontal adalah area bisnis. Misalnya, segala sesuatu yang terkait dengan hubungan pelanggan (sel hijau pertama) adalah satu area, dan ada satu set aplikasi dari satu departemen. Pemisahan fungsi tujuan ini menciptakan beberapa duplikat kode di tempat yang berbeda dan membutuhkan bus perusahaan yang baik (sekali lagi, cerita yang terpisah), tetapi ini memungkinkan Anda untuk dengan jelas menemukan ujungnya dan menyelesaikan masalah hingga hasilnya. Melihat ini setelah hampir tiga tahun, saya dapat mengatakan bahwa arsitektur dipilih dengan benar, tetapi jika saya tahu apa yang saya ketahui sekarang, saya akan membuat beberapa perubahan.
Sekarang kita sampai pada kesimpulan bahwa dalam struktur umum ada banyak tim fitur yang membentuk tim produk besar. Pada saat yang sama, tim produk tidak hanya mencakup pengembang itu sendiri, tetapi juga desainer dan perwakilan bisnis. Karena tujuan akhir dari setiap departemen TI perusahaan adalah untuk meningkatkan kecepatan pengembangan bisnis, atau untuk mengurangi biaya karena otomatisasi, kami memerlukan perwakilan bisnis dalam tim ini. Ritel adalah semua tentang IT. Tidak ada satu proses pun yang bisa disebut "tidak dapat didekati."
Tim fitur adalah sekelompok kecil orang (biasanya analis, penguji, pengembang back-end dan pengembang front-end, ops). Analis biasanya memainkan peran sebagai pemilik produk atau seseorang dari bisnis datang ke tempat ini. Pemilik memiliki jaminan simpanan, prioritas, tugas. Dia menentukan perkembangan mereka. Pengembang memilih sendiri opsi implementasi, berdiskusi dalam tim apa yang akan dilakukan dan bagaimana caranya. Kami tidak memiliki pemimpin tim untuk penilaian tugas, pengkodean, dan pengambilan keputusan. Setiap orang melakukan segalanya. Biasanya anggota tim yang lebih berpengalaman memberikan pendapat yang banyak bergantung pada mereka. Tapi siapa pun bisa mengambil keputusan. Tentu saja, ada konflik ketika dua pengembang tidak dapat menyetujui implementasi fitur. Jika konflik berubah menjadi kepribadian - Anda perlu eskalasi ke kepala. Tetapi sebagian besar adalah pilihan solusi untuk implementasi. Kemudian semua orang berdiri dan mendekat ke papan sampai mereka menemukan opsi yang cocok untuk semua orang. Biasanya ternyata cepat, tetapi ada kasus ketika mereka berdebat sepanjang hari. Ketika argumen macet, wasit sering dipanggil - orang dari tim lain yang pendapatnya dipercaya semua orang. Mereka menjelaskan esensi masalah, dia memecahkan. Bahkan seorang juni atau trainee dapat berpartisipasi dalam teori dalam perselisihan ini, tetapi saya hanya tahu beberapa kasus seperti itu - biasanya para joon memiliki seorang mentor yang mereka dengarkan.
Contoh tim fitur: kami memiliki platform layanan yang memungkinkan Anda membeli layanan dengan kontraktor beserta barang. Sebagai contoh, saya membeli pintu - Anda dapat segera memasukkan keranjang dan instalasi, sehingga master independen datang dan melakukan sesuai dengan standar kami. Kami akan memeriksa dan membayar, memberikan jaminan. Jadi, tim ini membuat produk, untuk ini ia menulis solusi TI dan membuat keputusan bisnis, mengubah proses di toko. Setuju dengan kontraktor. Di sana - pemilik produk dari bisnis, pegawai toko, arsitek, pengembang, analis, dan penguji. Mereka segera menggunakan platform API perusahaan kami untuk mengirimkan semua data bolak-balik dan menulis layanan mikro. Pendekatan semacam itu - orang-orang bisnis dan bisnis yang segera beroperasi dalam hubungannya dengan pengembang dan tim kecil - memungkinkan Anda untuk dengan cepat membuat produk. Tapi, saya pikir, lebih baik mereka sendiri nanti memberi tahu Anda bagaimana tampilannya dari dalam.
Awalnya, kami tidak ingin melakukan penguji terpisah: ada kecenderungan bahwa pengembang harus mengikuti metodologi TDD atau menguji sendiri kodenya. Sebenarnya, itu tidak terlalu efektif. Pada awalnya semuanya berjalan dengan baik: menulis - Anda menjawab. Anda perlu tes agar aplikasi Anda berfungsi dengan benar. Tetapi kemudian, semakin banyak tugas dan aplikasi menjadi, semakin sulit. Beberapa aplikasi mati, beberapa pergi ke prod dan tidak berubah selama berbulan-bulan. Menjadi sulit untuk menulis ujian, mempertahankannya, dan sebagainya. Analis tim telah berubah. Baru-baru ini, mereka sepakat bahwa mereka salah: penguji diperlukan. Tetapi pengembang tidak berhenti menulis tes dan - terkadang - melakukan TDD. Kami menyadari sendiri bahwa tes yang memeriksa fungsionalitas (aplikasi berfungsi dengan benar) dan tes yang memverifikasi bahwa aplikasi berfungsi dalam situasi bermasalah harus dilakukan oleh orang yang berbeda. Dan untuk yang kedua, penguji diperlukan, karena mereka mencakup kemungkinan kasus aneh tidak hanya dengan tes unit.
Sekarang ada 60 pengembang murni - belakang, depan, tumpukan penuh. Ada juga analis, penguji, dan dukungan. Dan ditambah tujuh devops lagi. Tapi tetap saja, 200 orang yang direncanakan dari jabatan tersebut tidak direkrut, jadi kami sekarang mencari orang baru, karena bidang pekerjaannya sangat besar. Ada lowongan di
lingkaran Saya , jika itu. Artinya, dari pengembangan kami sekarang memiliki 74 dari sekitar 200.
Sumber Daya Dalam
Mengingat kami memiliki banyak tim independen hanya di Rusia, dan masih ada tim yang melihat hal serupa di banyak negara lain, kami bergerak ke arah sumber daya
losmen . Ini sangat mirip dengan open source dalam kelompok orang terbatas.
Dalam grup ADEO dari semua divisi negara, semua kode terletak di cloud github. Proyek ini disusun sesuai dengan aturan desain yang seragam. Tidak ada batasan pada gaya, teknologi dan peralatan. Saat Anda memiliki kode sumber terbuka dan aturan desain yang jelas, pengembang mana pun di stack dapat berkontribusi. Untuk menyalin Anda ke dalam kode, Anda perlu membaca dok, mengkloning repositori, melakukan edit, mengirim permintaan tarik.
Saat ini, Brasil, Rusia dan Prancis sangat aktif menggunakan pangkalan bersama ini.
Kami sekarang mencoba untuk mentransfer seluruh kode kontraktor (dan kami memiliki banyak dari mereka dalam arah yang berbeda) ke InnerSource. Dalam analisis, kami membuat peta pada dua sumbu: kompleksitas teknis transfer ke mode lingkaran dalam pada satu sumbu dan sumbu kedua, seberapa besar transfer ke lingkaran dalam berguna secara umum. Jika kode ini unik dan hanya diperlukan di satu tempat - mungkin Anda bahkan tidak harus menyentuhnya. Tetapi jika banyak tim menggunakan situs ini - itu pasti perlu.
Semua ini umumnya meningkatkan budaya pembangunan. Dan itu mempercepat kecepatan beberapa tim, karena Anda dapat menulis permintaan gabungan untuk fitur apa pun yang Anda butuhkan. Ini akan disesuaikan oleh tim pemilik, dan diuji oleh orang yang menjadi kontributor. Salah satu syarat penting adalah ketersediaan autotest dan deskripsi kode apa pun di repositori.
Beberapa nuansa lagi
Ketika mereka mulai, tidak ada sama sekali. Sejalan dengan para pengembang, mereka merekrut devops. Sekarang layanan devob dapat diberikan sebagai layanan (untuk mereka yang membutuhkannya), atau tim produk memiliki operasi sendiri, yang telah menentukan apa dan bagaimana.
Perakitan dilakukan di Jenkins, kode dijalankan di Sonar (lebih tepatnya, sudah SonarQube). Sonar gagal - tidak ada rilis. Penguji menulis autotest, pemilik kode - tes fungsional. Basis data diberikan sebagai layanan oleh insinyur infrastruktur. Pengujian beban penuh dilakukan dalam kasus yang jarang terjadi, karena struktur dasar uji dan yang utama berbeda: pada preprod, kami memiliki data kacau, dan bukan data nyata yang dianonimkan (ini adalah salah satu langkah di masa depan), jadi Anda perlu menggulungnya dengan lembut dan tidak sekaligus.
Segera kita harus pergi ke Kubernetes (dan beberapa produk baru seperti
pasar sudah ada di sana pada awalnya), segera setelah kita mengetahui rencana transisi dan menyepakati semua detail dalam infrastruktur.
Rekan-rekan saya dan saya akan terus berbicara tentang bagaimana bagian pekerjaan itu diatur, karena hampir di mana-mana Anda dapat melanjutkan tanpa batas. Nah, Anda dapat mengikuti reality show kami (karena semuanya dibangun dan berubah dengan cepat) dan bertaruh apakah kami mengacaukannya atau tidak.