Agenda
Motivation
Problemstellung
Kategorien
Demo & Erfahrung
Kein „Best Practice“ | Rezept | Maven | CD
CI
Grady Booch (1994):
Integration aller Komponenten
Automatische Qualitätskontrolle
Unit TestingIntegrationstestsSystem TestAkzeptanz Test
CI
CD
Problemstellung
Use-Case: SPA mit Java Backend➔ M & V & C im Browser➔ Logik im Browser → Unittests ?
Integrationsproblem Neue Tools, Neue Compiler Neue Artefakte Neue Repositories
Problemkategorien
Buildsystem
Repository
Dependency
Struktur
Flexibilität, Version, OS
Format, Netz, Kontrolle
Versionsordnung, Tiefe
Versionsmaster, Propagierung
Separate Projektstruktur
Unabhängige Projekte– Einzeln Gebaut– Einzeln Versioniert– Problem: Versionspropagierung– Snapshot Problem
common:1
CRM:1.2
Produkt:2
NewUI:0.1
WAR:2015.Q1
Projektstruktur Integriert
Ein Zusammenhängendes Projekt– Zusammen gebaut– Eine Version– Problem: Große Projekte / Baulänge
SalesApp:15.Q1
CRM
Produkt
NewUI
WAR
JS Projekt Anatomie
JS– Ein JS & HTML– Assets
Generieren (CSS)
„Transpilieren“
Konkatenieren
Minifizieren
Java– Bytecode– Modell: JWE AR
Generieren (JAVA)
Compilieren
Paketieren
Typische Schritte
Tool Chain
JS
Node.js
Grunt, Gulp (uvm)
Bower / NPM
Ruby (compass)
Python (gyp)
Java (selenium)
GCC | Xcode
Java
JDK
Maven|Gradle|Ant
Integration – „kein Rezept“
Master-Tool JS | JAVA | make
Tool-Verteilung zentral | manuell
Paketsystem GEM | JAR | rpm
cabal | NIX | deb
Ziel-Archiv WAR | docker | ...
WAR-Archiv webapp | separat
Entwicklung Reload | Deploy
Integration Buildsystem
Task Basiert {ant} Definition von
Integrationstasks
Projektmodel {mvn} Erweiterung
Modells (Plugins)
FixiertAufruf BS
Task + Model Plugins
Integrationstasks
JS Artefakte mit JAVA
✔gradle-compass✔gradle-js-plugin✔gradle-css-plugin
Analog mvn (oos)
✗ Test (Jasmin)✗ E2E (protractor)✗ ng-annotate✗ Typescript / ES6✗ Ng-doc
...
Master der JS Artefakte
JAVA (gradle & co)➢ Paralleluniversum
Integriert
JS (grunt & co)➢ Duales System
Flexibel● Systemgrenze● Feature● Teams ...
Integration Grunt
Simple Call (Maven: ant-tasks)– Lifecycle → Task ?– Versionsmaster ?– Installation von Node?
Gradle Plugin– Installiert Node– Task: grunt → gradle– Versionsmaster via task
Repository
Funktionen: Caching, Kontrolle, Netz
Internes Repo Private Pakete (Keine Veröffentlichung)
Versionsstabilität (Internet „gelöscht“)
Paketformate
Maven & Ivy | NPM & Bower
NPM & Bower
NPM node.js Paket-Mgr.
Build tool
Dependencies: node_modules rekursiv
BowerZiel: Client-Entwicklung
Repository Format = Git Repo !
Dependencies Flach: bower_components
Internes Repo: JAVA
Maven & Ivy:Lokale & Remote
Artifactory OSS
Nexus OSS
Archiva
webjars.orgcompile 'org.webjars:jquery:2.1.3'
Internes Repo: JS
NPMNexus OSS (Ablage) ↔ sinopia (Cache)
URL via Scope
PublishConfig: {"registry":"…"}
BowerGit + Tag als Paketformat → ??
registry:"http://localhost:8000"
git clone # private-bower
Beispielprojekt Triton
common: Schnittstellen-Definition
client: JS Projekt: grunt, npm, fabs
service: Rest-Implementation
server: Integrationsprojekt
client & service = web-fragments
➔https://github.com/w11k/triton
Projekte
Öffentliche Verwaltung: • Migration von Ant nach Gradle
• Monolitischer Build• Modularisiert (Grunt Modul + Grunt Plugin)• Großteil nach AngularJS migriert
2 x DAX-Konzern:• Maven Build, Integration mit ant-run,
Release-Skript• Grunt (Fabs) Integration mit Gradle
Fazit + IMHO
Integration der JS Toolchain– Vermeidung der Parallelwelt
Stabile Versionen (Gradle, Node)– Versionsordnung & Versionsmaster
Build unabhängig vom OS– Less statt SASS
Lokales Repo ermöglichen– Bower vermeiden (aktuell)– Paketformat (JAR vs. TAR) → Nutzer
Top Related