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?

Anchor
test test

Tester

Funktionella tester

Image Removed

Image Added

Enhetstester (https://www.javatpoint.com/unit-testing )

Dessa tester ska fokusera på att testa enskilda isolerade komponenter och dess funktionalitet.

Vi ska enhetstesta vår kod med en kodtäckning på minst 80%. En analys av kodtäckningen ska utföras vid varje commit och varna vid för låg kodtäckning.

Både positiva och negativa enhetstester ska implementeras.

Dessa tester ska vara automatiska och exekveras vid varje commit.

Integrationstester (https://www.javatpoint.com/integration-testing )

Dessa tester ska fokusera på att testa integrationerna mellan olika komponenter.

Exempel på integrationer som ska testas:

• integration mot angränsade applikationer

• integration mot databas

För att inte vara beroende av angränsade applikationers hälsa ska integrationer simuleras med hjälp av WireMock (http://wiremock.org/ ) eller liknande.
Databasen som används kan vara en “in-memory”-databas, exempelvis H2.

Dessa tester ska vara automatiska och exekveras vid varje commit.

Systemtester (https://www.javatpoint.com/system-testing )

Dessa tester ska fokusera på att testa systemets helhet. Dessa tester ska omfatta hela lösningen i vilken “våra” applikationer/mikrotjänster är en delmängd.

Både positiva och negativa systemtester ska utföras.

Dessa tester kan antingen vara automatiska eller manuella och ska exekveras inför varje release.

Acceptanstester (https://www.javatpoint.com/acceptance-testing )

Acceptanstestning ska utföras av kunden. Dessa tester ska fokusera på att säkerställa att systemet motsvarar de specificerade kraven.

Dessa tester ska exekveras inför varje release.

Icke-funktionella tester

Prestandatester

Användbarhetstester

Kompatibilitetstester