💻IKT – Azpiegitura eta laguntza teknikoa

1. Aurreikusitako entregagaien berrikuspena

Talde bideratzaileak gogorarazi zuen proiektuak Gutxieneko Produktu Bideragarriaren (GPB) logikarekin aurrera egin behar duela blokeoak saihesteko. Hasierako entregagaiak berrikusi ziren: azpiegitura proposamena, GPB teknikoa, baliabideen estimazioa eta mantentze-protokoloak. Hurrengo saio teknikoetan xehetasunak fintzea eta dokumentazio hau ixtea erabaki zen.

2. Hedapenaren baldintzak

Plataformaren behin-behineko izena aurkeztu zen: Ágora, orain Komunikazio arloa baliozkotzen ari dena. Hasieran agora.ehu.eus domeinuarekin eta horri lotutako proben ingurune batekin (froga.agora.ehu.eus) aurrera egiteko aukera aztertzen ari da, betiere barne-araudiak horretarako aukera ematen badu. EHUko talde teknikoak, domeinu-izenen esleipena eta egitura koherenteak direla bermatzeko ardura duenak, azpidomeinuetarako baldintzak eta prozedurak berrikusiko ditu, eta berretsi ondoren eman beharreko pausoak jakinaraziko ditu, hori guztia komunikazio taldeak nortasunarekin, behin betiko izenarekin eta domeinuaren koherentzia instituzionalarekin lotutako alderdietan aurrera egin dezan zain.

3. Azpiegitura: instalazio modalitatea

Hedapen teknikorako aukerak berrikusi ziren, instalazioa EHUko berezko zerbitzarietan instalatzea eta SaaS modalitateko aukera aztertuz. Hasiera batean, on premise hedapenerantz aurrera egitea pentsatu bazen ere, proiektuaren hasiera mantsotu zezaketen  analisi teknikoko, dimentsionamenduko eta baliabideen eskuragarritasuneko behar gehigarriak identifikatu ziren.

Abiarazte arina ziurtatzeko eta hasierako fase horretan blokeoak saihesteko, EHUagora SaaS modalitatean hedatzea erabaki zen, behin-behinean. Ikuspegi horrek plataformarekin lan egiten hasteko aukera emango du, azterketa xehatua osatzen den bitartean, ondorengo fase batean, berezko zerbitzarietara migratzeko aukera baloratzeko.

Talde teknikoak azaldu zuen bere ohiko hedapena Dockerren oinarritzen dela, Postgres eta Redis barne, eta arkitektura erraz egokitu litekeela etorkizunean instalazio propio bat aukeratuz gero. Erabilera trinkoko kargak (bozketak, parte-hartze prozesu jendetsuak…) aurreikusteko, koreen eta RAM estimazio zehatza edukitzearen garrantzia azpimarratu zen.

4. Hazkundea eta eskalagarritasuna

Taldeak azpimarratu zuen ezinbestekoa dela plataforma blokeorik gabe hazi ahal izatea eta erabilera igoerei erantzutea. Funtsezko elementuak laburtu ziren:

• Baliabideen estimazio zehatza (cores, RAM eta gehienezko karga), batez ere parte-hartze handiko uneetarako, hala nola, bozketetarako.

• SaaS modalitateko hasierako hedapenak elastikotasuna eta egonkortasuna eskaintzen ditu, etorkizunean zerbitzari propioetara migratu ahal izateko analisia osatzen den bitartean.

• Decidim-en arkitektura (Docker, Postgres, Redis) modularra eta eskalagarria da, eta beharrezkoa denean azpiegitura handitzea ahalbidetzen du. 

• Aurrerago berrikusi beharko diren hazkunde-egoerak identifikatu ziren: erabiltzaileen igoera, karga intentsiboak eta eskalatze-kostuak.

Oro har, ondorioztatu zen SaaS ereduak proiektua berme guztiekin hastea errazten duela, behin betiko arkitektura aztertzen den bitartean.

5. Kode-biltegia

Subiranotasun teknologikoa dela eta, EHUk gordailu propioa izango duela erabaki zen. Orain, GitLab hobesten da, barne-erabileren arabera. Hala ere, hasierako hedapena SaaS modalitatekoa izango denez, biltegi egonkorra GitLab-en edo GitHub-en ostatatuko den erabakitzeko behin betiko erabakia proiektuaren hurrengo fase batera atzeratzea erabaki zen, zerbitzari propioetara migratuko den ala ez eta behin betiko fluxu teknikoa zein izango den argitzen denean.

6. Parte-hartzaileen egiaztapena eta kudeaketa

Eskuragarri zeuden metodoak berrikusi ziren: LDAP, SAML, Izenpe, BAQ eta OAuth. Taldea bat etorri zen sarrera erakundeen kredentzialen bidez egin behar dela esatean. Libo Revillak adierazi zuen SAML hobea dela bere sendotasun eta erraztasun teknikoagatik, eta beharrezko zehaztapenak bidaltzeko konpromisoa hartu zuen.

Puntu honetan, aldez aurretik parte-hartze dokumentuetan datuen mugari buruzko hausnarketa berreskuratu zen: unibertsitateak kredentzial aktiboak eta lotura-maila desberdina duten kolektiboak ditu, eta horrek zuzenean eragiten du LDAPerako eta beste integrazio batzuetarako datuen kalitate eta fidagarritasunean.

Unibertsitate-komunitatearen definizioa eztabaidatu zen, talde ezagunak (IIP, AZP eta ikasleak) eta “mugan” dauden profilak (Ikerbasque, kanpoko ikasleak edo kasu bereziak) bereizten. Datu batzuk behar bezain fidagarriak ez direla eta berrikuspena behar dutela adierazi zen. Gainera, hasiera batean datuen mugaren barruan dauden identitateekin soilik lan egingo dela adostu zen, hau da, erakunde autentifikazio-sistemetarako lotura eta fidagarritasuna erabat bermatuta daudenekin.

7. Baliabide teknikoen zenbatespena

Mantentze-laneterako, laguntzarako eta eskalagarritasunerako agertokiak planteatu ziren. EHUk Decidim-en corean parte hartzeko aukera eztabaidatu zen, nahiz eta gaur egun barne-taldeek ez duten Ruby-rekin lan egiten eta ikuspegi hau epe ertain-luzera planteatu beharko litzatekeen.

8. Egiteke dauden gaiak

Irekita dauden eta proiektuaren erreferentziako dokumentuetan oinarrituta garatu behar diren gaiak (TECH gai-zerrenda, dokumentazio funtzionala, aurretiko esperientziak eta parte-hartze esparrua) hurrengoak dira:

8.1 LDAP Decidim-ekin integratzeko lantaldearen aktibazioa

• EHUagoran autentifikazio instituzionala zehazteaz eta ezartzeaz arduratzen den talde teknikoa formalki martxan jartzea.

• LDAP/SAMLn eskuragarri dauden ezaugarriak berrikustea, “datu-mugari” eta “unibertsitate-komunitatearen” definizio operatiboari buruzko parte hartzeko dokumentuetan jasotako irizpideekin bat etorriz.

• Hasierako alta-mekanismoaren, gutxieneko metadatuen eta kontuen inportazio programatuaren premia posibleen ebaluazioa, TECH taldearen gai-zerrendan zehazten den moduan.

8.2 Domeinu-izena baliozkotzea

• Komunikazio- eta teknikari-taldeak elkarrekin baliozkotu behar dute agora.ehu.eus izenaren egokitasuna, koherentzia instituzionala eta unibertsitatearen nortasun digitalarekiko sendotasuna ziurtatuz.

• Onarpena beharrezkoa da domeinuak egiaztatzeko barne-mekanismoa aktibatzeko eta horien esleipen formalean aurrera egiteko.

• Baliozkotze hori Hedapen Markoaren dokumentuan deskribatutako praktiken eta etorkizuneko espazio parte-hartzaileetarako irizpideak bateratzeko beharraren barruan kokatzen da.

8.3 SaaS zerbitzuaren protokoloaren dokumentua

Dokumentuak hurrengoa jaso beharko du, gai-zerrendan aurreikusitakoa eta dokumentazio teknikoa handituta:

• Mantentze-lan ebolutiboa, prebentiboa eta zuzentzailea.

• Barne-euskarriaren eredua: 1. maila (Komunikatik) eta 2. maila (talde tekniko espezializatua), eskalatzeko protokoloekin.

• Segurtasuna eta monitorizazioa: HTTPS zifratua, logo auditagarriak, eguneroko segurtasun-kopiak, gorabeheren aurkako protokoloak eta arduradunak.

• Behar funtzionalen dokumentuetan jasotako hirugarrenen zerbitzuak integratzea (analisia, geolokalizazioa, bozketa segurua, egiaztapena…).

• Kredentzialak, rol administratzaileak eta ekintzen trazabilitatea kudeatzea.

• Eguneratzeak, aldaketen kontrola eta bertsio-arauak.

• Kontingentzia-prozedurak eta zerbitzuaren jarraitutasuna.