ci.adoc

Kontinuerlig integrasjon

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

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: gradle og maven

  • 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 også mer krevende og tungvint

• gradle

  • konfigurerbare byggetrinn sekvensieres basert på avhengigheter

  • konfig.filene (settings.gradle og build.gradle) er forståelige

Enkelt prosjektoppsett

Enkle prosjekter består av én modul og mappe

• settings.gradle og build.gradle konfigurerer bygg

• gradlew/gradlew.bat og gradle-mappe må inkluderes

Eksempel:

• desktop-app med javafx og fxml

• ikke noe behov for gjenbruk av kjernelogikk i andre prosjekter

simpleexample

• eksempel på én-modul-prosjekt

  • javafx+fxml-app

  • standard mapper for java

  • gradle-filer

simpleexample forts.

• standard innhold i build.gradle

  • plugins - tillegg som passer til typen prosjekt, f.eks.

  • repositories - hvor finnes tillegg og bibliotek (jar-filer)

  • dependencies - hvilke bibliotek brukes og til hva/når

• tillegg-spesifikk konfigurasjon, f.eks.

  • oppstartsklasse for java

  • javafx-versjon og -moduler som brukes

simpleexample forts.

• build.gradle plugins

  • application - java-app med main-metode, som kan pakkes som kjørbar jar

  • org.openjfx.javafxplugin - javafx-app

plugins {
	id 'application'
	id 'org.openjfx.javafxplugin' version '0.0.8'
}

Modulært prosjektoppsett

Flermodul-prosjekter har delmoduler i undermapper

• settings.gradle i hovedmappa navngir hovedprosjektet og delmodulene

• gradlew/gradlew.bat og gradle-mappe må inkluderes i hovedmappa

• delmodulene (i undermappene) trenger (bare) egen build.gradle-fil

Eksempel:

• klient-tjener-app

• (noe) felles kjernelogikk i klient og tjener

• kan ha flere klienter, f.eks. desktop og mobil (og web)

Modularitet

• et modulært system er mer oversiktlig

  • moduler er relativt selvstendige enheter

  • eksplisitte avhengigheter mellom moduler

  • gjenbrukes på tvers av prosjekter

• tilsvarer i java et sett pakker

  • skiller mellom API og interne pakker

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

multiexample

• eksempel på fler-modul-prosjekt

  • core - kjernelogikk

  • fx - javafx+fxml-app

  • jaxrs - REST API

  • jersey - web-server-app

  • webreact - web-klient

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!

Avhengigheter forts.

• avhengigheter er eksplisitte

  • deklareres i build.gradle i dependencies-seksjonen

  • krever (fullt) navn og versjon (major.minor.micro)

  • bibliotek må finnes i deklarerte repositories

• formålet angir når avhengigheten brukes

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

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

  • implementation - kjøring (men ikke komp.) av vanlig kode

  • testImplementation - kjøring (men ikke komp.) av testkode

IDE-støtte

• importere gradle-konfigurerte prosjekter

• basere egen konfigurasjon på gradle sin

  • kildekodemapper

  • avhengigheter

• utføre gradle-oppgaver, f.eks. kjøre tester

Eclipse-støtte

• New > Project…​ > Gradle Project: opprette nytt java-prosjekt, ferdig oppsatt med fornuftig gradle-konfigurasjon

• Import…​ > Existing Gradle Project

• > Gradle > Refresh Gradle Project: oppdaterer Eclipse sin prosjektkonfigurasjon fra gradle-konfigurasjonen

  • kildekodemapper

  • avhengigheter

• paneler

  • Gradle Tasks

  • Gradle Executions

CI @ gitlab

• gitlab kan konfigureres til å bygge, når endrer `push`es til et repo

• .gitlab-ci.yml inneholder byggeinstruksjoner

• hele repoet sjekkes først ut

• så utføres byggeinstruksjoner iht. innstillinger