1. Indholdsfortegnelse

2. Introduktion

2.1. 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.

2.2. Sammenhæng med øvrige dokumenter

-

3. Udvikling

3.1. Krav for at bygge projektet

Xcode, min version 12.5.1

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

3.2. 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: 
    NSP.zip

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

    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:


3.3. 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:

~/Library/Developer/Xcode/UserData/CodeSnippets

nsp-header.codesnippet


3.4. Tools

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

3.4.1. 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

Localizely konfigurationen er defineret i localizely-cli.json filen i roden af repositoryet og kan justeres til Localizely branches osv.

Med følgende CLI kan man opdatere Localizable.strings så den svarer til seneste opdateringer i Localizely:

./localizely


Hvis macOS afviser, at køre CLI applikationen, kan du gå til System Preferences -> Security & Privacy og trykke "Open Anyway". CLI'en er et hjemmelavet Rust værktøj, der anvendes indtil Localizely kommer med deres eget officielle CLI (skulle være klar i løbet af august 2021). Det er altså ikke signeret korrekt, hvorfor macOS advarer imod programmet.


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

3.4.2. 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 models-version.config 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.

3.4.3. 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

4. Konfiguration

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

Der eksisterer følgende konfigurationer:

BuildConfiguration enum
enum BuildConfiguration: String {
    case debug = "Debug"
    case projectEnv = "ProjectEnv"
    case internalTest = "InternalTest"
    case test1 = "Test1"
    case test2 = "Test2"
    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.

5. Distribution

5.1. 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 Firebase Release" og "Min Graviditet App Store Release"

Se afsnit 5.3 ang. versionering af app'en.

5.2. 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.

For at sikre ens distribuering af apps med forskellige konfigurationer, anvendes fastlane med følgende lane: app_store. Denne lane anvender FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD som environment variabel for at forbinde til App Store Connect. Hvis dette ikke angives spørger den efter login information i stedet.

Se afsnit 5.3 ang. versionering af app'en.

5.3. 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) 

6.  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.

Når der skal sendes ændringer til QA review, merges developer til qa-branchen, hvorefter der oprettes pull request fra qa til master.


  • No labels