Vai no CMS varēs aiziet: kā pirms izstrādes pārbaudīt datu eksportu un pārnesamību

CMS datu pārnesamību vislabāk pārbaudīt ar izmēģinājuma eksportu un tā izmantošanu ārpus piegādātāja darba vides. Eksportā jābūt saprotamam saturam, attiecībām starp ierakstiem, vajadzīgajiem failiem un metadatiem. Atsevišķi jānoskaidro, kas netiek pārnests un kāds darbs būs vajadzīgs, lai datus izmantotu citā sistēmā.

Uzņēmuma īpašniekam jautājums par aiziešanu nav obligāti neuzticības izpausme. Mainās komanda, sistēmas un biznesa vajadzības. Pirms individuālas CMS pasūtīšanas ir lietderīgi zināt, vai nākamais uzturētājs spēs turpināt darbu ar saņemtajiem materiāliem. Solījums “dati pieder jums” pats par sevi nepasaka, kā tos iegūt un atjaunot.

Tehniska pārnesamība un līgumā noteiktas tiesības ir saistīti, bet atšķirīgi jautājumi. Šis raksts palīdz formulēt tehnisku pārbaudi. Tas neaizstāj līguma vai licenču juridisku izvērtēšanu un nesola migrāciju bez izmaksām.

Vispirms definējiet, ko uzņēmums vēlas aiznest līdzi

Satura eksports, sistēmas rezerves kopija un pilna lietotnes nodošana nav viens rezultāts. Satura eksports var būt piemērots migrācijai uz citu platformu. Rezerves kopija var būt paredzēta tās pašas sistēmas atjaunošanai. Lietotnes pārņemšanai papildus var būt vajadzīgs kods, konfigurācija, izpildes vide un dokumentēta izvietošana.

Pirms prasīt “pilnu eksportu”, uzrakstiet paredzēto lietojumu. Vai gribat atjaunot esošo CMS citā serverī? Vai pārcelt saturu uz citu produktu? Vai nomainīt uzturētāju, saglabājot sistēmu? Katram scenārijam ir atšķirīgas prasības, un viens arhīvs ne vienmēr nodrošina visus.

Publiskā WordPress dokumentācija, piemēram, apraksta WXR XML eksportu ar noteiktiem satura veidiem un importu citā WordPress vietnē. WordPress eksporta tvērums. Tas palīdz uzdot pareizo jautājumu arī individuālai CMS: ko konkrētais rīks ietver, nevis tikai kā sauc tā pogu?

Pārnesamības prasībā norādiet arī izņēmumus. Ja pilna vēsture vai kāds ārējas sistēmas datu bloks netiks iekļauts, tas jāzina iepriekš. Atklāts ierobežojums ir pārvaldāms. Nepateikts ierobežojums parasti parādās brīdī, kad vecā vide jau jāslēdz.

Saturs bez relācijām var zaudēt nozīmi

Produkta nosaukums un apraksts vēl neatjauno katalogu. Vajadzīgas tā kategorijas, varianti, piesaistītie faili un valodu saites. Ja eksports saglabā tikai cilvēkam redzamas vērtības, var pazust stabilā identitāte, pēc kuras šīs daļas jāsavieno.

Pārbaudiet, vai ierakstiem ir identificētāji un vai atsauces uz tiem var atrisināt. Vienādi nosaukumi nav droša saistīšanas atslēga. Eksporta dokumentācijā jābūt saprotamai shēmai: kurš lauks uz ko norāda, kā attēlota tukša vērtība un kā interpretēt sarakstus vai atkārtotus blokus.

Atsevišķi aplūkojiet vēsturi un statusus. Ja vajadzīgs zināt, kas bija publicēts agrāk, ar pašreizējo tekstu nepietiek. Ja migrācijā vajadzīga tikai aktuālā versija, to var apzināti ierobežot. Svarīgi vienoties, vai eksportā ietilpst melnraksti, arhivētais saturs, publicēšanas datumi un apstiprinājumu vēsture, ja uzņēmums uz to paļaujas.

Strapi dokumentācija rāda citu eksporta piemēru: definētu arhīvu ar saturu, relācijām, failiem, shēmām un konfigurāciju, vienlaikus norādot atsevišķus neiekļautus elementus, piemēram, administratorus un API tokenus. Strapi eksporta apraksts. Tas nav formāts, kuru cita CMS automātiski sapratīs, bet ilustrē vajadzību aprakstīt gan saturu, gan izņēmumus.

Faila URL vēl nav pats fails

Eksportētā tabulā var būt saites uz attēliem vecā piegādātāja glabātuvē. Kamēr tā darbojas, pārbaudes vietne izskatās pilnīga. Pēc piekļuves slēgšanas attēli pazūd. Tāpēc pārnesamības testā jānoskaidro, vai saņemti paši nepieciešamie faili un vai jaunā vide spēj tos izmantot neatkarīgi.

Līdzās priekšskatījumiem pārbaudiet failu oriģinālus. Var būt vajadzīgi PDF, lejupielādējami tehniskie dokumenti, attēlu paraksti un alternatīvais teksts. Pie katra materiāla saglabājiet identitāti un saikni ar attiecīgo ierakstu. Daudzi vienādi failu nosaukumi nedrīkst pārrakstīt cits citu.

Contentful eksporta rīka dokumentācijā failu lejupielādei ir atsevišķa izvēle downloadAssets. Contentful eksporta iestatījumi. Šis konkrētais piemērs parāda, kāpēc jāfiksē izmantotie iestatījumi. Ar rīka nosaukumu vien nevar pierādīt, ka eksportā ir visi nepieciešamie materiāli.

Prasiet arī failu sarakstu un integritātes pārbaudes iespēju. Saņemot arhīvu, var salīdzināt skaitu un kontrolsummas, bet ar to vēl nepietiek satura pilnīgumam. Nepieciešams pārbaudīt, vai pareizais fails piesaistīts pareizajam produktam un atverams lietojamā formātā.

Ko saglabāt par URL un daudzvalodu saturu

Migrācijā noder pašreizējās adreses, valodu saites un metadati. Ja jaunajā sistēmā adrese mainīsies, vajadzēs plānu vecās un jaunās adreses sasaistīšanai. Šeit mērķis nav iepriekš noteikt visus SEO pāradresēšanas lēmumus, bet saglabāt informāciju, bez kuras tos vēlāk nevar droši pieņemt.

Pārbaudiet vienu daudzvalodu ierakstu ar nevienādi aizpildītiem laukiem. Eksportam jāparāda, kur ir īsts tulkojums, kur trūkst satura un kur sistēma izmanto aizvietoto vērtību. Citādi jaunā vide var nejauši publicēt avota tekstu kā gatavu tulkojumu.

Datumu un statusu nozīmei arī jābūt dokumentētai. Tehnisks atjaunošanas datums var atšķirties no publikācijas datuma. Pārnesot abus vienā laukā, iespējams izveidot nepareizu vēsturi. Izmēģinājuma ieraksti palīdz šīs neskaidrības atrast pirms pilnas migrācijas.

Licences un ārējās atkarības jāuzskaita atsevišķi

Saņemts kods nenozīmē, ka automātiski var pārnest katru maksas komponenti, attēlu vai ārējo pakalpojumu. Uzskaitiet izmantotās licences un noskaidrojiet, uz kura konta tās ir. Konkrētās nodošanas un turpmākās lietošanas tiesības jāpārbauda attiecīgajos nosacījumos un līgumā.

Ārējā atkarība var būt meklētājs, maksājumu pakalpojums, e-pasta piegāde vai attēlu glabātuve. Ja tās iestatījumi eksistē tikai piegādātāja kontā, eksportētais saturs neatjaunos darbību. Nosakiet, kuras atkarības var pārkonfigurēt uzņēmuma kontā un kurām vajadzīgs aizvietojums.

Noslēpumus nevajag ielikt parastā satura arhīvā. API atslēgu un paroļu nodošanai vai nomaiņai paredziet atsevišķu drošu procesu. Testa vidē izmantojiet atbilstošas ierobežotas piekļuves, nevis automātiski pieslēdziet produkcijas integrācijas. Pārnesamības pārbaude nedrīkst nejauši nosūtīt klientiem ziņas vai radīt reālus pasūtījumus.

Arī izpildes vides zināšanas ir atkarība. Ja sistēmu spēj iedarbināt tikai viens izstrādātājs ar savā datorā glabātiem iestatījumiem, pārņemšana vēl nav pierādīta. Vajadzīga saprotama instrukcija un nosacījumu saraksts, kuru var izpildīt cita kompetenta komanda.

Izmēģinājuma eksports pirms līguma noslēgšanas

Pirms pasūtījuma izvēlieties nelielu, bet daudzveidīgu demonstrācijas datu kopu. Tajā var būt parasts ieraksts, daudzvalodu saturs, saistīti ieraksti, fails un melnraksts. Piemēriem jāaptver sarežģītās attiecības, nevis tikai glīts vienas lapas apraksts.

Lūdziet izstrādātājam parādīt eksporta izveidi un skaidrojumu. Tad izmēģiniet atjaunošanu atsevišķā vidē ar dokumentāciju, kuru saņemtu nākamais uzturētājs. Ja projekts vēl nav izstrādāts, šādu demonstrāciju var veikt prototipā un līgumā paredzēt atkārtotu pārbaudi ar projekta datiem.

Tabula ir piedāvāts pieņemšanas tests, ne apgalvojums par kāda produkta pilnīgumu. Katrā projektā jānorāda, kuri punkti ir obligāti un kuri apzināti nav iekļauti. Svarīga ir atkārtojamība: citam speciālistam jāspēj saprast, ko pārbaude pierādīja.

Jautājumi, kurus uzdot izstrādātājam

Prasiet parādīt eksporta formātu un shēmas dokumentāciju. Noskaidrojiet, kas drīkst to izveidot, vai vajadzīga piegādātāja līdzdalība un kā iegūt datus, ja regulārā sadarbība beidzas. Ja eksports ir atsevišķs pakalpojums, tā tvērums un aprēķina kārtība jāzina laikus.

Pajautājiet, kā tiek pārbaudīta pilnība. Vai ir objektu un failu saraksts? Kā rīks uzrāda neizdevušos lejupielādi? Vai daļējs eksports var izskatīties sekmīgs? Darba beigās uzņēmumam vajadzīgs saprotams rezultāts ar izņēmumiem, ne tikai procesa beigšanās paziņojums.

Atsevišķi jautājiet par pārņemšanas instrukciju un ārējām atkarībām. Kur atrodas konfigurācija, kas eksportā nav? Kuras piekļuves uzņēmums pārvalda pats? Kuras darbības jaunajā vidē nedrīkst ieslēgt pirms pārbaudes? Šīs atbildes palīdz novērtēt faktisko uzturēšanas neatkarību.

Noslēgumā lūdziet nošķirt tehnisko iespēju no darba apjoma. Datus var būt iespējams iegūt, bet jaunajā CMS vajadzēs pārveidot lauku struktūru, attēlu saites vai satura blokus. Tas nav automātiski slikts risinājums. Svarīgi, lai šī nākotnes darba daba būtu saprotama un netiktu paslēpta aiz vārda “eksports”.

Kas vēlāk rada migrācijas darbu

Izmaksas ietekmē satura struktūras atšķirības, datu kvalitāte, failu apjoms un integrācijas. Sarežģīti, tikai vienā sistēmā saprotami satura bloki var prasīt pārveidošanu. Nepilnīgi metadati vai salauztas relācijas savukārt prasa izmeklēšanu, nevis vienkāršu kopēšanu.

Jāparedz arī izmaiņas starp izmēģinājuma eksportu un faktisko pāreju. Ja vecajā sistēmā turpinās darbs, jāvienojas par noslēguma datu kopu un pārbaudi. Atsevišķi jāizvērtē kļūmes gadījums: kurā brīdī drīkst atsākt darbu vecajā vidē un kā nepieļaut atšķirīgu datu attīstību abās vietās.

Pārnesamības tests nevar iepriekš izslēgt visus šos darbus. Tas var atklāt galvenos ierobežojumus un dot pamatu skaidrākam pasūtījumam. Izvērtējiet to kopā ar ikdienas lietojamību un uzturēšanu, nevis kā vienīgo CMS izvēles kritēriju.

Vai JSON vai CSV nozīmē, ka dati ir pārnesami?

Tie ir nolasāmi formāti, bet formāta nosaukums nepasaka, vai saglabāta nozīme, attiecības un faili. Pārbaudiet dokumentāciju un praktisku importu paredzētajam lietojumam. Bez tā fails var būt tikai daļēja datu kopija.

Vai atvērtā pirmkoda CMS novērš atkarību no piegādātāja?

Tā var dot noteiktas tehniskas iespējas, taču individuāli paplašinājumi, licences, konti un dokumentācijas trūkums joprojām var sarežģīt pārņemšanu. Jāvērtē konkrētais projekts un faktiskais nodošanas tests.

Pārnesamību ierakstiet prasībās, kamēr vēl var izvēlēties

Pirms izstrādes pasūtījuma definējiet paredzēto aiziešanas scenāriju, obligāto eksporta saturu un atjaunošanas pārbaudi. Saglabājiet pieņemšanas rezultātu un zināmos izņēmumus. Tādējādi vēlāk būs pamats konkrētai sarunai par pārņemšanu, nevis strīdam par atšķirīgu vārda “pilns” izpratni.

Ja vajadzīgs individuālas CMS prasību izvērtējums, iekļaujiet tajā datu eksportu un turpmākās uzturēšanas iespējas. Projekta budžeta sastāvdaļas skaidro individuālas CMS izmaksas, bet plašāku nodošanas pārbaudi — mājaslapas pieņemšanas testēšana.