Peluncuran Bertahap untuk Pengembang Plugin & Tema WordPress: Menghindari “Rilis Clusterbug”
Diterbitkan: 2020-12-23Apakah Anda ingat kapan terakhir kali Anda merilis versi baru dari plugin atau tema WordPress Anda untuk segera menemukan bahwa Anda keliru menambahkan bug utama baru yang menyelinap melalui retakan urutan pengujian Anda?
Yoast SEO 3.0 memecahkan banyak situs web pada tahun 2015. Elementor 3.0 melakukan hal yang sama tahun ini. Dan itu hanya dua contoh dari atas kepala saya tentang perusahaan fantastis di ruang kita dengan 100+ karyawan dan personel QA yang berdedikasi (dan tidak, itu tidak terkait dengan versi 3.0, tapi mungkin itu pertanda untuk melewati versi itu di perangkat lunak Anda ; )).
Apakah Anda seorang pembuat kode otodidak atau insinyur perangkat lunak, pengembang indie, atau bagian dari toko plugin/tema besar, kita semua harus berurusan dengan bug. Ini adalah bagian tak terelakkan dari pengembangan perangkat lunak.
Apa pun otomatisasi pengujian CI/CD/pengujian yang Anda terapkan – Anda tidak akan pernah bisa menguji semuanya. Jumlah konfigurasi server (PHP, MySql, caching, web server), versi WP, kombinasi plugin dan tema… semuanya tidak ada habisnya.
Dan itu berlawanan dengan intuisi. Semakin populer & stabil produk Anda, semakin tinggi peluang rilis "Clusterbug" yang ditakuti, yang akan menguras dukungan Anda, dapat secara signifikan memengaruhi kepercayaan & loyalitas pelanggan Anda, dan berpotensi merusak reputasi merek secara keseluruhan.
Meskipun Anda tidak dapat menghindari bug, Anda dapat, dan yang paling pasti, mengurangi risiko sebanyak yang Anda bisa.
Jika Anda memiliki ponsel cerdas, Anda mungkin memperhatikan bahwa beberapa teman Anda mendapatkan pembaruan Android/iOS berhari-hari, berminggu-minggu, kadang-kadang bahkan berbulan-bulan sebelum Anda mendapatkannya. Itu bukan kebetulan, dan tidak, itu bukan masalah pribadi terhadap Anda. Ini adalah proses penerapan progresif yang disengaja yang disebut Peluncuran Bertahap yang membantu perusahaan seperti Apple mengirimkan pembaruan perangkat lunak utama ke lebih dari satu miliar perangkat.
Ya, satu miliar!
Bisakah Anda memahami jumlah tanggung jawab yang akan ditanggung oleh pemimpin versi di Apple jika mereka harus mendorong pembaruan langsung ke 1,5 miliar perangkat seluler secara bersamaan? aku tidak bisa. Saya yakin tidak ada orang waras yang setuju untuk memikul tanggung jawab seperti itu.
Jadi, bagaimana mekanisme Staged Rollouts bekerja? Bagaimana Anda bisa menerapkannya? Dan apa yang WordPress.org tunggu? Ini adalah topik yang akan saya bahas di bawah.
Apa itu Peluncuran Bertahap untuk Plugin & Tema WordPress?
Peluncuran Bertahap memungkinkan Anda menentukan jumlah (atau persentase) situs web yang ingin Anda luncurkan versi barunya. Mekanisme Peluncuran Bertahap memungkinkan Anda untuk memulai siklus rilis Anda dengan eksposur terbatas dan kemudian meningkatkannya secara bertahap saat Anda memantau dukungan & umpan balik, sehingga membangun kepercayaan dalam rilis Anda untuk Anda dan pengguna Anda.
Apa Manfaat Peluncuran Bertahap?
Alih-alih mempertaruhkan seluruh basis instalasi Anda dengan rilis bug potensial, konflik dengan plugin/tema pihak ke-3, atau bahkan masalah UI/UX, Anda dapat merilis versi secara progresif, meminimalkan jumlah orang dan situs web yang akan terkena masalah tak terduga. Setelah Anda menyelesaikan semua masalah dan bug yang ditemukan selama proses peluncuran, sebagian besar pengguna Anda akan terpapar ke versi "dewasa" dan jauh lebih stabil.
Kami menggunakan pembaruan bergulir untuk memastikan kualitas rilis baru kami. Jika ada masalah dengan rilis baru, kami dapat mengidentifikasinya dengan cepat, dan hanya sebagian kecil pengguna yang akan terpengaruh.
John Turner, Pendiri di SeedProd
Menggunakan Peluncuran Bertahap adalah praktik terbaik untuk merilis perangkat lunak secara bertanggung jawab – sebuah proses yang diikuti oleh banyak perusahaan (berapa pun ukurannya) di luar gelembung WP.
Ada peluang besar bagi komunitas WordPress untuk memanfaatkan Peluncuran Bertahap, yang akan saya bahas sebentar lagi.
Apakah Program Beta Mirip dengan Peluncuran Bertahap?
Menyiapkan program Beta untuk produk WordPress Anda adalah awal yang baik, tetapi jauh dari seefektif Peluncuran Bertahap, dan memiliki tujuan & dinamis yang berbeda secara fundamental.
Kecuali jika plugin atau tema Anda sangat populer dan memiliki komunitas yang besar, cukup sulit untuk merekrut grup beta yang cukup secara statistik karena hanya sebagian kecil pengguna yang tertarik untuk bergabung. Bahkan jika Anda unggul dalam merekrut sekelompok penguji beta yang layak, Anda harus mengandalkan ketersediaan & niat baik mereka untuk menguji produk, dan kemudian berharap mereka melakukan upaya ekstra untuk melaporkan masalah yang mereka temukan.
Berapa banyak orang yang menurut Anda akan melihat melalui seluruh proses ini? Tidak banyak.
Pengujian beta adalah proses pra-produksi di mana upaya dukungan Anda dikontrol sepenuhnya dan penguji memperkirakan akan mengalami masalah dengan rilis beta. Oleh karena itu, harapan penguji tentang kualitas tidak mewakili sentimen umum basis pengguna Anda.
Selain itu, program Beta yang bertanggung jawab akan memperingatkan pengujinya untuk menghindari penggunaan versi beta di lingkungan produksi, jadi pengujian beta tidak benar-benar mensimulasikan situs web produksi langsung.
Bagaimana Mengelola Rilis Peluncuran Bertahap untuk Plugin atau Tema WordPress Anda?
Sebagai bagian dari penelitian saya tentang Peluncuran Bertahap, saya berkesempatan untuk bertemu dengan Amir Helzer dan belajar dari pengalaman mereka selama 2+ tahun menggunakan Peluncuran Bertahap dengan WPML dan Toolset, plugin yang berjalan di lebih dari 1.000.000 situs web WordPress.
Inilah yang dibagikan Amir tentang implementasi Peluncuran Bertahap mereka:
Ketika sebuah situs web menginstal salah satu plugin kami, kami menggambar angka acak antara 1 hingga 100 dan menyimpannya di database situs untuk diingat. Metode ini pada dasarnya membagi situs web menjadi 100 tempat sampah secara acak.
Saat rilis siap untuk ditayangkan, rilis hanya akan tersedia secara bertahap untuk satu nampan yang dipilih. Setiap hari kami meningkatkan eksposur rilis ke 5% tambahan situs web di tempat sampah yang ditentukan. Dan perbaiki dan tambal masalah yang akan datang saat kami pergi.
Untuk mendiversifikasi lingkungan menggunakan versi yang diperbarui dan menghindari "korban" rilis awal yang sama berulang kali, Amir menegaskan bahwa setiap rilis baru masuk ke bin pengguna yang berbeda terlebih dahulu.
Pendekatan ini juga berarti bahwa siklus rilis rata-rata membutuhkan waktu sekitar satu bulan untuk tersedia bagi setiap pengguna.
Butuh waktu hingga orang melihat rilis baru yang tersedia di WP Admin dan memperbarui versi mereka. Dan bahkan setelah mereka melakukannya, perlu waktu berhari-hari sampai mereka menemukan masalah.
Dengan ukuran audiens kami, mau tidak mau, setiap rilis memiliki beberapa masalah. Tujuan utama kami adalah memastikan bahwa kami menghindari munculnya masalah baru, dan jika kami melakukannya, kami memiliki proses yang andal untuk menyelesaikannya.
Siklus rilis memang panjang, tetapi bahkan jika, dalam skenario terburuk, ada beberapa bug gila yang kami lewatkan dalam pengujian, 95% pengguna kami bahkan tidak mengetahui semua drama, karena mereka tidak terpapar pada rilis sampai stabil.
Amir juga menekankan pentingnya sinkronisasi dengan seluruh tim sebelum rilis, terutama dukungan dan pengembangan pelanggan. Dengan cara ini, anggota tim dapat memberikan fokus ekstra pada tiket yang dipicu karena masalah yang terkait dengan rilis yang sedang berlangsung, dengan tujuan untuk memeriksa, mengonfirmasi, dan memperbaiki masalah yang valid serta merilis patch secepat mungkin.
Kami memiliki tiga tingkatan dukungan di tim kami. Tingkat 1 akan melihat masalahnya, memvalidasinya sebenarnya adalah masalah yang terkait dengan rilis plugin dengan mereproduksinya. Ketika sebuah kasus tampaknya terkait dengan rilis baru, ia menuju ke tingkat 2, yang akan men-debug masalah untuk memvalidasi bahwa kasus tersebut memang terkait dengan rilis dan menemukan bagian yang relevan dalam kode yang memicu masalah. Jika divalidasi, pengembang yang bertanggung jawab atas kode tersebut akan segera diberi tahu untuk memprioritaskan perbaikan.
OnTheGoSystems adalah perusahaan besar dengan hampir 100 karyawan, jadi masuk akal jika mereka menyempurnakan proses Peluncuran Bertahap mereka. Namun, bahkan sebagai pengembang produk tunggal dengan satu tingkat dukungan (Anda & diri Anda sendiri), wawasan Amir dapat mengajarkan kita bahwa sangat penting untuk mengalokasikan sumber daya khusus untuk rilis. Ini adalah praktik yang baik untuk memprioritaskan tiket dukungan yang bahkan "berbau" terkait dengan rilis baru Anda dan mengurangi paparan dari masalah baru sebanyak mungkin.
Mengapa (hampir) Tidak Ada Plugin atau Tema yang Mendukung Peluncuran Bertahap?
Dalam persiapan menulis artikel ini, saya mencoba meminta komunitas untuk melihat siapa yang menggunakan peluncuran bertahap untuk mendapatkan umpan balik tentang pengalaman mereka, apa yang mereka pelajari, dll.
Tidak mengherankan, saya hanya menemukan dua perusahaan WordPress di jaringan saya yang telah menyiapkan Peluncuran Bertahap sebagai bagian dari siklus rilis mereka. Banyak pengembang bahkan tidak mengetahui konsepnya, dan sisanya tidak menggunakannya karena solusi distribusi mereka tidak mendukungnya (atau mereka mungkin berpikir untuk mengembangkannya dan tidak punya waktu).
Sebagian besar pengembang plugin dan tema yang tidak menjual melalui Freemius menjual dari situs web mereka melalui EDD atau WooCommerce, yang keduanya tidak mendukung Peluncuran Bertahap. Mereka yang menjual melalui pasar seperti CodeCanyon dan ThemeForest juga tidak memiliki solusi out-of-the-box, dan kemungkinan besar tidak akan pernah memilikinya.
Bahkan pengembang yang mengetahui konsep tersebut tidak memiliki pilihan selain mengembangkan mekanisme mereka sendiri untuk mendukung Peluncuran Bertahap. Pengembangan infrastruktur ini biasanya sangat sulit untuk diprioritaskan dalam perusahaan produk.
Berlangganan dan dapatkan salinan gratis dari kami
Buku Bisnis Plugin WordPress
Tepatnya bagaimana membuat bisnis plugin WordPress yang makmur dalam ekonomi berlangganan.
Berbagi dengan teman
Masukkan alamat email teman Anda. Kami hanya akan mengirim email kepada mereka buku ini, scout's honor.
Terima kasih sudah berbagi
Luar biasa - salinan 'Buku Bisnis Plugin WordPress' baru saja dikirim ke . Ingin membantu kami menyebarkan berita lebih banyak lagi? Ayo, bagikan buku ini dengan teman dan kolega Anda.
Terima kasih telah berlangganan!
- kami baru saja mengirimkan salinan 'Buku Bisnis Plugin WordPress' Anda ke .
Ada salah ketik di email Anda? klik di sini untuk mengedit alamat email dan mengirim lagi.
Bagaimana Peluncuran Bertahap Memberi Anda Keuntungan Komersial?
Karena hampir tidak ada yang memanfaatkan Peluncuran Bertahap saat ini, jika Anda mulai memanfaatkan Peluncuran Bertahap dan memasarkannya dengan benar di situs web Anda untuk memberi tahu pengunjung bahwa Anda memiliki siklus rilis yang bertanggung jawab, ini pasti memberi Anda keunggulan kompetitif dan meningkatkan kepercayaan pada produk Anda /merek!
Jika Anda menganalisis pasar dari perspektif pengembang, Anda akan melihat bahwa banyak pengembang mengikuti pesaing mereka dan biasanya menetapkan harga mereka dalam kisaran harga pasar secara vertikal, yang mengarah ke produk WordPress pesaing yang menawarkan fitur serupa dalam kisaran harga yang sama.
Dari sudut pandang pembeli, itu berarti sering kali terjadi kebingungan tentang produk mana yang harus dibeli karena semuanya memiliki fitur dan harga yang sebanding. Namun, ketika Anda mengevaluasi beberapa plugin dengan biaya yang sama dan, memberi atau menerima, memiliki fitur yang sama, tidakkah Anda akan cenderung memilih produk yang menawarkan Peluncuran Bertahap mengetahui bahwa rilis produksinya harus lebih stabil daripada pesaing?
Peluncuran Bertahap meningkatkan kepercayaan pada produk dan bisnis Anda. Ini adalah keunggulan yang dapat Anda manfaatkan sebelum Peluncuran Bertahap menjadi praktik standar (yang saya harap mereka benar-benar melakukannya).
Freemius Sekarang Mendukung Peluncuran Bertahap untuk Plugin & Tema Berbayar
Kami sangat antusias untuk merintis Peluncuran Bertahap di plugin dan ekosistem tema WordPress premium. Mitra penjualan kami sekarang dapat merilis pembaruan dengan aman, percaya diri, dan andal, dengan dampak minimal kepada pengguna atau sumber daya dukungan/pengembangan mereka.
Kami tahu betapa menantang dan menegangkannya rilis utama, terutama karena selalu ada potensi risiko yang berdampak negatif pada merek Anda setelah rilis "Clusterbug".
Dengan Peluncuran Bertahap, ada jaring pengaman untuk keberlanjutan & ketahanan merek mitra kami, dan mengurangi tekanan yang tidak perlu yang terkait dengan rilis ke basis pengguna yang besar.
Ini berjalan beriringan sebagai manfaat bagi pelanggan mitra kami. Ketika pengguna membeli produk yang dijual melalui Freemius, mereka sekarang dapat memiliki keyakinan bahwa mereka memilih solusi yang didukung oleh Peluncuran Bertahap dan mereka dapat mengharapkan rilis yang jauh lebih stabil dari plugin dan tema premium yang menggunakan mekanisme tersebut.
Jika Anda menjual dengan Freemius, berikut cara menggunakan mekanisme Peluncuran Bertahap kami dengan benar.
Bagaimana Freemius Mengimplementasikan Peluncuran Bertahap?
Setiap situs web yang mengaktifkan lisensi untuk membuka kunci plugin atau tema premium mendapatkan catatan di database kami. Hal pertama yang kami lakukan adalah memperkenalkan properti last_served_update_version baru untuk menyimpan versi produk terbaru yang tersedia untuk situs web.
Kemudian, kami memperkaya tabel yang bertanggung jawab untuk menyimpan data rilis dengan dua properti baru: limit , uniques .
Saat pengembang menandai versi sebagai dirilis, mereka akan diminta dengan dialog berikut, memungkinkan mereka untuk mengatur persentase (atau jumlah) situs web yang memiliki lisensi aktif yang mereka inginkan untuk meluncurkan versi berbayar:
Jika mereka menetapkan peluncuran rilis terbatas, sistem akan menghitung total situs web aktif dengan lisensi aktif dan kemudian menetapkan properti limit baru dari rilis yang sesuai.
Terakhir, kami memperbarui titik akhir API yang dipanggil oleh situs web untuk memeriksa apakah ada rilis baru dan memperkenalkan logika berikut (dalam kode semu):
latest_version = load latest version of product X
If (website is on latest_version)
return “no new version”
If (last_served_update_version of website same as latest_version)
return “no new version”
If (latest_version is limited)
If (latest_version is limited AND uniques >= limit)
return “no new version”
previous_version = load the previous version of product X
If (previous_version is limited too AND uniques <= previous_version.uniques)
If (website not using previous_version AND
last_served_update_version different from previous_version)
return “no new version”
else If (random({true, false}) )
return “no new version”
Set last_served_update_version of website to latest_version
Increment uniques by 1
return latest_version
Algoritma ini memastikan bahwa:
- Eksposur rilis dibatasi sesuai dengan persentase peluncuran yang ditetapkan.
- Jika versi sebelumnya masih dipentaskan, yaitu, tidak pernah diekspos ke seluruh basis penginstalan, situs web yang menerima rilis bertahap sebelumnya akan diekspos ke rilis bertahap terbaru terlebih dahulu.
Tidak seperti arsitektur Staged Rollouts WPML yang memastikan setiap rilis akan masuk ke subset berbeda dari basis instal mereka menggunakan nampan logis, implementasi kami bergantung pada keacakan. Jadi, sebuah situs web mungkin mendapatkan dua rilis tahap awal dalam dua siklus rilis berturut-turut. Namun, manfaat pendekatan ini adalah kami dapat mengirimkan Peluncuran Bertahap ke semua pelanggan mitra kami tanpa perlu mendorong pembaruan SDK, yang dapat memakan waktu berbulan-bulan, bahkan bertahun-tahun, untuk disebarkan ke semua pelanggan.
Mengapa Peluncuran Bertahap Penting untuk Masa Depan WordPress?
Ketika saya bertanya kepada Amir apa pemicu mereka untuk mengembangkan Peluncuran Bertahap untuk siklus rilis WPML, inilah yang dia katakan kepada saya:
3 tahun yang lalu, di WordCamp Europe, saya menghabiskan waktu mengobrol dengan pelanggan WPML untuk mengumpulkan semua jenis umpan balik tentang keseluruhan pengalaman mereka. Frustrasi #1 yang saya temukan adalah bahwa pelanggan kami takut untuk memperbarui plugin karena hal itu dapat merusak situs mereka secara tidak terduga.
Amir Helzer,
Pendiri OnTheGoSystems (WPML, Toolset)
Saya benar-benar berhubungan dengan itu.
Kebijakan internal kami di Freemius dalam hal memperbarui plugin & tema adalah… jangan! Dengan dua pengecualian: Jika ada masalah keamanan yang diketahui atau fitur yang tersedia dalam versi yang lebih baru yang kami perlukan untuk situs kami.
Kebijakan pembaruan kami "ditulis dengan darah" setelah beberapa insiden pembaruan yang salah dan menyebabkan sakit kepala dan pemborosan waktu yang tidak terduga, mengganggu operasi dan jadwal kami. Dan ya, kami dapat menghindari beberapa tekanan dengan lingkungan pementasan, tetapi ini tidak akan menghemat waktu & kerumitan kami jika kami masih ingin mengejar pembaruan ke produksi.
WordPress telah berkembang sedikit sejak saat itu, dan sekarang kami memiliki penonaktifan otomatis pada kegagalan plugin. Namun, itu tidak berlaku untuk tema dan penonaktifan plugin mission-critical untuk situs web kami masih menjadi masalah besar.
Intinya adalah jika saya, sebagai pengembang plugin dan CEO dari sebuah perusahaan yang membantu ribuan pengembang plugin & tema mengembangkan bisnis mereka, khawatir akan merusak situs kami setiap kali kami memperbarui plugin atau tema di situs kami, maka itu berarti sebagian besar pengguna tidak percaya diri dalam memperbarui perangkat lunak di ruang kami.
Kurangnya Peluncuran Bertahap menahan kami dan seluruh ekosistem WP dan memberi solusi bersaing berbasis SaaS keuntungan yang cukup besar. Pengguna WiX dan Shopify tidak perlu memikirkan pembaruan sama sekali! Pembaruan terjadi begitu saja untuk mereka di latar belakang, dan perangkat lunak mereka selalu mutakhir, dari segi keamanan & fitur.
Kurangnya Peluncuran Bertahap menahan seluruh ekosistem WP dan memberi solusi berbasis SaaS keuntungan yang cukup besar. Pengguna WiX dan Shopify tidak perlu memikirkan pembaruan perangkat lunak – pembaruan terjadi begitu saja di latar belakang. Tweet
Jika Anda menonton State of the Word minggu lalu, salah satu pendiri WordPress, Matt Mullenweg, jelas memahami pentingnya perangkat lunak terkini. Inilah visi Matt untuk pembaruan WP:
… memungkinkan Anda untuk ikut serta dalam pembaruan otomatis untuk Core. Ini adalah langkah pertama untuk tujuan kami memungkinkan WordPress Anda pada dasarnya mempertahankan dirinya sendiri, ketika Anda dapat mengaturnya dan melupakannya, dan itu akan otomatis, di latar belakang dan pembaruan tanpa kerumitan untuk semua plugin, tema, dan inti Anda. Tweet
Satu-satunya cara saya dapat membayangkan WordPress menjadi "setel dan lupakan" adalah jika pembaruan perangkat lunak dapat lebih andal dan dapat dipercaya, dan itu hanya dapat terjadi dengan Peluncuran Bertahap.
WordPress.org: Inilah Bagaimana Anda Dapat Memperkenalkan Peluncuran Bertahap untuk Plugin dan Repositori Tema
Mirip dengan implementasi kami, dua opsi meta baru perlu ditambahkan ke setiap plugin dan rilis tema di database WordPress.org: limit dan uniques .
Pengeditan opsi meta limit dapat diekspos di Tampilan Lanjutan untuk pemilik yang dicatat (dan mungkin untuk pembuat lainnya):
Pengembang akan memiliki cara untuk mengontrol eksposur setiap rilis, serta kemampuan untuk menetapkan batas untuk rilis berikutnya.
Karena WordPress.org tidak menyimpan data terstruktur untuk setiap situs web yang menerima pembaruan dari WordPress.org, alih-alih menyimpan versi terbaru "terlihat" oleh situs web di database WordPress.org, penyimpanan data dapat didelegasikan ke situs web . Ini berarti bahwa 'update_plugins' sementara dan data yang dikirim ke WordPress.org API saat memeriksa pembaruan perlu diperkaya dengan last_served_update_version .
Terakhir, titik akhir API pembaruan WordPress.org dapat diperkaya dengan logika yang sama yang kami gunakan untuk implementasi Peluncuran Bertahap Freemius. Alih-alih mengandalkan last_served_update_version dari database wp.org, mekanismenya akan bergantung pada nilai yang dikirim dari situs web oleh inti.
Mudah-peasy, bukan?
sedang Mempekerjakan 
Mari Kembalikan Kepercayaan Pengguna untuk Menekan Tombol Perbarui
Kita semua ingin melihat WordPress berhasil dan terus tumbuh lebih besar dan lebih baik!
Dengan begitu banyak sumber daya yang masuk ke Gutenberg, jelas bahwa kepemimpinan WordPress mengakui bahwa kami harus membuat platform lebih mudah diakses oleh Joe non-teknisi rata-rata. Masalahnya adalah selama pembaruan perangkat lunak tidak dapat dipercaya, bahkan dengan Gutenberg dan semua pembuat halaman luar biasa yang kami miliki, orang non-teknisi akan melarikan diri ke Wix pada pembaruan pertama yang rusak, dan saya tidak dapat menyalahkan mereka.
Saya memanggil pendiri EDD, Pippin Williamson, CEO WooCommerce, Paul Maiorana, dan tim WordPress.org: Kami memiliki peluang untuk membuat ekosistem plugin & tema jauh lebih stabil untuk komunitas WordPress yang lebih besar. Mari kita memungkinkan pengguna untuk menjaga perangkat lunak mereka tetap aman & up to date dengan lebih sedikit rasa takut & frustrasi. Meskipun mungkin tidak terlihat seperti prioritas tinggi dalam jangka pendek, saya yakin kita semua akan mendapat manfaat darinya dalam jangka panjang.