Mida teha, kui eelmine arendaja on kadunud — Drupal projekti ülevõtmine
🎧 Kuula kõiki artikleid järjest
Eelmise arendaja lahkumine ei pea tähendama kriisi, kuid enne muudatuste tegemist tuleb aru saada, milline on projekti tegelik seis.
Kui probleem ei ole kood, vaid teadmus
Paljud organisatsioonid avastavad alles arendaja lahkumisel, kui palju teadmisi oli ühe inimese peas.
Dokumentatsiooni võib olla vähe või üldse mitte. Mõnikord pole selge:
- kus asub Git hoidla;
- kelle käes on domeen;
- kuidas tehakse varukoopiaid;
- millised integratsioonid töötavad taustal;
- millised probleemid on juba teada.
Sellisel hetkel ei ole peamine küsimus „kas veeb töötab“, vaid „kas me saame seda turvaliselt hallata“.
Esimene eesmärk: kontroll olukorra üle
Enne suuremaid muudatusi tasub kaardistada kogu tehniline keskkond.
Kontrolli vähemalt järgmisi asju:
- Drupal administraatori ligipääs;
- serveri või hostingu ligipääs;
- domeeni haldus;
- Git hoidla;
- Composer failid;
- andmebaasi ligipääs;
- välised teenused (Google Analytics, reCAPTCHA, makselahendused, CRM-id).
Kui mõni neist puudub, tuleks see lahendada enne järgmiste sammude tegemist.
Tee kohe varukoopia
Enne uuendusi või parandusi tuleb olemasolev seis fikseerida.
Varunda:
- andmebaas;
- üleslaetud failid;
- konfiguratsioon;
- koodibaas.
Eesmärk ei ole ainult katastroofitaaste. Varukoopia võimaldab vajadusel tagasi pöörduda olukorda, mis eksisteeris enne ülevõtmist.
Kaardista tehniline seis
Järgmine samm on mõista, mida süsteem tegelikult sisaldab.
Tüüpilised küsimused:
- Milline Drupal versioon on kasutusel?
- Kas versioon on veel toetatud?
- Milliseid mooduleid kasutatakse?
- Kas projekt kasutab Composerit?
- Kas on kohandatud mooduleid?
- Kas eksisteerivad automaattestid?
- Kas on testkeskkond?
Sageli ilmnevad juba selles etapis peamised riskid.
Kohandatud kood on suurim teadmusrisk
Drupal core ja tuntud moodulid on dokumenteeritud.
Kõige suurem teadmusrisk peitub tavaliselt kohandatud koodis.
Eriti tähelepanelikult tasub vaadata:
modules/custom- kohandatud teemasid
- integratsioonimooduleid
- cron-töid
- migratsiooniskripte
Need on kohad, kus äriloogika ja süsteemi eripärad tavaliselt asuvad.
Ära alusta ümberkirjutamisest
Levinud viga on otsustada kohe, et kogu kood tuleb ümber teha.
Enamasti ei ole see vajalik.
Mõistlik järjekord on:
- Stabiliseeri süsteem.
- Taasta kontroll ligipääsude üle.
- Kaardista riskid.
- Tee vajalikud turvauuendused.
- Planeeri suuremad muudatused.
Alles pärast auditi tegemist on võimalik hinnata, kui palju olemasolevast lahendusest on mõistlik säilitada.
Tehniline audit vähendab ebakindlust
Kui projekti seis ei ole teada, tasub alustada auditist.
Auditi käigus hinnatakse näiteks:
- Drupal core'i seisundit;
- moodulite uuendatavust;
- kohandatud koodi kvaliteeti;
- turvariske;
- jõudlust;
- hooldatavust;
- ligipääsetavust;
- integratsioonide sõltuvusi.
Tulemuseks on realistlik pilt sellest, kui suur töö tegelikult ees ootab.
Kokkuvõte
Drupal projekti ülevõtmine ei ole ainult koodi kopeerimine ühelt partnerilt teisele.
Sageli tuleb taastada ülevaade süsteemist, mille teadmised olid koondunud ühe inimese või ettevõtte kätte.
Mida kiiremini saad kontrolli ligipääsude, varukoopiate, koodi ja dokumentatsiooni üle, seda väiksem on risk, et järgmine probleem tekib hetkel, kui veebis on vaja teha oluline muudatus.
Vajad Drupal abi?
Kui artikkel puudutab sinu olukorda, ei pea kõike lõpuni lugema. Sinuga suhtleb päris inimene ja aitab järgmise sammuni jõuda.