Kontinuerlig integrasjon

Smidig utfordring

  • Hvordan iterere raskt?

    • skrive korrekt kode raskt

    • være trygg på kvaliteten

    • levere ofte, for å få tilbakemelding fra brukere

  • Mange nivåer av testing

    • egen kode - enhetstesting

    • koden innen teamet - integrasjonstesting

    • hele systemet - systemtesting (og evt. deployment)

Kontinuerlig integrasjon (CI)

Automatisering av alt som fremmer kvalitet, men som tar tid, f.eks.

  • kompilering og bygging av jar-filer (generelt avledete artifakter)

  • kjøring av enhets- og integrasjonstester

  • analyser av ulike typer kvalitet (formatering, kodingsstandarder, vanlige feil, …​)

  • bygging av kjørbart system og kjøring av systemtester

Smidig løsning

  • Kontinuerlig - bygg, sett sammen og test

  • Innimellom - lever (release) og sett i drift/prod. (deploy)

  • Alt for mye arbeid uten støtte

    • byggeverktøy automatiserer prosessen

    • byggetjenere sikrer reproduserbar prosess

Byggeverktøy

  • strukturert tilnærming basert på meta-informasjon

    • prosjekt-type (språk, plattform, …​)

    • struktur og avhengigeter

    • rammeverk og bibliotek automatisk lastet fra nettet

  • sekvens av byggetrinn med innbyrdes avhengigheter

  • mange konfigurasjonsmuligheter med gode standardinnstillinger (convention over configuration)

  • prosjektmaler gjør initiell rigging enklere

  • i stor grad styrt av tillegg (plugins) til et generell system

Byggeverktøy forts.

  • to hovedalternativer for Java er gradle og maven, andre språk har tilsvarende, f.eks. yarn for Javascript og sbt for Scala.

    • litt ulik terminologi og logikk, men forskjellene er tildels overfladiske

    • begge kan mye det samme, så valget er i stor grad pragmatisk (!)

    • masse materiale å lære fra, uansett valg

  • maven

    • mer modent og strukturert, men oppfattes som noe mer krevende og tungvint

    • sekvensierer byggetrinn basert på overordnede faser

  • gradle

    • konfigurerbare byggetrinn sekvensieres basert på avhengigheter

Maven og pom.xml

  • pom.xml konfigurerer bygg

    • nødvendige biblioteker for kompilering, kjøring og testing

    • versjon og konfigurasjon av maven-tillegg som trengs i bygget

    • konfigurasjon av kompilering (java-versjon) og kjøring (hovedklasse)

  • standardinnstillingene krever fire mapper for java

    • src/main/java inneholder "produktiv" java-kode

    • src/main/resources inneholder ressurser, f.eks. fxml- og png-filer

    • src/test/java inneholder testkode

    • src/test/resources inneholder ressurser spesifikke for testene, f.eks. datafiler

javafx-template

Eksempel på én-modul-prosjekt i (i javafx-template-kodelageret)

  • avhengigheter til biblioteker for javafx og jupiter (testing)

  • velger spesifikke versjon av en del maven-tillegg

  • Java 16 for kompilering (og kjøring)

  • app.App er hovedklassen for kjøring med maven-tillegget for javafx

javafx template structure

modules-template

Eksempel på fler-modul-prosjekt

  • to undermapper, core og ui, med hver sin pom.xml

    • core har kode (og tester) for domeneklasser

    • ui har GUI-kode med avhengigheter til JavaFX

    • modulspesifikk konfigurasjon er i respektive pom.xml-filer

  • pom.xml på toppnivå innholder

    • avhengigheter som er felles for (under)modulene

    • konfigurasjon av tillegg som brukes i (under)modulene

Modularitet

  • et modulært system er mer oversiktlig

    • moduler er relativt selvstendige enheter

    • eksplisitte avhengigheter mellom moduler

    • gjenbrukes på tvers av prosjekter

  • i Java tilsvarer en modul et sett pakker

    • skiller mellom API og interne pakker

    • distribueres som jar-fil (zip-fil med meta-data)

todo-list

  • eksempel på fler-modul-prosjekt

    • core - kjernelogikk

    • fxutil - hjelpekode for fxui

    • fxui - javafx+fxml-app

    • rest - REST API og server

    • integrationtests - integrasjonstester

    • springboot/restserver - alternativ server

Avhengigheter

  • De fleste applikasjon bygger på annen programvare

    • større rammeverk, f.eks. JavaFX (UI), Spring (web-server), React (web-klient), osv

    • bibliotek for spesifikke tjenester, f.eks. SL4J (logging), Jackson (JSON)

  • Det finnes store mengder prosjekter med åpen kildekode av høy kvalitet

  • Avhengigheter mellom moduler i samme prosjekt må også deklareres!

maven central

Avhengigheter forts.

  • avhengigheter er eksplisitte

    • deklareres i pom.xml i dependencies-seksjonen

    • krever navn (groupId og artifactId) og versjon (major.minor.micro)

    • bibliotek må finnes i deklarerte repositories

  • scope angir anledningen avhengigheten brukes i

    • compile - kompilering (og kjøring) av vanlig kode

    • test - kompilering (og kjøring) av testkode

    • runtime - trengs ved kjøring, men ikke kompilering

    • provided - trengs ved kompilering, men ikke ved kjøring (er implisitt med)

VSCode-støtte

  • gjenkjenner automatisk mapper med pom.xml som maven-prosjekter

  • konfigurerer editorstøtten og innebygget kompilering deretter

    • kildekodemapper

    • avhengigheter

  • ved større endringer av pom.xml og/eller mappestrukturen kan en be VSCode oppdatere sin forståelse av oppsettet

  • har tillegg for å utføre bygge-oppgaver, f.eks. kjøre tester, men like greit å bruke terminalen

CI @ gitlab

  • gitlab kan konfigureres til å bygge, når endringer overføres til et kodelager

  • .gitlab-ci.yml inneholder byggeinstruksjoner

  • hele kodelageret klones over i en virtuell maskin

  • så utføres byggeinstruksjoner iht. innstillinger

Norwegian University of Science and Technology