Utveckling

Sammanfattning av verktygsval, arbetsmetoder och rutiner för utvecklingsfasen av vår DevOps-cykel.

Utvecklingsmiljö

Med utvecklingsmiljö här avser vi den lokala miljön som utvecklare sitter med.

Generella verktyg

Som generell editor föreslår vi Visual Studio Code med lämpliga plugins (dokumentera en rekommenderad grunduppsättning). Det bör dock vara fritt att använda andra editors om en känner sig effektivare med dem, så länge inte byggmiljöer påverkas eller licensmässiga problem uppstår.

Finns det några andra verktyg som alla skall/bör använda sig av? Skriv i så fall lite om dem här.

Språk och ramverk

Förstahandsvalet för utveckling av backendtjänster skall vara Java, med hjälp av ramverket Quarkus. Se bakgrunden till beslutet.

Databas

MariaDB används som databas i produktion. Quarkus har bra stöd för integration mot MariaDB. Ett tips är att använda Hibernate ORM för att generera upp databastabeller. Då blir det väldigt enkelt att köra samma kod med t.ex. H2.

Maven dependencies:

• quarkus-jdbc-mariadb

• quarkus-hibernate-orm

H2 används som in-memory databas i sandbox och vid enhetstester.

Maven dependencies:

• quarkus-jdbc-h2

OpenAPI

Vi genererar upp OpenAPI-specifikationer för våra applikationer. Detta gör vi för att få en bra dokumentation samtidigt som det gör det enkelt för klienter att anropa våra applikation. Denna OpenAPI-specifikation används även för att skapa ett API i vår API-Gateway WSO2.

WSO2 stödjer idag versioner av OpenAPI upp till 3.0.2. Ange därför detta i applikationens application.properties:

mp.openapi.extensions.smallrye.openapi=3.0.2

Maven dependencies:

• quarkus-smallrye-openapi

Namnsättning i Java-applikationer

Allt namnsätts på engelska.

Paket

• Paket namnsätts med gemener.

• Paketstrukturen ska inledas med se.sundsvall

• Exempel:

  • se.sundsvall.util

  • se.sundsvall.database

Klasser

• Klasser namnsätts enligt UpperCamelCase.

• Klassnamn ska vara substantiv.

• Undvik förkortningar i klassnamn.

• Exempel:

  • FeedbackSettingResource

  • Message

Metoder

• Metoder namnsätts enligt lowerCamelCase.

• Metodnamn ska vara verb.

• Exempel:

  • convertDateToString

  • deleteFeedbackSetting

Variabler

• Variabler namnsätts enligt lowerCamelCase.

• Försök undvika variabelnamn med endast en bokstav, förutom temporära variabler (t.ex. for-loop).

• Exempel:

  • personId

  • primaryContactMethod

Konstanter

• Konstanter namnsätts med versaler.

• Orden separeras med understreck ( _ ).

• Exempel:

  • THE_REQUEST_MUST_CONTAIN_A_REQUEST_BODY

Kodhantering

Kodhantering sker idag internt på våran GitLab server https://gitlab.sundsvall.se

Finns även möjlighet att ha kod i externa Github https://github.com/Sundsvallskommun/

Där bör man fundera man fram om det man jobbar med ska ligga open source eller om det är för en intern tjänst. Detta dikterar vart man ska lägga koden.

När ett nytt repository skapas i Gitlab då skapar driftansvariga även en Sandbox gren. Denna gren hanteras annorlunda än master grenen.

Hur fungerar det med branchhanteringen? När och hur skapas featurebrancher?

Testning

Enhetstester (https://en.wikipedia.org/wiki/Unit_testing )

Vi skall enhetstesta vår kod med en kodtäckning på minst 80%.

Enhetstester skall exekveras vid varje commit,

Applikationstester

Förutom enhetstester skall vi dessutom implementera helhetstester av våra applikationer/mikrotjänster, från anrop till svar inklusive integrationer.

För att inte vara beroende av angränsade applikationers hälsa skall integrationer simuleras med hjälp av WireMock (http://wiremock.org/ ) eller liknande.

Både positiva och negativa applikationstester skall implementeras.

Dessa tester skall minst exekveras vid varje commit.

Integrationstester

Helhetstester inkluderande integrationer mot angränsade applikationer skall genomföras inför varje release.

Acceptanstestning

Acceptanstestning skall utföras av verksamheten och omfatta hela lösningen i vilken “våra” applikationer/mikrotjänster är en delmängd.