Sürü Kedileri — WordPress Ortamı için Geliştirme Sırasında Öğrenilen Dersler

Elementor 3.0 bir yıldan uzun bir süre önce, 2020'de piyasaya sürüldüğünde, bunu daha hızlı ve önemli ölçüde daha güçlü bir editöre doğru önemli bir adım olarak gördük. Bu doğru olsa da, bu sürümün önemli, beklenmedik sonuçları da oldu - önemli sayıda sitenin çalışmasını durdurmasına ve açıkçası itibarımıza zarar vermesine neden oldu. Bu sürümden sonra, bu sitelerin tekrar çalışmasını sağlamak için bir dizi düzeltme yapmamız gerekiyordu. Ayrıca, tüm deneyim bize tüm test ve sürüm prosedürümüzü elden geçirmemiz gerektiğini gösterdi. Acı verici olsa da, v3.0 ve v3.4 sürümlerimizin piyasaya sürülmesi arasındaki sorunlarda, özellikle kritik olanlarda görülen olağanüstü düşüşün yansıttığı gibi, bu süreç bugün meyvesini veriyor:

Şimdi, Elementor 3.0'ın birinci yıl dönümüne yaklaşırken, geriye bakmanın ve piyasaya sürülmesine eşlik eden sorunların tekrar meydana gelmemesini sağlamak için uyguladığımız prosedürleri incelemenin tam zamanı. Topluluğumuza karşı olabildiğince şeffaf olmak için 3.0 sürümüyle ilgili konuların arka planını, geçen yıl attığımız adımları, kararlı sürümleri nasıl sağlayabildiğimizi ve geleceğin neler getireceğini incelemek istiyorum. Ama önce, biraz Elementor tarihini ve WordPress ortamında karmaşık, sofistike bir eklenti geliştirirken karşılaştığımız zorlukları anlamak önemlidir.

Elementor ve WordPress Mücadelesi

Haziran 2016'da Elementor'un ilk sürümünü yayınladığımızda, eklenti geliştirmeyi ve insanların web siteleri oluşturmasına yardımcı olmayı seven birkaç "çocuk"tuk. Bu bizim ilk ürünümüz değildi, WordPress topluluğu tarafından kullanılan birkaç eklenti geliştirmiştik. Ancak Elementor üzerinde çalışırken özel bir şey geliştirdiğimize ikna olduk. Görünüşe göre haklıydık - ilk sürümümüzden sadece birkaç ay sonra on binlerce kullanıcı Elementor'u zaten yüklemişti ve dünya çapında web siteleri oluşturmak için kullanıyordu.

O zamandan beri şirketimiz daha fazla geliştirici, daha fazla kullanıcı ve daha fazla özellik ile her yönden büyüdü. Bu büyümeyle birlikte, önemli ama daha sıradan sorunları bir kenara bırakarak acil sorunlara odaklandığımız için artan teknoloji açığı da dahil olmak üzere bir dizi yeni sorun geldi.

Bu sorunlarla başa çıkmak, WordPress ortamının doğasından kaynaklanan genel zorluk nedeniyle daha da zorlaştı.

Açık bir platform olarak WordPress, geliştiriciler için bir dizi harika avantaj sunar. Yayınları izleyen ve yavaşlatan birkaç engel var. Kavramlar hayal edilir, geliştirilir ve depoya eklenir. Kullanıcılar, bu ürünleri dener, test eder ve yargılar; pazar, hangilerinin başarılı olacağına ve hangilerinin başarısız olacağına karar verir. Ancak, bu hız ve basitliğin bir bedeli var.

WordPress ortamında çok az tekdüzelik vardır ve düzenli bir iş akışı yoktur. Web yaratıcıları, çok çeşitli eklentiler, temalar vb. kullanırken sitelerinin ortamını tanımlamakta özgürdür. Bu, WordPress sitelerinin sayısız eklenti, tema ve sunucu yapılandırması kombinasyonu içerdiği anlamına gelir.

Ek olarak, sürüm sürecinin basitliği ve sağlam dağıtım araçlarının olmaması, WordPress geliştiricilerinin CI/CD, Canary Deployment ve Feature Flags gibi modern sürüm kavramlarından yararlanamayacağı anlamına gelir.

Açıklık, WordPress'in güzelliğinin bir parçası olsa da, site ve sunucu yapılandırmalarının doğası gereği çokluğu, eklenti çakışmalarını ve belirli sunucu sorunlarını hesaba katma konusunda geliştiricilere gerçek bir meydan okuma sunar.

Bizim durumumuzda, Elementor gitgide daha fazla web sitesi için kullanıldığından, tüm bu farklı kombinasyonları destekleme ihtiyacı, yayın planımızı yavaşlatıyor ve hatta yeni özellikler geliştirmek konusunda tereddüt etmemize neden oluyordu. Söylemeye gerek yok, bu durum kabul edilemezdi ve bir şeyleri sarsmamız gerekiyordu.

Eskiyi Bozmadan Yeni Özellikler Geliştirmek

Yukarıdaki tüm faktörler, zaten Elementor'a güvenenlerin çalışmalarını olumsuz etkilemeden gelişmeye ve iyileştirmeye nasıl devam edebileceğimiz ikilemiyle bizi baş başa bıraktı?

Yayın sürecimizde bazı küçük değişiklikler uygulayarak başladık. Elementor 1.5'te geliştiricilere Beta sürümlerine erişim sunmaya başladık. Bunu, bir sürümden önce bu sürümün çok çeşitli eklenti/tema/ortam kombinasyonlarıyla nasıl etkileşime girdiğini gösteren ve herhangi bir uyumsuzluk konusunda bizi erkenden uyaran geri bildirim almamıza izin veren Github ve diğer topluluklar aracılığıyla yaptık. Bu yaklaşım bir süre işe yaradı, ancak Elementor büyüdükçe bunun yeterli olmadığını keşfettik.

Bu zamana kadar beş milyon kurulum eşiğini geçmiştik. İnanılmaz bir başarı olsa da, bu aynı zamanda tüm bu web sitelerinin sorunsuz bir şekilde işlemesinden sorumlu olduğumuz anlamına da geliyordu.

Elementor 3.0'ın piyasaya sürülmesiyle işler sonunda doruğa ulaştı. Bu sürümde, yükleme hızlarını artırmak için DOM öğelerini kaldırarak bazı eski, görünüşte kullanılmayan işlevleri bırakmaya karar verdik. Bu, en azından kısmen, sisteme gereksiz yere yük bindirdiğimize dair haklı şikayetlere yanıt olarak oldu.

Ne yazık ki, bu değişiklik, yükseltme sırasında sildiğimiz koda dayanan bir dizi sitenin bozulmasına neden oldu. Üçüncü taraf geliştiricileri sürece dahil etme çabalarımıza rağmen, bu hatalar keşfedilmemişti ve durumu düzeltmek için hızlı hareket etmemiz gerekiyordu. Sonunda, yükseltmenin bazı bölümlerini isteğe bağlı hale getirerek bunu başardık, ancak topluluğumuzun bazı üyeleri eklentimizin kararlılığına olan güvenlerini sarsmadan önce değil.

Bu deneyim, bizi bir dizi büyük değişiklik yapma amacıyla geliştirme sürecimize uzun ve sert bir şekilde bakmaya zorladı. Süreçlerimiz, bizim büyüklüğümüz ve kurulum tabanımızdaki bir şirket için uygun değildi. İlk ve belki de en belirgin hareket, kalite kontrol ekibimizin boyutunu ve kapsamını artırmaktı, ancak bu yine de bir dizi önemli sorunla boğuşmamıza neden oldu:

• Sayısız site kurulumuyla bir sürümün uyumluluğunu kontrol etme
• Beş milyondan fazla mevcut siteyle geriye dönük uyumluluk sağlama
• Yüzlerce üçüncü taraf Elementor uzantısının uyumluluğunu kontrol etme

Tüm bu sorunlarla başa çıkmak için WordPress dünyasına daha güncel yazılım geliştirme yöntemleri getirmemiz gerekiyordu.

Geri Bildirim Döngüsü

Genel olarak geliştirmenin karşılaştığı en büyük sorunlardan biri, kullanıcıların güncellemeleri yalnızca yayınlandıktan sonra deneyimlemeleridir. Bu, kullanıcılardan herhangi bir geri bildirim aldığımızda bir özelliğin zaten tasarlanmış, geliştirilmiş ve yayınlanmış olduğu anlamına gelir. Bizim durumumuzda, yüzlerce üçüncü taraf eklenti ve eklenti ile uğraşırken, bu geri bildirim döngüsü sorunu daha da önemlidir.

Bu geri bildirim döngüsünü kısaltmanın yollarını ararken, tarayıcı geliştiricilerinin bizimkine oldukça benzer sorunlarla nasıl başa çıktıklarına baktık - ayrıca sayısız üçüncü taraf web sayfası, uygulama, uzantı ve daha fazlasıyla uyumluluk sağlamaları gerekiyor.

Örneğin Google'ın Chrome tarayıcıları için geliştirdiği sistemi inceledik. Geliştiriciler herhangi bir noktada tarayıcının üç sürümüne erişebilir: beta sürümü, geliştirme sürümü ve gece sürümü. Bu, geliştiricilerin yeni Chrome özelliklerine erken bakabilecekleri ve sürüm resmi olarak yayınlanmadan çok önce Google'a geri bildirim vermeye başlayabilecekleri anlamına gelir.

Bu dersleri eklentimize uygulayan Elementor, WordPress deposunda bulunan kendi geliştirici sürümünü – Elementor Beta'yı (Geliştirici Sürümü) yayınlamaya başladı ve tabiri caizse “baskıdan yeni çıkmış” yeni özelliklerimizi kontrol etmek isteyen geliştiricilere yönelikti.

Tabii ki bizim için uyumluluk sorunlarıyla ilgili erken uyarılar almaktan faydalanıyoruz. Geliştirici sürümü, kullanıcıların yalnızca tüm bu yeni özelliklere erişmesine izin vermekle kalmaz, aynı zamanda hataları bildirmek için Github'a doğrudan bir bağlantı bile vardır. Bu, mevcut web sitelerini tehlikeye atmadan sürekli olarak yeni özellikler dağıtabileceğimiz ve bunlar hakkında geri bildirim alabileceğimiz anlamına gelir. Geliştiriciler için bu, kendi uyumluluk sorunlarını önlemeye yardımcı olarak ve ayrıca özellik üzerinde çalışılırken onlara ürün ve teknik geri bildirim sağlama fırsatı vererek, yaklaşan resmi sürümlere önceden hazırlanmalarına olanak tanır.

Geliştirici sürümünün sürümlerinin normal - alfa, beta, RC ve üretim - Elementor sürümlerini geliştirmek için kullanılan bir süreçle paralel olarak çalıştığı belirtilmelidir. Yeni bir özellik geliştirdiğimizde, kullanılabilecek kadar kararlı olur olmaz, ancak henüz alfa aşamasındayken onu geliştirici sürümüne ekliyoruz. Bu şekilde geliştiricilerimiz, özellik beta sürümüne ulaşmadan önce bile bize geri bildirimde bulunabilir. Bu aynı zamanda geliştirici sürümünün henüz beta aşamasına ulaşmamış özellikler içerdiği anlamına gelir.

Esasen beta aşaması, kasıtlı bir hata ayıklama süreci için ayrılırken, geliştirici sürümü, özellikleri en erken aşamalarında dahil ederek daha sık güncellenir.

Piyasaya sürülmesinden bu yana, geliştiriciler sürümü, bir yıldan kısa bir sürede 40 binin üzerinde kurulum elde ederek büyük bir başarı elde etti.

"Deneysel" Özelliklerle Tanışın

Yıllar içinde, geliştiricilerin benimsediği başka bir konsept, özellikle SaaS dünyasında yaygın olan özellik bayraklarıdır. Genel fikir, bu özellik bayraklarının, geliştiricilerin yeni özellikleri test etmeleri ve nasıl çalıştıklarını görmeleri için farklı kullanıcı segmentleri için açıp kapatarak test etmelerine izin vermesidir.

Yukarıda bahsedildiği gibi, 3.0'ın piyasaya sürülmesinden kaynaklanan sorunların çoğu, eski kodu ortadan kaldıran yeni özelliklerden kaynaklanıyordu. Bu tür sorunlardan kaçınmak için, özellik bayraklarına benzer bir yaklaşım benimsemeye karar verdik.

Elementor 3.1 ile başlayarak, yeni özellikleri "deneysel" olarak işaretleyerek daha dikkatli bir şekilde yayınlamaya başladık. Bu, aşamalar halinde yeni özelliklerin tanıtıldığı bir sistemi içerir. Bu sistemde yeni geliştirilen bir özellik “Alpha” olarak işaretlenecektir. Bu, varsayılan olarak tüm sitelerde kapalı olduğu anlamına gelir. Daha kararlı olduğunu kanıtladıkça "Beta" olur, yani artık yeni siteler için varsayılan olarak açık ve mevcut siteler için kapalıdır. Kararlı olduğundan emin olduktan sonra, tüm siteler için varsayılan olarak açıktır. O zaman bile, kullanıcıların sınırlı bir süre için özelliği devre dışı bırakma seçeneği olacak.

Bu sistem, içerik oluşturucuların sitelerinin ihtiyaçlarına göre bu yeni yükseltmeleri seçmelerine veya devre dışı bırakmalarına olanak tanırken, hem özellik kümesine hem de hızına katkıda bulunarak Elementor'u geliştirmeye devam etmemize olanak tanır. Bu aynı zamanda içerik oluşturucuların yeni özellikleri daha dikkatli bir şekilde benimsemelerine izin vererek sitelerini güncellemelerine yardımcı olur.

Uyumluluk Etiketleri

Elementor'un çok aktif geliştirici topluluğunun büyümesi, büyük bir gurur kaynağı oldu ama aynı zamanda kendi zorluklarını da ortaya koydu. Üçüncü taraf geliştiriciler, tümü mevcut teknolojimize dayalı olarak yüzlerce uzantı, tema, kit ve widget oluşturmuştur.

Bu üçüncü taraf eklentilerin geliştiricilerini desteklemek için, API'de yaptığımız değişiklikler ve kullanımdan kaldırmalar hakkında onlara erken bildirimde bulunmak için geliştiricilerin blogunu ve posta listemizi kullandık. Ancak yukarıda da bahsettiğimiz gibi bunun yeterli olmadığını gördük. Yeni sürümlerde yaşadığımız sorunların çoğu, bu üçüncü taraf eklentiler nedeniyle uyumluluk sorunları yaşıyordu. Eklentimiz, teknolojimiz nedeniyle değil, bu üçüncü taraf uyumsuzlukları nedeniyle kararsız olarak görüldü.

Yine, ilham almak için başkalarının ne yaptığına baktık. Bu durumda, WooCommerce ve üçüncü taraf geliştiricilerle çalışma yaklaşımları. 3.1 sürümümüzden başlayarak, üçüncü taraf geliştiricilerin, uzantılarının yeni sürümle uyumlu olduğunu onayladığı bir sisteme başladık (Daha Fazla Bilgi Edinin). Ardından, kullanıcılara Elementor'u yükseltme seçeneği verildiğinde, kullandıkları üçüncü taraf uzantıların bir listesi ve Elementor'un yeni sürümüyle uyumlu olarak onaylanıp onaylanmadıkları sunulur. Bu şekilde kullanıcılar yükseltme hakkında bilinçli bir karar verebilirler.

Daha İyi Bir Geleceğe Doğru

Bu zorlukların ve uyguladığımız değişikliklerin ana hatlarını çizerek, açık kaynaklı ve sürekli değişen bir ortamda dünya çapında kullanım için bir ürün geliştirmenin nasıl bir şey olduğuna dair size bir fikir vermiş olduğumu umuyorum. Bu açık kaynak kültürünün bir parçası olarak, kullanıcı ve geliştirici topluluğumuza karşı şeffaf olmamız çok önemlidir - şirket büyüdükçe ve “kişisel bir dokunuş” sürdürmek daha da zorlaştıkça. Yalnızca kullanıcılarımızın acısı bizim acımız olduğu için değil, Elementor'un mümkün olan en geniş kullanıcı yelpazesine açık, istikrarlı bir araç olarak kalmasının en iyi yolu olduğu için.

Uyguladığımız değişikliklerin Elementor'un büyümesine ve başarısına katkıda bulunduğuna ve katkıda bulunmaya devam edeceğine kuvvetle inanıyoruz. Ancak, hala yapılacak işler olduğunun ve Elementor ile Elementor topluluğu arasındaki iletişimin açık kalması ve hatta geliştirilmesi gerektiğinin de farkındayız. Örneğin, geliştiricilerin Elementor'u özelleştirmesine ve geliştirmesine yardımcı olacak kullanımı kolay belgeler sağlayarak geliştirici kaynak sitemizi yükseltiyoruz.
Ama belki de iletişimi geliştirmek için attığımız en önemli adım, Elementor Topluluk Merkezi'ni kurmaktır. Burada, dünya çapındaki web yaratıcıları birbirleriyle ve bizimle fikir alışverişinde bulunmak için bir araya gelebilir - Elementor'u olabilecek en iyi hale getirmek için birlikte işbirliği yapabilir. Ne de olsa, eski bir deyişin önerdiği gibi, kedileri gütmek neredeyse imkansız olabilir, ancak birlikte çalıştıklarında buna Gurur denir.