În orice dezvoltare de software este înțelept să-ți propui o abordare în 3 etape:
- Dezvoltare;
- Testare;
- Producție.
În diagrama următoare se pot vedea modalitățile în care o aplicație QVW parcurge mai multe etape și care este rolul fiecărei etape în parte.
Diagrama QlikView™ în 3 Etape (Dezvoltare-Testare Producție)
În timp ce Producția este clar ar trebui să o avem (altfel, am greșit subiectul, corect? 
), pentru primele două etape trebuiesc parcurse o serie de aspecte:
1. Pentru etapa de Dezvoltare este suficient să ai un (sau mai multe, dacă dispui de mai mulți dezvoltatori) fișier QVLC (= Clientul Local = fostul Dezvoltator) ca să-ți asiguri perspectiva licențierii.
Le oferă dezvoltatorilor tot ceea ce le trebuie pentru a dezvolta noi aplicații QlikView™. Poate fi chiar o licență împrumutată de la un Named CAL sau un QvS (în caz că aveți asta), dar cel mai sigur mod este de a avea un QVLC dedicat în orice situație. Putem avea aici în vedere și un alt scenariu unde dezvoltarea este și ea un serviciu externalizat.
Pentru etapa de dezvoltare este recomandat să avem și un mecanism (fie automat, dacă nu măcar manual) care ne permite să facem capturi de ecran pe parcursul mai multor etape ale dezvoltării. Cu alte cuvinte, o modalitate prin care să păstrăm copii ale versiunilor mai vechi.
O opțiune care este mereu disponibilă este desigur abordarea ”Salvează ca”. Dar QlikView™ oferă și alte opțiuni mai înțelepte, precum: opțiunea QlikView™ Local Client trebuie să păstreze versiunile anterioare ale fișierelor QVW (uită-te la Menu – Settings-User Prefferences – Save – Use Backup), sau opțiunea de a exporta toate metadatele dintr-un fișier QVW către un set de fișiere XML.
O modalitate de a face asta este manual prin intermediul Menu – File – Export.
Dar cea mai bună opțiune aici este să avem un submeniu numit ”.-PRJ” în același fișier cu aplicația.
În același subfișier, toate fișierele XML cu metadatele fișierului QVW (script, variabile, definiții în interfață, acțiuni, macrouri, etc.) vor fi salvate automat. Aceasta este cea mai recenta versiune disponibilă și aduce valoare adaugată, special într=un mediu multi-developer, prin integrarea cu CVS-urile, SV-urile si cu orice altă soluție de versioning.
Aceasta pemite nu numai compararea versiunilor, ci si facilități de tipul check-in / check-out (evitând situația în care doi dezvoltatori lucrează în aceeași zonă și riscul inerent al generării de versiuni conflictuale).
2. Pentru stadiul de Testare, trebuie acoperite cel putin 3 perspective:
- testarea dezvoltărilor locale noi (aplicații întregi QVW noi sau părți noi ale celor deja existente) înainte de lansarea lor în Producție (utilizarea în viața reală). Inclusiv extinderea testărilor pentru cascadările corecte ale proceselor de data staging pentru incremental loads;
- testarea noilor versiuni și îmbunătățiri ale platformei QlikView™ lansate (de mai multe ori pe parcursul unui an) de către Qlik™Tech, înainte de migrarea platformei noastre de Producție la cea mai nouă versiune/îmbunătățire;
- testarea capabilităților de performanță ale platformei noastre și în special ale noilor noastre rapoarte.
Pentru prima perspectivă a stadiului de testare, cea mai potrivită practică pe care am întâlnit-o a fost să adaugăm un fișier separat în cadrul serverului de producție, unde sunt găzduite fișierele ”under testing”. (Uneori, ca variație a acestei abordări, are sens chiar adăugarea unei serii de tag-uri speciale în titlurile obiectelor care sunt ”under testing” din fișierele existente).
Pentru a doua perspectivă, a avea un mediu de teste pentru a verifica dacă toate aplicațiile QVW sunt compatibile cu noua versiune a platformei este o abordare înțeleaptă, preventivă.
Mai mult decât atât, printr-o migrare inițială într-un mediu de Testare, putem fi siguri atât că procestul de migrare este bine documentat și că funcționează cum ne așteptăm în mediul nostru special.
Nu trebuie uitat faptul că migrarea mediului de Producție este, de regula constrânsă să fie făcută seara târziu sau în orele sfârșitului de săptămână! (nu e prea amuzat să tot repeți treaba asta). De ce nu ar trebui să facem migrarea mediului de testare oricând în timpul zilei de lucru, și doar să schimbăm mediul de producție în noul mediu de Testare migrat, în același timp păstrându-ne opțiunea de a reveni la cel vechi, în cazul în care se înregistrează vreun eșec major al migrației?
Este mai ușor și mai sigur în același timp! Si apoi, numai să-i atribuim rolul noului mediu de Testare, celui vechi de Producție.
Apropo, acesta poate fi considerat totodată și o modalitate destul de interesantă de oferire a unei opțiuni reale de back-up pentru întregul mediu de Producție (este adevărat, pot apărea anumite limitări).
Pentru a treia perspectivă, din nefericire majoritatea dezvoltărilor curente pe care le stim sunt doar reactive (Lucru care are puțin sens, bazat pe performanța înaltă pe care QlikView™ o conferă de regulă).
Totuși, o modalitate mai bună de a face testările de performanță într-un ”sandbox” separat și de a împinge limitele performaței în așa fel încât să putem prezice în avans când ne vom confrunta cu probleme de perfomanță și vom avea nevoie să upgradăm hardware-ul (sau un fine-tunning al aplicațiilor) pentru a sprijini un număr mai mare de utilizatori sau un nivel crescut de complexitate în setul nostru de aplicații.
***
Presupunând că motivele menționate mai sus sunt suficiente pentru a lua în calcul abordarea în 3 stadii, constrângerile bugetare sunt încă, mai ales în zilele noastre, o problemă majoră. Nu este ușor pentru niciun fel de organizație să dublezi bugetul pentru licențe doar pentru a oferi aceste posibilități.
Dar chiar și cu aceste constrângeri, sunt vești bune: modelul de licențiere al QlikView™ oferă o licență specială de testare numită QlikView™ Test Server, care costa aproximativ jumătate din prețul Serverului QlikView™ (QvS) echivalent și oferă același număr de licențe CAL ca și Serverul QlikView™ asociat (fără tariful suplimentar pentru CAL-uri!).
Pentru QvS Enterprise Edition acest lucru este valabil deja de ceva vreme, dar mai există și unul nou nouț, numit QvT SBE (Small Business Edition), disponibil din această vară, la un preț de plecare destul de rezonabil!
***
Abordarea procedurală
Recent, vorbind despre acest subiect cu o parte din clienții noștri, am realizat că este necesar să existe o abordare procedurală clară a Testării, a definirii listelor de verificare a testării și a rezultatelor așteptate pentru diferitele scenarii.
Pentru aceasta, este util să mai avem un spațiu în care să colectăm erorile întâlnite anterior și posibilele variante prin care acestea pot fi prevenite și testate pe parcursul următorului stadiu de testare al unui nou deployment.
Mai multe într-o postare viitoare…