Indholdsfortegnelse

Introduktion

Formål

Formålet med dette dokument, er at beskrive systemkrav og opsætning for udviklere på projektet. Desuden beskrive en række værktøjer, der hjælper med udviklingen, som er anvendt i projektet.

Sammenhæng med øvrige dokumenter

-

Udvikling

Krav for at bygge projektet

Xcode, min version 1214.5.16

Swiftlint, min. version 0.41.0.: https://github.com/realm/SwiftLint

Xcode templates

Da alle filer skal indeholde headers, jvf. NSP anbefales det at man anvender følgende Xcode templates, når man koder for at garantere headers.

1. Download Xcode templates: 
   

   View file
   name NSP.zip height 250

2. Kopier "NSP" mappen til følgende lokation:

   Code Block
   title Xcode templates file path
   /Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File Templates

   
   Derefter bør din mappestruktur ser sådan ud:
   

3. Brug dine nye file templates, når du opretter filer:
   

Xcode Code Snippets

For at få en "NSP" short cut til at indsætte copy right header kan nedenstående fil placeres på følgende path:

...

Tools

Projektet indeholder en række tools, der anvendes under projektudvikling. De ligger alle i Tools mappen i repositoryet.

Generering af Localization tools

Alle strings er oprettet i et Localizely projekt (Claus Leth Gregersen er Owner på projektet): https://app.localizely.com/projects/3278b0a4-b1a5-4277-ba70-3159fb9dac9b/main/dashboard

...

Desuden anvendes R.swift til at tilgå strings via et typealias: Localizable

Generering af modeller via OpenAPI spec

Alle modeller der anvendes til JSON responses fra maternity API'et er genereret ud fra OpenAPI speccen. For at generere nye modeller anvendes nedenstående script.

Hvis udvikleren vil opdatere til en ny version af modellerne, skal man først opdatere opdatere models-version.config med den  med den version af backenden, som modellerne skal genereres ud fra (Det er kun versionsnummer, "gm-api-" skal ikke med)
Herefter kører man et autogenererings script til macOS, som køres fra roden af repositoryet på følgende måde:

./Tools/generate-models.sh

Krav til minimum version af openapi-generator er 5.3.0, for at kunne køre scriptet.

Når man opdaterer modellerne, er det vigtigt at man får koden og tests til at bygge igen og committer disse ændringer samlet, hvorefter der tagges i Git med "models-version/VERSIONSNUMMER", således at man altid kan se i Git historikken, hvornår ændringen af modellerne blev foretaget.

Sortering af Xcode projekt fil

For at undgå merge konflikter i projekt-filen, anbefales det at man - inden oprettelse af PR - anvender et script, der sorterer projekt-filen alfabetisk:

./Tools/sort-xcode.sh

Konfiguration

Projektet anvender Xocde Build Configurations til at styre forskellige build konfigurationer med.

...

enum BuildConfiguration: String {
    case debug = "Debug"
    case projectEnv = "ProjectEnv"
    case internalTest = "InternalTest"
    case test1clientTest = "Test1ClientTest"
    case test2clientTestMockMitID = "Test2ClientTestMockMitID"
    case release = "Release"
}

...

De forskellige konfigurationer udløser forskelligt setup af komponenter i app'en. Det ses i den statiske Configuration.build(for buildConfiguration: BuildConfiguration) -> Configuration metode.

Distribution

Distribution af test apps som IPA via Azure

Distribuering kræver at man opfylder kravene for at bygge projektet og at man har fastlane min. version 2.176.0: https://fastlane.tools/

Projektet distribueres som IPA via azure, hvor der er oprettet flere pipelines, hhv. "MinGraviditet iOS Appstore Release", "MinGraviditet iOS ClientTest Release", "MinGraviditet Firebase iOS ClientTestMockMitId Release" og "Min Graviditet App Store MinGraviditet iOS InternalTest Release"

Se afsnit 5.3 ang. versionering af app'en.

App Store

Man skal være i besiddelse af Sundhedsdatastyrelsens Apple Distribution certifikat for at signere app'en til App Store. Dette certifikat må aldrig være den del af det public Git respository. Derudover skal man have adgang til App Store Connect kontoen.

...

Se afsnit 5.3 ang. versionering af app'en.

Versionering

App'en kører efter en almindelig major.minor.patch versionering, som styres manuelt i xcodeproj-filen. Build nummeret opdateres automatisk med antallet git-commits, således at det altid ændrer sig, når man har lavet ændringer i koden. 

Build nummeret opdateres ved at køre "bump_release_version" lanen i fastlane, hvor den også tagger i git med den respektive version. Formatet er: release/VERSION_BUILDNUMMER (release/0.0.1_1000) 

 Branches

Der arbejdes efter en git-flow tankegang, hvor master-branchen indeholder det nyeste, der er godkendt af QA-teamet.

Der udvikles løbendes på develop-branchen via feature /bugfix/hotfix branches med pull requests til develop-branchen.

...