6 parasta käytäntöä Adobe Experience Manager -sivustoprojekteihin

Muiden suurten ohjelmistojen tapaan Adobe Experience Manager voi hämmentää lukuisilla vaihtoehdoillaan. AEM on joustava tuote, joka tukee monenlaisia mukautuksia. Mikä tahansa vaatimus voidaan toteuttaa monin eri tavoin aina täysin mukautetusta ratkaisusta ratkaisuun, joka noudattelee tarkasti tuotteen ydinperiaatteita.

Meillä on paljon kokemusta AEM-ratkaisujen toteuttamisesta ja yritysten verkkosisällönhallintajärjestelmistä yleensä, joten tunnemme erilaisten ratkaisuvaihtoehtojen edut ja sudenkuopat. Ratkaisuarkkitehtuurin ja mahdollisen teknisen laajuuden lisäksi järjestelmän kehittämisessä on huomioitava kustannustehokkuus, ylläpito ja valmius tulevaisuuteen.

Tässä kirjoituksessa esittelemme muutamia avaintekijöitä, jotka on syytä huomioida AEM-toteutuksissa.

1. Rakenne ja arkkitehtuuri

Verkkosivujen rakenteen ja arkkitehtuurin suunnittelu alkaa vaatimusten kartoittamisesta ja yhdistämisestä järjestelmän valmiisiin toimintoihin mahdollisimman aikaisessa vaiheessa. Prototyyppien avulla voidaan esitellä vaihtoehtoisia ratkaisuja ja käytettävissä olevia valmiita toimintoja. Usein prosessia on mahdollista tehostaa huomattavasti hienosäätämällä hieman alkuvaatimuksia.

Muutamia esimerkkejä:

• Mukauta Context-Aware Configuration -kehyksillä erikseen sivuston osien ulkoasua ja toimintaa.
• Mallinna ulkoisista järjestelmistä tulevat dokumenttiluettelot Sling Dynamic Include -kehyksen kautta, jolloin niitä sisältävät sivut voidaan edelleen lisätä välimuistiin.
• Vältä valmiiden komponenttien kahdentaminen käyttämällä Sling Resource Mergeria.
• Poista responsiivinen CSS ja hyödynnä samaan tarkoitukseen AEM:n toiminnallisuuksia.
• Toteuta osa vaatimuksista AEM:n ulkopuolella esimerkiksi ulkoisten mikropalvelujen avulla. Tämä auttaa välttämään AEM:n ”väärinkäytön” WCMS:nä.
• Tee yli 95 % pyynnöistä välimuistiin tallennettaviksi ja varmista näin hyvä suorituskyky.

2. Ydinkomponentit

Adobe aloitti muutama vuosi sitten hankkeen nimeltä WCM Core Components. Ajatuksena oli siirtyä pois Foundation Components -nimellä tunnetuista komponenteista, jotka olivat vanhentuneet, ja tarjota niiden tilalle monipuolinen komponenttikirjasto, joka toimisi kaikkien projektien perustana.

Core Components -kirjasto tarjoaa yrityksille laadukkaita rakennuspalikoita edistyneitä sivustoja varten. Noudattaen samaa periaatetta mekin olemme kehittäneet oman kokoelman (projektikohtaisia) komponentteja. Samalla osallistumme aktiivisesti Core Components -kirjaston kehittämiseen ajan kuluessa.

Hyödyntämällä näitä komponentteja ja niiden perusideoita pystymme luomaan erittäin joustavia koodikantoja ja päivittämään komponentit yksitellen rikkomatta yhteensopivuutta taaksepäin.

3. Muokattavat mallit

Sivumallien tuominen yrityskäyttäjien saataville oli aiemmin kehittäjien tehtävä. Ennen kuin sisältöä tuottava henkilö saattoi siis käyttää tiettyä mallia, kehittäjän oli otettava tuo malli käyttöön AEM:ssä. Tämä viivästytti helposti sisällön julkaisua.

Viime vuosien aikana AEM:ään on kuitenkin lisätty uusi muokattavien mallien (Editable Templates) toiminto, mikä vähentää riippuvuutta IT-tuesta sivujen rakentamisen aikana. Tällä toiminnolla sisällöntuottajat voivat koota malleja itse AEM Touch UI -käyttöliittymän kautta.

4. Responsiiviset ruudukot ja tyylijärjestelmä

Responsive Grids (responsiiviset ruudukot) -toiminnolla yrityskäyttäjät voivat muokata joustavasti sivujen asettelua ja komponenttien toimintaa. Kun tätä toimintoa käytetään yhdessä tyylijärjestelmän (AEM Style System) kanssa, ennalta määriteltyjä tyylejä voidaan käyttää tinkimättä sivujen välisestä yhdenmukaisuudesta.

Perinteisessä työnkulussa suunnittelija mallinsi erilaiset asettelut ja kehittäjä lisäsi nuo mallinnukset tiettyyn malliin. Sisällöntuottaja valitsi sitten tuon mallin ja lisäsi siihen sisällön. Responsiiviset ruudukot yksinkertaistavat työnkulkua merkittävästi: sisällöntuottaja lisää sisällön ja voi mukauttaa asettelua itsenäisesti. Hänen ei siis tarvitse konsultoida kehittäjää responsiivisuuden osalta tai odottaa uuden asettelun käyttöönottoa. Tämä AEM 6.3:ssa esitelty ominaisuus tuo käyttäjille joustavuutta, eivätkä kehittäjät joudu enää tekemään näitä tehtäviä. Mallin muuttaminen ei edellytä kehitystyötä eikä erillistä käyttöönottoa.

Joustavuudella on kuitenkin hintansa: käyttäjien on nyt hallinnoitava itse sivujen komponenttien asettelua, ja tämä voi vaatia paljon vaivannäköä. Usein paras ratkaisu on etsiä kultainen keskitie, jossa osa asettelusta lukitaan ja osa jätetään joustavaksi. Me voimme auttaa sopivan tasapainon löytämisessä.

5. Verkkokehityksen parhaat käytännöt

Noudatamme kaikissa AEM-projekteissamme myös yleisiä kehitystyön parhaita käytäntöjä ja erityisiä teknisiä AEM-standardeja. Tässä niistä muutamia esimerkkejä:

• Koontiversion rikkoja myös korjaa sen.
• Kaikki uudet ominaisuudet on yksikkö- ja integraatiotestattava.
• Kun ominaisuus on valmis, siitä on lähetettävä muutosten yhdistämispyyntö.
• Tekninen päällikkö vertaistarkistaa koodimuutokset.
• Komponenttien kehittämisessä on käytettävä Sling Model -luokkia, vaikka komponentti olisi hyvin yksinkertainen.
• Käytä Proxy Component -malleja.
• Käyttäjädokumentaation ja teknisen dokumentaation on oltava aina ajan tasalla.
• Koodi on testattava sekä AEM:ssä että Dispatcherin kautta.
• Koodia ei saa monistaa, SonarQube-säännöt on määritettävä, jokainen koontiversio laukaisee SonarQube-skannauksen jne.

6. Täysi automaatio

Pyrimme parantamaan työmme laatua hyödyntämällä mahdollisimman paljon automaatiota. Käytämme AEM 6.5:n paikalliseen asentamiseen infrastructure-as-code-lähestymistapaa, jolloin voimme automatisoida palvelimien ja paikallisten ympäristöjen määrittämisen. Näin kehittäjät pääsevät työskentelemään muutamassa minuutissa paikalliseen ympäristöön, joka vastaa tarkasti tuotantoympäristöä. Ratkaisu sisältää jopa paikallisen Dispatcher-instanssin, jotta vältämme välimuistiin liittyvät sudenkuopat.

AEM-as-a-Cloud-Service-asennuksissa hyödynnämme Adoben Cloud Manageria, joka automatisoi päivitykset, tietoturvakorjaukset ja julkaisut. Laatua valvotaan ennalta määritettyjen ja mukautettavien laatuporttien avulla.

Aina kun versionhallintaan kirjataan koodimuutos, uusi koontiversio suoritetaan ja kehittäjät saavat ilmoituksen mahdollisista ongelmista. Muutokset viedään kohdeympäristöön, jolloin ne näkyvät välittömästi oikeassa järjestelmässä.

Noudattamalla näitä periaatteita voimme julkaista uudet versiot täysin automaattisesti. Tuotantoon julkaisu onnistuu yhdellä painikkeen painalluksella.

Loppusanat

Käyttämäsi WCMS:n uusimpien parhaiden käytäntöjen tunteminen on hyvä lähtökohta verkkosivuprojektille. Ehkä vielä tärkeämpää laadukkaan digitaalisen kokemuksen tuottamisessa on kumppani, joka tuntee nämä käytännöt ja myös valvoo niiden noudattamista. Uusien sivustojen perustamisen lisäksi näistä ohjeista on hyötyä myös olemassa olevan Adobe-alustan päivittämisessä ja laajentamisessa.