Näin yhdistät DevOpsin design systemiisi

Eilen illalla sain inspiraation hetkellä sovelluksen kehitettyä. Aloitin kello kuusi illalla, ja kello yksi se oli jo otettu käyttöön kaikkine ominaisuuksineen: mukana olivat esimerkiksi yksikkö- ja hyväksymistestit, SSL-sertifikaatit sekä Kubernetesissä toimiva ympäristö.

Toisin sanoen ideasta tuotantoon kului vain seitsemän tuntia. Ja ennen kuin sovellus oli valmis, olin jo tehnyt useita onnistuneita toimituksia.

Miten tämä on mahdollista, saatat kysyä?

Vastaus on Continuous Delivery -putki, joka on yhdistetty design systemiin. DevOps alkaa itse asiassa jo ennen suunnitteluvaihetta. Kun DevOps otetaan osaksi design systemiä, saat toimitusputkelle vankan lähtökohdan ja voit käynnistää uusia innovaatioita nopeammin.

Design system on yrityksen ääni

Design systemit ovat olleet pinnalla jo jonkin aikaa. Ne syntyivät tarpeesta yhtenäisille tyyleille, ja niiden avulla organisaatio voi yhdenmukaistaa ilmaisunsa visuaalisessa muodossa.

Termille on useita määritelmiä, mutta pohjimmiltaan design system on joukko elementtejä, joiden avulla tiimit voivat suunnitella ja kehittää tuotetta organisaation tai yrityksen yhtenäistä ääntä ja identiteettiä noudattaen. Nykyään on yhä tärkeämpää, että käytössä on yhtenäinen tyyli- ja komponenttikirjasto uusia palveluita luotaessa tai olemassa olevaa sovellusta muutettaessa. Yksinkertaisesti sanottuna design system on yhteinen, kehittyvä ja uudelleenkäytettävä komponenttikirjasto.

Design systemit: avoimen lähdekoodin ratkaisut ja itse rakennetut järjestelmät

Design systemeitä on karkeasti ottaen kahta eri tyyppiä:

1. Avoimen lähdekoodin, yhteisölähtöiset design systemit, jotka ovat kaikkien saatavilla, kuten Google Material Design, Carbon ja Polaris.

2. Vain tietylle organisaatiolle tai organisaation itsensä kehittämät design systemit, kuten https://unity.com/design-portal tai https://www.eficode.com/cases/vaisala

Yksi suosikeistani avoimista design systemeistä on Australian Government Design System. Se sisältää suunnittelun, HTML- ja CSS-esimerkit sekä React-komponentit (React on yksi suosituimmista JavaScript-käyttöliittymäkehyksistä, jonka Facebook on luonut ja jota se ylläpitää).

Hyvän design systemin tulisi sisältää suunnittelun lisäksi myös suunnittelun taustalla oleva koodi. Jos käytössä on esimerkiksi painike, kehittäjille olisi valmiina JavaScript-/React-, HTML- ja CSS-koodi, joka toteuttaa painikkeen ja sen toiminnallisuuden.

DevOps alkaa suunnitteluvaiheesta

Perinteisesti suunnitteluvaiheen ja kehitysvaiheen välillä on ollut kuilu. Tämä johtuu siitä, että suunnittelua ohjaavat käyttöliittymäasiantuntijat, jotka työskentelevät mielellään käyttöliittymien parissa, kun taas DevOps on perinteisesti ollut operaatio- ja backend-kehittäjien vastuulla.

Hyvin toteutettu, DevOpsin sisältävä design system on tehokas tapa kuroa tämä kuilu umpeen.

Kun teet User Experience (UX) -suunnittelua eli sovelluksen tai palvelun varsinaista visuaalista suunnittelua, se on lopulta muutettava digitaaliseen muotoon. Erilaiset suunnittelusovellukset, kuten InVision, Figma ja vastaavat, tekevät jo osan työstä suunnittelijoiden ja kehittäjien puolesta ennen kehitysvaihetta. Yhteys alkaa jo, kun suunnitelmaa ryhdytään toteuttamaan, eli DevOps alkaa suunnitteluvaiheesta.

Tukevatko hyvät design systemit kehitystä ja käyttöönottoa?

Saatat nyt pohtia, miltä hyvin toteutettu design system näyttää, kun se on sujuvasti integroitu DevOps-käytäntöihin ja -työkaluihin. DevOpsia tehokkaasti tukeva design system sisältää:

• React-komponentteina toteutetut komponentit, joihin sisältyvät sopiva tyyli ja vuorovaikutus.

• Yksikkötestit, kuten Jestillä kirjoitetut käyttöliittymäkomponenttien testit.

• Esimerkit siitä, miten käyttöliittymä yhdistetään varsinaiseen backendiin tai sovelluksen ytimeen.

• Yhteyden infrastruktuuriin / Infrastructure as Codeen.

• Toimitusputken sekä sovelluksesi liittämisen koko automaatiokehykseen.

Kun alat työstää sovellusta hyvin toteutetussa design systemissä, sovellus on tuotantoympäristössä heti työn alkaessa. Me Eficodella kutsumme tätä zero-day deliveryksi, ja juuri tätä kokeilin eilen illalla kehittäessäni sovellukseni vain muutamassa tunnissa.

Käynnistät sovelluksen mallipohjasta, joka perustuu design systemiin. Ensimmäisen commitin jälkeen se on jo yhdistetty Continuous Delivery -putkeesi ja toimitettu tuotantoympäristöön.

Toimitus ja julkaisu eivät ole sama asia

Tämä toimintatapa poistaa jännityksen tilanteista, joita on perinteisesti pidetty pelottavina totuuden hetkinä – tiedäthän sen hetken, kun painat nappia, julkaiset sovelluksesi käyttäjille, pidät peukkuja ja toivot kaiken menevän hyvin.

Suosittelen erottamaan käsitteet ”toimitus” ja ”julkaisu” toisistaan. Toimituksen pitäisi olla huomaamaton osa työtä, sillä toteutettavia ominaisuuksia tulisi toimittaa jatkuvasti.

Continuous Deliveryssa (tai deploymentissa) toimitat toimivan sovelluksen, mutta keskeneräiset ominaisuudet, tuotantoympäristöön. Piilotat toiminnallisuudet käyttäjiltäsi tai pidät ne taustalla. Julkaisu tapahtuu, kun otat nämä ominaisuudet todella käyttöön käyttäjillesi.

Tällä tavoin työskennellessä epäonnistuminen ei ole suuri asia, sillä palautus aiempaan versioon tai korjausten tekeminen käy nopeasti. Julkaisupäivänä tiedät jo, että kaikki toimii, koska virheet on tehty aiemmin.

Hyvät design systemit voivat muuttaa yrityskulttuuria

Tämä moderni ja sujuva työskentelytapa tarvitsee tuekseen muutoksen yrityksen kulttuurissa. Eri alojen ihmisten on tehtävä yhteistyötä, jotta DevOps ja design systemit voidaan integroida. Design systemiä kehittävien ja sitä käyttöön ottavien ihmisten välille on luotava palautesilmukka.

Tähän ei ole yhtä ainoaa tapaa, vaan ennen etenemistavan valintaa on vastattava moniin kysymyksiin:

• Mitä käytäntöjä tarvitaan design systemin ja sen komponenttien kehittämiseen, käyttöönottoon ja jakamiseen?

• Onko teillä keskitetty tiimi, joka vastaa design systemistä?

• Onko design systemillä oma Continuous Delivery -putki, jossa voitte tehdä yhteistyötä esimerkiksi kehittäjien pull requestien avulla?

Mitä käytäntöjä tarvitaan design systemin ja sen komponenttien kehittämiseen, käyttöönottoon ja jakamiseen?

Onko teillä keskitetty tiimi, joka vastaa design systemistä?

Onko design systemillä oma Continuous Delivery -putki, jossa voitte tehdä yhteistyötä esimerkiksi kehittäjien pull requestien avulla?

Teidän on myös päätettävä, tehdäänkö design systemistä yhteisölähtöinen Australian Governmentin design systemin tapaan. Siinä kuka tahansa voi tehdä pull requestin, minkä jälkeen muutama henkilö päättää, hyväksytäänkö ja yhdistetäänkö se design systemiin.

Aloita käytäntöyhteisöstä tai pilottiryhmästä

DevOpsin käyttöönoton design systemissä ei tarvitse olla suuri hanke. Useimmilla yrityksillä, ainakin suuremmilla, on jo design system käytössä. Se voi koostua vain graafisista ohjeistuksista tai siihen voi olla yhdistetty HTML- ja CSS-kirjastoja. Todennäköisesti joitakin sovelluksia on myös kehitetty design systemin mukaisesti, joten kaikkea ei tarvitse aloittaa alusta.

Yksi tapa kehittää design systemiä on perustaa käytäntöyhteisö, joka koostuu samanhenkisistä ihmisistä ja jolla on yhteinen tavoite työn tekemiseen.

Toinen tapa on aloittaa yhdestä nykyisestä projektista, jossa työskentelee ihmisiä, joita asia kiinnostaa ja jotka pystyvät kokeilemaan sitä.

Yleensä näitä asioita on verrattain helppo kokeilla ja ottaa käyttöön. Vaikeinta on muuttaa yrityskulttuuria ja käytäntöjä. Siksi me Eficodella suosimme pilotointia. Jos teillä on uusi sovellus tulossa, aloittaisin design systemin kehittämisen sen ympärille.

Kun otat Continuous Delivery -putken käyttöön, voit saavuttaa sen, mitä kutsumme zero-day deliveryksi. Toisin sanoen kun aloitat uuden palvelun suunnittelun, se on jo tuotannossa.