Skip to content
Snippets Groups Projects
ci.adoc 6.1 KiB
Newer Older
= Kontinuerlig integrasjon
:customcss: slides.css
:icons: font
:includedir: revealjs/includes/
:LECTURE_TOPIC: Continuous Integration
:LECTURE_NO: 
include::{includedir}header.adoc[]
== 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

[.smaller-60]
* Hvordan iterere raskt?
** skrive korrekt kode raskt
** være trygg på kvaliteten
** levere ofte, for å få tilbakemelding fra brukere

[.smaller-60]
* Mange nivåer av testing
** egen kode - enhetstesting
** koden innen teamet - integrasjonstesting
** hele systemet - systemtesting (og evt. deployment)

== Smidig løsning

[.smaller-80]
* 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

[.smaller-80]
* 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.

[.smaller-60]
* 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

[.smaller-60]
Enkle prosjekter består av én modul og mappe

[.smaller-60]
* *settings.gradle* og *build.gradle* konfigurerer bygg
* *gradlew*/*gradlew.bat* og *gradle*-mappe må inkluderes

[.smaller-60]
Eksempel:

[.smaller-60]
* desktop-app med javafx og fxml
* ikke noe behov for gjenbruk av kjernelogikk i andre prosjekter

== simpleexample

[.smaller]
[.left-60]
* eksempel på én-modul-prosjekt
** javafx+fxml-app
** standard mapper for java
** gradle-filer

[.right]
image::../images/simpleexample-structure.png[width=300]

== simpleexample forts.

[.smaller]
* 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

[source]
----
plugins {
	id 'application'
	id 'org.openjfx.javafxplugin' version '0.0.8'
}
----

== Modulært prosjektoppsett

[.smaller-60]
_Flermodul_-prosjekter har delmoduler i undermapper

[.smaller-60]
* *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

[.smaller-60]
Eksempel:

[.smaller-60]
* klient-tjener-app
* (noe) felles kjernelogikk i klient og tjener
* kan ha flere klienter, f.eks. desktop og mobil (og web)

== Modularitet

[.smaller-60]
* 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

[.smaller]
[.left-60]
* eksempel på fler-modul-prosjekt
** core - kjernelogikk
** fx - javafx+fxml-app
** jaxrs - REST API
** jersey - web-server-app
** webreact - web-klient
Hallvard Trætteberg's avatar
Hallvard Trætteberg committed

== Avhengigheter

[.smaller-60]
[.left-60]
* 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! 

[.right]
image::../images/maven-central.png[width=300, link="https://mvnrepository.com"]

== Avhengigheter forts.

[.smaller-60]
* 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

[.smaller-60]
[.left-60]
* *New > Project... > Gradle Project*: opprette nytt java-prosjekt, ferdig oppsatt med fornuftig gradle-konfigurasjon
Hallvard Trætteberg's avatar
Hallvard Trætteberg committed
* *Import... > Existing Gradle Project*
* *> Gradle > Refresh Gradle Project*: oppdaterer Eclipse sin prosjektkonfigurasjon fra gradle-konfigurasjonen
Hallvard Trætteberg's avatar
Hallvard Trætteberg committed
** kildekodemapper
** avhengigheter
* paneler
** *Gradle Tasks*
** *Gradle Executions*

[.right]
image::../images/gradle-views.png[width=300]

== 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
include::{includedir}footer.adoc[]