Când o firmă alege o platformă pentru site-ul ei, discuția se învârte de obicei în jurul funcțiilor, al designului și al prețului. Toate contează. Dar decizia care modelează în tăcere costurile următorilor cinci ani e alta: cum se raportează platforma la timp. Orice software se schimbă, iar întrebarea e dacă schimbările sosesc după un program pe care îl poți planifica sau ca surprize pe care trebuie să le absorbi. Răspunsul Drupal la această întrebare e unul dintre cele mai puternice motive pentru care construim pe el, și e rar discutat în afara cercurilor de dezvoltatori. Articolul de față e o încercare de a-l discuta în termeni de business.
Calendarul, într-un singur paragraf
Drupal își publică programul de lansări cu ani înainte. O nouă versiune majoră apare cam o dată la doi ani, în decembrie. Între versiunile majore, o versiune minoră apare de două ori pe an, în iunie și în decembrie, adăugând funcții și păstrând compatibilitatea. Fiecare versiune minoră e susținută aproximativ un an: șase luni de corecturi de erori, apoi șase luni de corecturi de securitate. Lansările de securitate pentru core și pentru modulele acoperite pleacă într-o zi fixă a săptămânii, cu anunț prealabil pentru orice e serios. Iar fiecare versiune majoră e susținută până la scurt timp după ce apare următoarea, așa că există mereu o versiune susținută pe care să fii și mereu o dată cunoscută până la care să te muți.
Acel paragraf e întregul sistem. Tot ce urmează e despre ce îți cumpără el.
Actualizările devin linii de buget, nu proiecte
Pentru că datele sunt cunoscute, munca poate fi programată. O actualizare minoră în iunie și una în decembrie. O actualizare majoră la doi ani, planificată într-o lună liniștită. Actualizări de securitate săptămânale care durează minute. Pe un site întreținut, acestea sunt intrări de rutină într-un calendar de mentenanță, cu efort predictibil lângă fiecare, și pot fi bugetate așa cum bugetezi orice serviciu recurent.
Compară asta cu alternativa, în care schimbarea sosește când decide un furnizor, în ce mărime se întâmplă, iar fiecare actualizare poartă o mică șansă de a fi cea care schimbă totul. Poți planifica și în jurul acelui model, dar costă atenție, iar atenția e scumpă. Un calendar publicat îți dă atenția aceea înapoi.
Versiunile majore sunt continuări
Cuvântul „major” sună alarmant, și a fost o vreme când merita să sune așa. De la Drupal 8 încolo, însă, fiecare lansare majoră e construită din ultima versiune minoră a celei anterioare, cu codul depreciat eliminat. Conținutul, configurația, utilizatorii și fișierele trec mai departe. Codul personalizat care urmează API-urile curente continuă să funcționeze. Instrumente automate identifică și rescriu cea mai mare parte din ce nu funcționează. Plecarea de pe Drupal 7 a fost ultima reconstrucție; tot ce a urmat a fost un pas.
Efectul practic e că un site Drupal construit bine astăzi are un drum clar prin Drupal 11, Drupal 12 și mai departe, fără nicio reconstrucție la orizont. Investiția în modelarea conținutului, în integrări și în design se acumulează în loc să se reseteze.
Securitate după program
Echipa de securitate Drupal e una dintre cele mai mari și mai longevive din open source. Coordonează remedieri pentru core și pentru fiecare modul contribuit care optează pentru acoperire, le publică într-o fereastră săptămânală fixă și anunță în avans lansările extrem de critice, ca echipele să fie pregătite. O asemenea lansare, în mai anul acesta, a fost anunțată cu zile înainte și a apărut într-o fereastră declarată, iar site-urile care urmează rutina au fost actualizate în aceeași seară.
Pentru o firmă, asta înseamnă două lucruri. Întâi, că vulnerabilitățile sunt tratate de un proces, nu de noroc. Apoi, că procesul e vizibil: fiecare aviz e public, datat și evaluat, astfel că oricine poate verifica dacă un site e la zi. Verificabilitatea e un avantaj discret care se plătește în ziua în care întreabă echipa de achiziții a unui client.
Ferestre lungi de suport
Drupal 10 a apărut în decembrie 2022 și e susținut până pe 9 decembrie 2026. Drupal 11 a apărut în 2024 și va fi susținut până la scurt timp după sosirea Drupal 13, în jur de 2028. Ferestrele de patru ani sunt destul de lungi ca o firmă să-și aleagă singură momentul mutării, în loc să fie împinsă. Înseamnă și că un site lansat în orice moment din viața unei versiuni are ani de drum liber înainte de următoarea decizie majoră.
Predictibilitatea scade costul tuturor celorlalte
Asta e partea ușor de ratat. O platformă predictibilă schimbă felul în care construiești pe ea. Integrările pot fi proiectate pe termen lung, pentru că terenul nu se va mișca sub ele. O bibliotecă de componente poate fi rafinată ani de zile, pentru că va rămâne relevantă. Modelele de conținut pot fi lăsate să supraviețuiască designului care le-a afișat prima dată. Site-urile care costă mai puțin de modificat sunt de obicei site-uri ai căror proprietari au putut investi în structură, iar structura merită investiția doar când platforma va fi tot acolo ca s-o răsplătească.
Modelul nostru de livrare e construit în jurul acestui calendar. Planurile de mentenanță sunt stabilite în raport cu el. Munca de actualizare e programată în el. Sezoanele de vârf sunt protejate de el. Predictibilitatea platformei devine a noastră, apoi a ta.
Ce înseamnă asta pentru o decizie pe care poate o iei acum
Dacă alegi o platformă, pune fiecărui candidat trei întrebări: când apare următoarea versiune majoră, cât timp e susținută cea curentă și unde e scris asta. Răspunsurile Drupal sunt publice și s-au ținut de un deceniu. Dacă rulezi deja Drupal, calendarul e un instrument: caută datele, pune-le în planificare și lasă actualizările să devină evenimentele plictisitoare și bugetate care ar trebui să fie. Iar dacă vrei ajutor ca să transformi calendarul într-un plan pentru site-ul tău, o facem cu plăcere.