Så kopplar du DevOps till ditt designsystem

I går kväll, i ett inspirerat ögonblick, utvecklade jag en applikation. Jag började klockan sex på kvällen, och klockan ett var den redan driftsatt med allt som hör till, som enhets- och acceptanstester, SSL-certifikat och drift i Kubernetes. 

Med andra ord tog det bara sju timmar från idé till produktion. Och innan den var klar hade jag redan genomfört flera lyckade leveranser.

Hur är detta möjligt, kanske du undrar?

Svaret är att koppla Continuous Delivery-pipelinen till ett design system. Faktum är att DevOps faktiskt börjar redan före designfasen. Genom att implementera DevOps i design systemet får du en stabil utgångspunkt för din delivery pipeline och kan snabbare sätta i gång nya innovationer.

Ett design system är företagets röst

Design system har varit ett hett ämne ett tag. De uppstod ur behovet av enhetliga stilar och ger organisationer ett sätt att harmonisera sitt uttryck i grafiskt format.

Det finns flera definitioner av begreppet, men i grunden är ett design system en uppsättning element som gör det möjligt för team att designa och utveckla en produkt samtidigt som de följer organisationens eller företagets enhetliga röst och identitet. I dag blir det allt viktigare att ha ett sammanhållet bibliotek med stilar och komponenter att använda när nya tjänster skapas eller när ändringar görs i en befintlig applikation. Enkelt uttryckt är ett design system ett bibliotek med komponenter som delas, utvecklas och kan återanvändas.

Design system: open source och egenutvecklade

Det finns ungefär två olika typer av design system:

1. Open source-baserade, communitydrivna design system som är tillgängliga för alla, till exempel Google Material Design, Carbon och Polaris.

2. Design system som har utvecklats exklusivt för en organisation eller av organisationen själv, till exempel https://unity.com/design-portal eller https://www.eficode.com/cases/vaisala

Ett av mina favoritexempel på öppna design system är Australian Government Design System. Det omfattar designen, HTML- och CSS-exempel samt React-komponenter (React är ett av de mest populära JavaScript-ramverken för användargränssnitt, skapat av och underhållet av Facebook).

Ett bra design system bör inte bara innehålla designen utan även koden bakom den. Om du har en knapp finns till exempel färdig JavaScript-/React-, HTML- och CSS-kod som utvecklarna kan använda för att representera knappen och dess beteende.

DevOps börjar i designfasen

Traditionellt har det funnits ett glapp mellan designfasen och utvecklingsfasen. Det beror på att design drivs av UI-specialister, som gillar att arbeta med användargränssnitt, medan DevOps traditionellt har varit ett ansvar för drift- och backendutvecklare.

Ett välfungerande design system som omfattar DevOps är ett effektivt sätt att överbrygga detta glapp.

När du arbetar med User Experience (UX)-design – alltså det konkreta grafiska designarbetet för en applikation eller tjänst – behöver du till slut omvandla det till ett digitalt format. Olika designverktyg, som InVision, Figma och liknande, utför redan en del av arbetet för designers och utvecklare före utvecklingsfasen. Kopplingen börjar egentligen när de börjar implementera designen, vilket innebär att DevOps börjar redan i designfasen.

Stöder bra design system utveckling och driftsättning?

Nu kanske du undrar hur ett välimplementerat design system ser ut när det är smidigt integrerat med DevOps-metoder och verktyg. Ett välfungerande design system som effektivt stöder DevOps omfattar:

• Komponenter skrivna som React-komponenter, med lämplig styling och interaktion.

• Enhetstester, till exempel tester för UI-komponenter skrivna i Jest. 

• Exempel på hur användargränssnittet är kopplat till den faktiska backenddelen eller applikationens kärna.

• Koppling till infrastrukturen / Infrastructure as Code.

• Delivery pipelinen och kopplingen mellan din applikation och hela ramverket för automatisering. 

När du börjar arbeta med en applikation i ett välimplementerat design system finns applikationen redan i produktionsmiljön från det ögonblick du sätter i gång. Det är något vi på Eficode kallar zero-day delivery, och det var precis detta jag testade i går kväll när jag utvecklade min applikation på bara några timmar. 

Du sätter i gång applikationen från en mall som bygger på designsystemet, och efter den första commiten är den redan ansluten till din Continuous Delivery-pipeline och levererad till produktionsmiljön.

Leverans och release är inte samma sak

Det här arbetssättet tar bort spänningen i situationer som traditionellt har setts som de skrämmande ögonblicken då allt avgörs – du vet, när du trycker på knappen, släpper applikationen till dina användare, håller tummarna och hoppas att allt går bra.

Jag rekommenderar att skilja på begreppen ”leverans” och ”release”. Leverans bör vara den odramatiska delen, eftersom du kontinuerligt bör leverera de funktioner som implementeras.

Med Continuous Delivery (eller deployment) levererar du en fungerande applikation, men med ofärdiga funktioner, till produktionsmiljön. Sedan döljer du antingen funktionerna för användarna eller låter dem ligga i bakgrunden. Releasen sker när du faktiskt gör funktionerna tillgängliga för användarna.

När du arbetar på det här sättet är det ingen stor sak om något misslyckas, eftersom det går snabbt att rulla tillbaka eller åtgärda problem. När det sedan är dags för release vet du redan att allt fungerar, eftersom du har gjort misstagen tidigare.

Bra designsystem kan förändra företagskulturen

Det här moderna och smidiga arbetssättet behöver stödjas av en kulturförändring inom företaget. Personer från olika områden behöver samarbeta för att DevOps och designsystem ska kunna integreras. Du behöver skapa en återkopplingsloop mellan dem som utvecklar designsystemet och dem som använder det.

Det finns inte ett enda sätt att göra detta på, utan snarare en rad frågor som behöver besvaras innan du bestämmer hur du ska gå vidare:

• Vilka arbetssätt behövs för att faktiskt utveckla, implementera och dela designsystemet och komponenterna i det?

• Har du ett centraliserat team som ansvarar för designsystemet?

• Har du en egen Continuous Delivery-pipeline för designsystemet, där ni kan samarbeta med till exempel pull requests från utvecklarna?

Vilka arbetssätt behövs för att faktiskt utveckla, implementera och dela designsystemet och komponenterna i det?

Har du ett centraliserat team som ansvarar för designsystemet?

Har du en egen Continuous Delivery-pipeline för designsystemet, där ni kan samarbeta med till exempel pull requests från utvecklarna?

Du behöver också avgöra om designsystemet ska drivas av communityn, som Australian Government design system. Där kan vem som helst skapa en pull request, och sedan är det några personer som avgör om den ska godkännas och mergas in i designsystemet eller inte.

Börja med en praktikgemenskap eller en pilotgrupp

Att implementera DevOps i designsystemet behöver inte vara ett stort projekt. De flesta företag, åtminstone de större, har redan ett designsystem på plats. Det kanske bara består av grafiska riktlinjer, eller så är deras HTML- och CSS-bibliotek sammankopplade. Det finns sannolikt också applikationer som redan har utvecklats enligt designsystemet, så du behöver inte börja från början.

Ett sätt att utveckla designsystemet är att starta en praktikgemenskap med likasinnade personer som samlas kring ett gemensamt mål.

Ett annat sätt är att helt enkelt börja med ett av dina pågående projekt där det finns personer som är intresserade och har möjlighet att prova.

Vanligtvis är sådant här relativt enkelt att prova och implementera. Den svåra delen är att förändra företagskulturen och arbetssätten. Därför föredrar vi på Eficode att arbeta med piloter. Om du har en ny applikation på gång skulle jag börja utveckla designsystemet kring den applikationen.

När du har fått din Continuous Delivery-pipeline på plats kan du uppnå det vi kallar zero-day delivery. Med andra ord: när du börjar designa en ny tjänst är du redan i produktion.