...

Når dette er sat, vil alle filer i projektet få indsat headeren automatisk ved oprettelse af filen. At der er Den påkrævede copyright på filerne opretholdes bliver også opretholdt ved hjælp af Spotless, som fejler hvis den scanner .kt, .kts eller .xml filer uden headeren.

Copyright headern som Spotless bruger ligger i mappen spotless/ med versioner til hver af de 3 filtyper som kræver headern.

Tools

Projektet indeholder en række tools, der anvendes under udvikling.

...

Hvis macOS afviser, at køre CLI applikationen, kan du gå til System Preferences -> Security & Privacy og trykke "Open Anyway". CLI'en er et custom lavet 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.

Signering

Dertil kræver byg og signering af APK/bundles eller Release at man har adgang til keystore filen og signing info. For at bygge lokalt kræver det man har oprettet en local.properties  fil i roden af projektet, som indeholder keystore password, key alias og key password i formattet:

keystore_password=SuperSecretPassword
private_alias=MyKeyAlias
private_password=MyPrivatePasswordHere

Det er vigtigt at informationen i local.properties filen og selve keystore filen (.jks) IKKE ikke uploades til version control (De er pt. inkluderet i .gitignore).

Konfiguration

Beskrivelse af de nuværende konfigurationer kan findes på Installationsvejledningen https://www.nspop.dk/pages/viewpage.action?pageId=121373687#GravidiDK(Android)Installationsvejledning-Indledning

Udvikleren vælger selv en flavor og en buildtype i Android Studio, som derefter kan bygges og køres. Under udvikling bruges debug buildtypen, da denne outputter logs i logcat.

Alle bygge konfigurationer skal findes i projektets build.gradle.kts filer. Der findes en build.gradle.kts som deles af hele projektet og derunder findes der en build.gradle.kts for hvert modul af appen (App, Api, Repo, Shared). 

Hvert modul har deres eget ansvarsområde, så api/build.gradle.kts definerer f.eks. hvilke endpoints APIet skal ramme og app/build.gradle.kts sætter suffix på pakkenavnet, så det er muligt at have flere versioner af appen installeret på samme tid.

Alle delte strings ligger i `shared`-modulet, som er inkluderet i alle andre moduler. Siden alle moduler har deres egen R-fil, kan den delte strings R-fil importeres ind i filen ved at bruge:

import dk.nsp.mingraviditet.core.shared.R as sharedR

Signering

For at bygge release udgaver til Google Play / Firebase, skal de signeres med MinGraviditets Keystore (MinGraviditetKeystore20211203.jks). 

For at bygge lokalt kræver det man har local.properties  filen i roden af projektet, som indeholder keystore password, key alias og key password i formatet:

keystore_password=SuperSecretPassword
private_alias=MyKeyAlias
private_password=MyPrivatePasswordHere

Det er vigtigt at informationen i local.properties filen og selve keystore filen (.jks) IKKE ikke uploades til version control (De er pt. inkluderet i .gitignore).

For at kunne bygge skal disse filer være tilgængelige på maskinen der bliver bygget på:

local.properties
signing
├── MinGraviditetKeystore20211203.jks
└── min-graviditet-test-4807133482ad.json

Konfiguration

Beskrivelse af de nuværende konfigurationer kan findes på Installationsvejledningen https://www.nspop.dk/pages/viewpage.action?pageId=121373687#GravidiDK(Android)Installationsvejledning-Indledning

Udvikleren vælger selv en flavor og en buildtype i Android Studio, som derefter kan bygges og køres. Under udvikling bruges debug buildtypen, da denne outputter logs i logcat.

Alle bygge konfigurationer skal findes i projektets build.gradle.kts filer. Der findes en build.gradle.kts som deles af hele projektet og derunder findes der en build.gradle.kts for hvert modul af appen. 

Hvert modul har deres eget ansvarsområde, så api/build.gradle.kts definerer f.eks. dependencies som det modul har brug for.

Library versioner er defineret i gradle/libs.version.toml . Hvis udvikleren ønsker at opdatere Library versioner er defineret i gradle/libs.version.toml . Hvis udvikleren ønsker at opdatere versionerne, bruges 

./gradlew dependencyUpdates

Læs mere i projektets README.md

Versionering

Appen versioneres efter almindelig major.minor.patch (version code). Projektet er opdelt i moduler, så styring af disse er samlet i root project build.gradle.kts i de to properties navngivet versionName  og versionCode .

Version name er tiltænkt man manuelt opdatere når man laver changes som er passende på en af de tre niveauer.
Version code bliver automatisk forhøjet for hvert commit på den pågældende branch

Tags

Releases af appen markeres med Git tags på formen release/major.minor.patch_versioncode 

Det er ikke tilladt at lave en release, uden der er et tilhørende tag på det commit man bygger fra (Dette er pt. ikke håndhævet ved manuelle byg, så dette er udviklerens eget ansvar at overholde).

Denne regel er indbygget i vores lanes i Fastlane, som et pre-check for at kunne køre de lanes som uploader appen - Heraf grunden til at Fastlane er anbefalt til distribution.

Distribution

Fastlane

Hele processen med at bygge og uploade til Firebase er blevet automatiseret med værktøjet Fastlane (https://fastlane.tools/).

Krav og installationsvejledninger kan findes på https://docs.fastlane.tools/getting-started/android/setup/#installing-fastlane

Ved at bruge kommandoen fastlane før man alle de mulige "lanes" frem, hvor man får nedenstående output.

 BuildLogic modulet

Projektet indeholder et vigtig gradle modul, som er med til at sætte alle android modulerne op på en ensartet måde; :build-logic.

Modulet er med til at sætte gradle versioning catalogs op og indeholder inkluderer en modul kalder :convention 

:convention er en samling af gradle plugins, som kan bruges af appens moduler, f.eks. bruger feature modulerne det gradle plugin som hedder "mingraviditet.android.feature" og er defineret i filen AndroidFeatureConventionPlugin.kt

I :convention er der også defineret appens minimum version, targetSdk, flavors og generelle kotlin & compose opsætning.

Versionering

Appen versioneres efter almindelig major.minor.patch (version code). Projektet er opdelt i moduler, så styring af disse er samlet i root project build.gradle.kts i de to properties navngivet versionName  og versionCode .

Version name er tiltænkt man manuelt opdatere når man laver changes som er passende på en af de tre niveauer.
Version code bliver automatisk forhøjet for hvert commit på den pågældende branch

Tags

Releases af appen markeres med Git tags på formen release/major.minor.patch_versioncode 

Det er ikke tilladt at lave en release, uden der er et tilhørende tag på det commit man bygger fra (Dette er pt. ikke håndhævet ved manuelle byg, så dette er udviklerens eget ansvar at overholde).

Denne regel er indbygget i vores lanes i Fastlane, som et pre-check for at kunne køre de lanes som uploader appen - Heraf grunden til at Fastlane er anbefalt til distribution.

Distribution

Fastlane

Hele processen med at bygge og uploade til Firebase er blevet automatiseret med værktøjet Fastlane (https://fastlane.tools/).

Krav og installationsvejledninger kan findes på https://docs.fastlane.tools/getting-started/android/setup/#installing-fastlane

Ved at bruge kommandoen fastlane før man alle de mulige "lanes" frem, hvor man får nedenstående output.

Welcome to fastlane! Here's what your app is set up to do:
+

Welcome to fastlane! Here's what your app is set up to do:
+--------+-------------------------------------+--------------------------------------------------------------------------------------------------------+
|                                                                Available lanes to run                                                                 |
+--|
+--------+-------------------------------------+--------------------------------------------------------------------------------------------------------+
| Number | Lane Name                           | Description                                                                                            |
+-|
+--------+-------------------------------------+--------------------------------------------------------------------------------------------------------+
| 1      | android setGitTag                   | Add version tag to commit                                                                              |
| 2      | android bumpReleaseVersion          | Bump, commit, tag and (optionally) push commit and tag                                                 |
| 3      | android allUnitTests                |                   ---+
| 1      | android setGitTag             | Add version tag        to commit                                                     |
| 42      | android generateQaReports       bumpReleaseVersion    | ChecksBump, that git is in a correct state and we have a tag. Then generates Unit Test and Coverage reports |
| 5commit, tag and (optionally) push commit and tag           | android uploadForProjectEnvironment | Upload Project Environment version to Firebase    |
| 3      | android allUnitTests          |                                  |
| 6      | android uploadForInternalTest       | Upload Internal Test version to Firebase                       |
| 4      | android generateQaReports     | Checks that git is in a correct state and we have a tag. Then generates Unit  |
|        |
| 7      | android uploadForTest1              | Upload Test1 version to Firebase   | Test and Coverage reports                                                     |
| 5      | android uploadForInternalTest  |
| 8Upload Internal Test version to Firebase | android uploadForTest2              | Upload Test2 version to Firebase                 |
| 6      | android uploadForGooglePlay   | Build GooglePlay .aab and upload to Google Play (Takes the Service account    |
|        |                  |
| 9      | android uploadForGooglePlay    | json file path as |a Buildparam) GooglePlay .aab and upload to Google Play (Takes the Service account json file path as a param)  |
| 0      | cancel                         |
| 0    | No selection,| exitcancel fastlane!                       | No selection, exit fastlane!                                                |
+--------+------------------  |
+--------+-----------+--------------------+------------------------------------------------------------------------------------+

Which number would you like to run?

...

1. Opdaterer version code ud fra antallet af commits (På tværs af repositoriets branches) og skriver det ind i root projects ./build.gradle .kts
2. Commiter koden
3. Opretter et release tag i git
4. Giver udvikleren valget om at pushe commitet og det oprettede tag til remote repository

Efter denne operation er kørt (såfremt man valgte at sige ja til pkt. 4), vil det commit man står på være klar til lave en release.

 Release lanes

Fælles for alle release lanes er at de kører en pre_release_actions lane, som sørger for at git er i et korrekt state for at bygge og uploade en release udgave af den valgte flavor.

...

• Flavor: ProjectEnv
• TPA Track: ProjectEnv

...

• Flavor: internalTest
• TPA Track: internalTest

...

• Flavor: Staging1
• TPA Track: Test1

en release.

 Release lanes

Der kan releases til Firebase vha uploadForInternalTest og til GooglePlay ved hjælp af uploadForGooglePlay

...

Release til Google Play

For at kunne release kræves det at man har adgang til Sundhedsdatastyrelsens Google Play projekt.
Projektet er opsat i Google Play til at benytte sig af app bundles (.aab). 

...