Əksər istifadəçilər plagin yeniləməsini çox sadə bir şey kimi görür.
Köhnə versiya var. Yeni versiya var. Update düyməsini basırsan. Problem həll olunmalıdır.
Və çox vaxt məhz belə də olur. Kiçik bir baq düzəlir, yeni bir seçim peyda olur, performans yaxşılaşır, hamı yoluna davam edir. Amma fərqli bizneslər, fərqli hosting provayderləri, fərqli plaginlər, fərqli iş axınları və fərqli texniki təcrübə səviyyəsi olan istifadəçilərin işlətdiyi real bir WordPress məhsulu üzərində işləyəndə tez bir zamanda anlayırsan ki, yeniləmə sadəcə bir versiya nömrəsi deyil.
Plagin yeniləməsi idarə olunmayan bir mühitdə edilən idarə olunan bir dəyişiklikdir.
Onu çətin edən də elə budur.
Bir plagini qurub saxlayanda, xüsusilə də kiminsə gündəlik biznes əməliyyatlarının bir hissəsinə çevrilən bir plagini, sən sadəcə kod göndərmirsən. Sən görüş axınlarına, ödəniş sistemlərinə, müştəri bildirişlərinə, işçi təqvimlərinə, biznes qaydalarına, köhnə parametrlərə, fərdiləşdirmələrə, inteqrasiyalara, bəzən isə hətta bir biznesin gəlirinə toxunursan.
Çöldən baxanda “zəhmət olmasa plagini yeniləyin” sadə bir göstəriş kimi səslənir. Məhsul tərəfindən isə bu, bir proqram təminatının bütün həyat dövründəki ən həssas əməliyyatlardan biri ola bilər.
İstifadəçi düyməni görür, arxasındakı sistemi yox
WordPress-in yeniləmə təcrübəsi qəsdən sadədir. WordPress-in bu qədər populyar olmasının səbəblərindən biri də budur. İstifadəçi plagini deploy proseslərini, verilənlər bazası migrasiyalarını, asılılıq idarəçiliyini və ya uyğunluq testini bilmədən qura, aktivləşdirə və yeniləyə bilər.
O sadəlik yaxşıdır. Çəpəri aşağı salır.
Amma həm də əsl mürəkkəbliyi gizlədir.
Plagin yeniləməsi mövcud olanda istifadəçi adətən bir düymə görür. Lakin o düymənin arxasında yüzlərlə, bəlkə minlərlə dəyişdirilmiş kod sətri ola bilər. Yeni verilənlər bazası sütunları, dəyişdirilmiş klas strukturları, adı dəyişdirilmiş fayllar, yeni asılılıqlar, çıxarılmış köhnə məntiq, təhlükəsizlik təkmilləşdirmələri, uyğunluq düzəlişləri və performans dəyişiklikləri ola bilər.
Plagin kiçikdirsə, risk az ola bilər. Amma plagin rezervasiyaları, ödənişləri, bildirişləri, təqvimləri, işçi əlçatanlığını, müştəri datasını, qaimələri, kuponları, paketləri, iş axınlarını və ya üçüncü tərəf xidmətləri ilə inteqrasiyaları idarə edirsə, onda yeniləmə artıq sadəcə texniki bir əməliyyat deyil.
O, biznes üçün həssas bir əməliyyata çevrilir.
- Yanlış yerdə edilən kiçik bir dəyişiklik görüşlərin necə yaradıldığına təsir edə bilər.
- Çatışmayan bir uyğunluq qatı köhnə add-on-lara təsir edə bilər.
- Uğursuz bir migrasiya illər əvvəl saxlanmış bir parametri sındıra bilər.
- Server konfiqurasiyasındakı fərq test zamanı heç vaxt görünməyən bir baqı üzə çıxara bilər.
- Bir keşləmə plagini yeniləmənin özü düzgün işləsə belə, yeni versiyanı sınıq kimi göstərə bilər.
Məhz buna görə plagin yeniləmələrinə bir çox istifadəçinin gözlədiyindən daha ciddi yanaşmaq lazımdır.
Köhnə data çox vaxt yeni koddan çətindir
Məhsul inkişafında yeni kod yazmaq həmişə ən çətin hissə deyil. Çox vaxt ən çətin hissə yeni kodu köhnə data ilə işlətməkdir.
Bu, xüsusilə WordPress plaginləri üçün doğrudur.
Bu gün ən son versiyanı quran yeni müştəri təmiz bir quraşdırma ilə başlayır. Onun verilənlər bazası strukturu təzədir. Parametrləri ən son formatda saxlanır. Add-on-ları gözlənilən ardıcıllıqla qurulub. Mühiti komandanın test etdiyinə daha yaxındır.
Amma mövcud bir müştərinin tamamilə fərqli bir keçmişi ola bilər.
- O, plagini üç il əvvəl qurmuş ola bilər.
- Uzun bir müddət ərzində versiyadan versiyaya yeniləmiş ola bilər.
- Bəzi yeniləmələri ötürmüş ola bilər.
- Bir neçə add-on qurub silmiş ola bilər.
- Fərdi kod parçaları (snippet) ola bilər.
- İnterfeysin artıq istifadə etmədiyi, amma hələ də verilənlər bazasında qalan köhnə parametrləri ola bilər.
- Köhnə məntiq altında yaradılmış rezervasiyaları, müştəriləri, ödənişləri və iş axınları ola bilər.
Əsl yeniləmə mürəkkəbliyi məhz burada başlayır.
Developer yeni versiyanı təmiz bir quraşdırmada test edə bilər və hər şey mükəmməl işləyə bilər. Amma real müştərilər təmiz quraşdırmaların içində yaşamır. Onlar illərlə yığılan məhsul tarixçəsinin içində yaşayır.
O köhnə tarixçə əhəmiyyətlidir.
Bəzən normalda mətn (string) olmalı bir parametr null kimi saxlanır. Bəzən cədvəl mövcuddur, amma sütunları çatışmır. Bəzən bir add-on əsas plagində yeri dəyişdirilmiş bir klası gözləyir. Bəzən köhnə bir iş axını addımı artıq eyni formatda mövcud olmayan dataya istinad edir. Bəzən istifadəçi əsas plagini yeniləyir, amma əlaqəli add-on-ları yeniləməyi unudur.
Bu halların heç biri nəzəri deyil. Bunlar real proqram məhsullarında baş verən növ məsələlərdir.
Buna görə də yeniləmə testi yalnız təmiz quraşdırmaları əhatə etməməlidir. O, köhnə versiyaları, real yüksəltmə (upgrade) yollarını, fərqli add-on kombinasiyalarını və real dataya bənzər datanı əhatə etməlidir.
Çünki yeniləmə yalnız ideal istifadəçi üçün işləməlidir deyil. O, illərdir məhsulla birlikdə olan istifadəçi üçün də işləməlidir.
Add-on-lar yeniləməni daha güclü, amma həm də daha həssas edir
Modul əsaslı plagin sistemi istifadəçilər üçün əladır. Yalnız ehtiyac duyduqları funksiyaları qurmağa imkan verir. Məhsulu daha çevik edir. Əsas plagini həddən artıq ağır etmədən qabaqcıl funksionallıq üçün yer açır.
Amma add-on-lar həm də yeniləmələri daha həssas edir.
Bir məhsulun əsas plagini və bir neçə add-on-u olanda, yeniləmə artıq yalnız bir paketlə bağlı deyil. O, bir ekosistem yeniləməsinə çevrilir.
- Əsas plagin yeni bir daxili struktur təqdim edə bilər.
- Bir add-on hələ də köhnə strukturdan asılı ola bilər.
- Bir ödəniş şlüzü ən son ödəniş (checkout) məntiqinə ehtiyac duya bilər.
- Bir iş axını add-on-u əsas plaginin hadisə datasından asılı ola bilər.
- Bir SaaS add-on-u əsas plaginin müəyyən bir minimum versiyasını tələb edə bilər.
- Bir fərdi add-on rəsmi add-on-larla eyni sürətdə saxlanmaya bilər.
Bu, bir asılılıq zənciri yaradır.
Hər şey birlikdə yenilənərsə, sistem gözlənildiyi kimi işləyir. Amma yalnız bir hissə yenilənib qalanı köhnə qalarsa, problemlər yarana bilər. Bəzən istifadəçi bunu heç fərq etmir də. O, əsas plagini yeniləyə, amma bir neçə add-on-u köhnə qoya bilər. Sonra bir xəta görür və yeni versiyanın sınıq olduğunu düşünür.
Texniki olaraq problem versiya uyğunsuzluğundan qaynaqlana bilər. Amma istifadəçinin nöqteyi-nəzərindən yeniləmə saytı sındırdı.
Dəstəkdə isə istifadəçinin nöqteyi-nəzəri əhəmiyyətlidir.
Bu, plagin ekosistemlərindəki ən böyük çətinliklərdən biridir: məhsul komandası yalnız ən son versiyanın işləyib-işləmədiyini deyil, həm də istifadəçilərin köhnə kombinasiyalardan yeni kombinasiyalara necə keçəcəyini düşünməlidir.
Yaxşı bir yeniləmə sistemi mümkün olduqda versiya uyğunsuzluqlarını aşkar etməlidir. Aydın xəbərdarlıqlar göstərməlidir. Lazım gələrsə, uyğunsuz kombinasiyaların qarşısını almalıdır. İstifadəçidən daxili asılılıqları başa düşməsini gözləmək əvəzinə, ona yol göstərməlidir.
Çünki əksər istifadəçilər əsas versiyalar, add-on versiyaları, migrasiya məntiqi və uyğunluq qatları terminləri ilə düşünmür.
Onlar sadəcə məhsulun işləməsini istəyirlər.
Hosting mühitləri eyni deyil
Plagin yeniləmələrinin riskli ola bilməsinin başqa bir səbəbi WordPress hosting mühitidir.
İdarə olunan bir SaaS məhsulunda komanda adətən server mühitini idarə edir. Onlar PHP versiyasını, verilənlər bazası versiyasını, genişləndirmələri, fayl icazələrini, keş qatını, növbə sistemini və deploy prosesini bilir.
WordPress-də isə bu, tamamilə fərqlidir.
Eyni plagin yüzlərlə, hətta minlərlə fərqli mühitdə işləyə bilər.
- Bir sayt PHP 8.3 işlədə bilər. Başqası hələ də PHP 7.4 işlədir.
- Bir serverdə sərt fayl icazələri ola bilər. Başqası müəyyən sorğuları bloklaya bilər.
- Bir hosting provayderi admin AJAX cavablarını aqressiv şəkildə keşləyə bilər. Başqasının yaddaş limiti aşağı ola bilər.
- Bir saytda API sorğularını bloklayan təhlükəsizlik plagini işləyə bilər. Başqasında JavaScript yüklənmə davranışını dəyişən optimallaşdırma plagini ola bilər.
Bu o deməkdir ki, plagin yeniləməsi saytdan-sayta fərqli davrana bilər.
Developer yeniləməni bir neçə mühitdə test edə bilər və yenə də müəyyən bir hosting konfiqurasiyasını gözdən qaçıra bilər. Bu, testin laqeyd aparıldığı anlamına gəlmir. Bu o deməkdir ki, WordPress ekosistemi son dərəcə müxtəlifdir.
Plagin nə qədər qabaqcıldırsa, bu, bir o qədər əhəmiyyət kəsb edir.
Sadə bir məzmun plagini bir çox mühit fərqindən təsirlənməyə bilər. Amma rezervasiya plagini, ödəniş plagini, LMS plagini, üzvlük plagini və ya SaaS tipli plagin sistemin bir çox hissəsi ilə qarşılıqlı əlaqədə olur. O, planlaşdırılmış tapşırıqlardan, verilənlər bazası sorğularından, AJAX endpoint-lərindən, REST API-lərdən, sessiyalardan, e-poçtlardan, üçüncü tərəf inteqrasiyalarından və ön tərəf skriptlərindən istifadə edə bilər.
Bu sahələrin hər biri hosting fərqlərindən təsirlənə bilər.
Məhz buna görə ciddi WordPress məhsulları güclü xəta idarəçiliyinə, aydın loglara, geriyə uyğunluğa və müdafiəyönlü kodlaşdırmaya ehtiyac duyur. Amma bütün bunlara baxmayaraq, bəzi problemlər yalnız buraxılışdan sonra üzə çıxır, çünki real mühitlər istənilən test mühitinin tam simulyasiya edə biləcəyindən daha müxtəlifdir.
İstifadəçilər həmişə gözlədiyin kimi yeniləmir
Başqa bir gizli risk istifadəçilərin yeniləmə davranışıdır.
Məhsul komandaları adətən düzgün bir yeniləmə axını təsəvvür edir:
- İstifadəçi saytın ehtiyat nüsxəsini götürür.
- Əsas plagini yeniləyir.
- Bütün əlaqəli add-on-ları yeniləyir.
- Keşi təmizləyir.
- Rezervasiya formasını və ya əsas axını test edir.
- Admin panelini yoxlayır.
- Bir şey səhvdirsə, dəstəyə müraciət edir.
Amma real istifadəçilər çox vaxt fərqli davranır.
- Bəziləri mövcud plaginin üzərinə yeni bir ZIP fayl yükləyir.
- Bəziləri datanın qalıb-qalmayacağını bilmədən köhnə plagini silir.
- Bəziləri yalnız bir add-on-u yeniləyir.
- Bəziləri iş saatları ərzində canlı saytda yeniləyir.
- Bəziləri köhnə brauzer keşindən istifadə edir və yeni versiyanı sınıq sanır.
- Bəziləri ehtiyat nüsxənin yalnız bir hissəsini bərpa edir.
- Bəziləri staging əvəzinə birbaşa canlı saytda test edir.
- Bəziləri texniki göründüyü üçün bildirişləri nəzərə almır.
Yenə də, bu, istifadəçilərin pis olduğu üçün deyil. Bu, istifadəçilərin məşğul olduğu üçündür. Onlar developer kimi düşünmür. Onlar bir biznes idarə edir.
Məhsul komandası bu reallıq üçün dizayn etməlidir.
- Bir yeniləmə üsulu təhlükəlidirsə, məhsul bunu aydın bildirməlidir.
- Add-on-lar birlikdə yenilənməlidirsə, sistem bunu çatdırmalıdır.
- Migrasiya tələb olunursa, istifadəçi təxmin etməyə məcbur qalmamalıdır.
- Keş problemi tez-tez rast gəlinirsə, sənədlər və dəstək cavabı bunu aydın qeyd etməlidir.
- Staging sayt tövsiyə olunursa, məhsul səbəbini izah etməlidir.
Yaxşı bir məhsul yalnız mükəmməl ssenaridə işləmir. O, qüsurlu ssenarilərdə ziyanı azaldır.
Əsl çətinlik də elə budur.
Geriyə uyğunluq həmişə sadə deyil
Geriyə uyğunluq sadə səslənir: köhnə şeyləri sındırma.
Amma real məhsul inkişafında bu, çox mürəkkəbləşə bilər.
Bəzən köhnə struktur məhsulu məhdudlaşdırır. Bəzən bir funksiya illər əvvəl məntiqli olan, amma indiki ehtiyaclara artıq cavab verməyən bir şəkildə qurulub. Bəzən performans təkmilləşdirmələri datanın necə yükləndiyini dəyişməyi tələb edir. Bəzən təhlükəsizlik təkmilləşdirmələri təhlükəli davranışı silməyi tələb edir. Bəzən gələcək funksiyaları dəstəkləmək üçün yeni bir arxitektura lazımdır.
Bu nöqtədə komanda çətin bir qərar verməlidir.
Köhnə məntiqi əbədi saxla və məhsulu yavaşlat, ya da strukturu dəyiş və yeniləmə riskini idarə et.
Mükəmməl cavab yoxdur.
Həddən artıq çox köhnə kod saxlasan, məhsul ağırlaşır və saxlanması çətinləşir. Hər yeni funksiyanın qurulması yavaşlayır. Hər baq düzəlişi daha təhlükəli olur. Developerlər köhnə sahələrə toxunmaqdan qorxur. Məhsul həddən artıq tarixi yük daşımağa başlayır.
Amma həddən artıq çox şeyi çox tez dəyişsən, istifadəçilər yeniləmə problemləri ilə üzləşə bilər. Add-on-lar düzəlişlərə ehtiyac duya bilər. Sənədlər köhnələ bilər. Dəstək həcmi arta bilər. Bəzi istifadəçilər məhsulun qeyri-stabil olduğunu hiss edə bilər.
Məhz buna görə böyük yeniləmələr kiçik yeniləmələrdən fərqli idarə edilməlidir.
- Kiçik bir yamaq (patch) səssizcə göndərilə bilər.
- Böyük struktur dəyişikliyi hazırlıq tələb edir.
- İstifadəçilərə aydın məlumat lazımdır.
- Add-on-lara uyğunluq yoxlamaları lazımdır.
- Migrasiya məntiqinin test edilməsi lazımdır.
- Dəstək komandasına kontekst lazımdır.
- Geri qaytarma (rollback) variantları nəzərdən keçirilməlidir.
- Sənədlər yenilənməlidir.
Texniki dəyişiklik yeniləmənin yalnız bir hissəsidir. Yeniləmə ətrafındakı kommunikasiya da eyni dərəcədə vacibdir.
Dəstək komandası yeniləmə prosesinin bir hissəsidir
Çoxları yeniləmələrin yalnız developer məsuliyyəti olduğunu düşünür. Əslində dəstək yeniləmə prosesinin kritik bir hissəsidir.
Yeniləmə buraxılanda ilk siqnallar çox vaxt dəstəkdən gəlir.
- Dəstək hansı istifadəçilərin çaşqın olduğunu görür.
- Dəstək hansı mühitlərin uğursuz olduğunu görür.
- Dəstək hansı bildirişlərin aydın olmadığını görür.
- Dəstək istifadəçilərin hansı yeniləmə təlimatlarını nəzərə almadığını görür.
- Dəstək eyni problemin fərqli saytlarda təkrarlanıb-təkrarlanmadığını görür.
Bu geribildirim son dərəcə dəyərlidir.
Yaxşı bir dəstək komandası yalnız ticketlərə cavab vermir. O, məhsul komandasına yeniləmənin real dünyada necə davrandığını anlamağa kömək edir.
Məsələn, çoxlu istifadəçi yeniləmə zamanı eyni səhvi edirsə, bəlkə sənədlər kifayət qədər aydın deyil. Çoxlu istifadəçi versiya uyğunsuzluğuna görə uğursuz olursa, bəlkə məhsul daha güclü bir xəbərdarlıq göstərməlidir. Çoxlu istifadəçi eyni fatal xətanı bildirirsə, bəlkə bir migrasiya halı gözdən qaçırılıb. İstifadəçilər yeniləmədən sonra bir funksiyanı davamlı olaraq səhv başa düşürsə, bəlkə interfeysin daha yaxşı ifadəyə ehtiyacı var.
Dəstəyə yalnız buraxılışdan sonra şikayətləri idarə edən ayrı bir şöbə kimi yanaşılmamalıdır. O, məhsul dövrəsinin bir hissəsi olmalıdır.
Developerlər, QA, dəstək və məhsul adamları məlumatı tez paylaşanda yeniləmələr daha təhlükəsiz olur.
Çünki bəzən problem yalnız “bir baq var” deyil. Bəzən problem “istifadəçilər nəyin dəyişdiyini başa düşmür”dür. Bəzən “məhsul təhlükəli bir yeniləmə yoluna icazə verdi”dir. Bəzən “biz funksiyanı test etdik, amma istifadəçilərin əslində istifadə etdiyi kimi yox”dur.
Bu fərq əhəmiyyətlidir.
Daha təhlükəsiz yeniləmə mədəniyyəti
Bəs plagin yeniləmələri necə idarə edilməlidir?
Cavab “heç vaxt yeniləmə” deyil. Bu, səhv olardı. Yeniləmələr lazımdır. Onlar baq düzəlişləri, təhlükəsizlik təkmilləşdirmələri, yeni WordPress versiyaları ilə uyğunluq, performans təkmilləşdirmələri və yeni funksiyalar gətirir.
Cavab daha təhlükəsiz bir yeniləmə mədəniyyəti qurmaqdır.
Məhsul komandaları üçün bu o deməkdir ki, yalnız təmiz quraşdırmaları yox, yüksəltmə yollarını da test etmək lazımdır. Köhnə data haqqında düşünmək lazımdır. Add-on uyğunluğunu yoxlamaq lazımdır. Migrasiya məntiqini diqqətlə yazmaq lazımdır. Bildirişləri və logları yaxşılaşdırmaq lazımdır. Buraxılışdan əvvəl dəstəyi hazırlamaq lazımdır. Lazımsız sındırıcı dəyişikliklərdən qaçmaq lazımdır. Böyük yeniləmələri aydın çatdırmaq lazımdır.
İstifadəçilər üçün bu o deməkdir ki, yeniləmələrin vacib olduğunu, amma məsuliyyətlə edilməli olduğunu başa düşmək lazımdır. Biznes üçün kritik bir sayt ehtiyat nüsxələrə malik olmalıdır. Böyük yeniləmələr mümkün olduqda staging-də test edilməlidir. Əsas plaginlər və add-on-lar uyğun saxlanmalıdır. Yeniləmələrdən sonra keş təmizlənməlidir. Və bir şey səhv gedərsə, dəstək yalnız “işləmir” əvəzinə faydalı detallar almalıdır.
Hər iki tərəfin məsuliyyəti var.
Məhsul komandası yeniləmələri mümkün qədər təhlükəsiz və aydın etməlidir. İstifadəçi canlı bir biznes saytına test mühiti kimi yanaşmaqdan çəkinməlidir.
Hər iki tərəf bunu başa düşəndə yeniləmələr daha az stresli olur.
Yeniləmə bir etibar anıdır
Plagin yeniləməsi yalnız texniki bir buraxılış deyil. O, həm də bir etibar anıdır.
- İstifadəçi öz saytını məhsul komandasına etibar edir.
- Məhsul komandası qurduğu yeniləmə prosesinə etibar edir.
- Dəstək komandası aldığı məlumata etibar edir.
- Biznes dəyişiklikdən sonra sistemin işləməyə davam edəcəyinə etibar edir.
Məhz buna görə məhsul istifadəçinin biznesi üçün vacib olanda kiçik bir yeniləmə belə böyük hiss oluna bilər.
Rezervasiya forması işləməyi dayandırarsa, problem yalnız texniki deyil. Bu, itirilmiş görüşlər demək ola bilər. Ödəniş məntiqi sınarsa, bu, itirilmiş gəlir demək ola bilər. Bildirişlər uğursuz olarsa, müştərilər vacib məlumatı qaçıra bilər. Təqvim sinxronizasiyası gözlənilmədən dəyişərsə, işçi cədvəlləri qarışa bilər.
Developer üçün bu, bir baq ola bilər. İstifadəçi üçün isə bir biznes problemi ola bilər.
Məhz buna görə plagin yeniləmələrinə hörmətlə yanaşmaq lazımdır.
Qorxu ilə yox. Hörmətlə.
Çünki yetkin proqram təminatı heç vaxt dəyişməyən proqram təminatı deyil. Yetkin proqram təminatı diqqətlə dəyişən proqram təminatıdır.
Yekun fikirlər
Real istifadəçilər və real WordPress məhsulları ilə işlədikdən sonra mən artıq yeniləmələrə sadə versiya dəyişiklikləri kimi baxmıram.
Versiya nömrəsi yalnız görünən hissədir.
Onun arxasında köhnə data, istifadəçi davranışı, add-on uyğunluğu, hosting fərqləri, biznes iş axınları, dəstək hazırlığı, sənədlər, test və etibar var.
Bu o demək deyil ki, yeniləmələrdən qaçmaq lazımdır. Tam əksinə. Yenilənməyən bir məhsul nəticədə köhnələcək, təhlükəsizlikdən düşəcək və istifadəsi çətinləşəcək.
Amma yeniləməyə heç vaxt “sadəcə yeni faylları yüklə” kimi yanaşılmamalıdır.
Sadə plaginlər üçün bəlkə bu, kifayətdir. Real bizneslərin işlətdiyi real məhsullar üçün isə yox.
Plagin yeniləməsi eyni anda bir məhsul qərarı, bir texniki əməliyyat və bir müştəri təcrübəsidir.
Və plagin istifadəçinin biznesi üçün nə qədər vacibdirsə, o yeniləmə bir o qədər diqqətlə idarə edilməlidir.