totask: eine rudimentäre Projektzeiterfassung

1. die Motivation

totask2 ist eine "Ausrede" um einen wieder einmal willkürlich ausgewählten Software-Stack auszuprobieren.

2. Beschreibung

totask2 erlaubt eine Erfassung von (Arbeits-) Zeiten zu Projekttasks. Daher verwaltet das Programm Entitäten wie Projekt, Task und Arbeitszeit (WorkEntry) und Taskzuordnung zu Usern (TaskAssignment).

2.1. Spec

  • Ein Administrator (User) darf Projekte anlegen

  • ein Projekt hat einen oder mehrere Projektleiter (User)

  • Projektleiter könnne Tasks zu Ihren Projekten erfassen

  • jeder Task kann Usern (für einem Zeitraum) zugeordnet werden, in diesem dann Arbeiten zum Task zulässig sind (TaskAssignment)

  • jeder User kann Zeiten wochenweise für Tasks erfassen die ihm im Zeitraum zugeordnet sind

  • die Erfassung erfolgt je Tag und Task in Stunden(bruchteilen) (WorkEntry)

  • die Erfassung kann für die aktuelle und zurückliegende Wochen erfolgen

  • seine erfassten Zeiten kann der User als Excel herunterladen

screenshot.useCases
Figure 1. unterstützte Usecases

Hint: obiges Bild nur sichtbar bei lokalem build, nicht auf github.

3. Der Software Stack

springmvc als serverseitiges Java Web Framework.

SpringMVC Web Anwendungen werden natürlich in Java programmiert. Im vorliegenden Fall bereits mit Java 8 da ich dabei Closures nutzen wollte. Als Templating Engine für HTML wird dabei thymeleaf verwendet.

Logging erfolgt mit logback/slf4j, optional in die cloud auf loggly.com,

Unit Tests mit junit. Der REST Teil wird über wagger zur Verfügung gestellt, alternativ erfolgen Tests der REST Aufrufe über Postman

Client Seitig benutze ich bootstrap für css, bootstrapvalidator für einige Client seitige Prüfungen, jquery als JavaScript Library, dazu datatables als Datagrid. Ein Chart wird mit Charts.js clientseitig erstellt, ein Gantt Chart mit ganttView. Für die kompfortable Auswahl von Usern benutze ich das autocomplete plugin, um Suchvorschläge on the fly per REST/json vom Server zu holen. Für die UI Zuordnung Projektleiter zu Projekt kommt das Control selectize.js zum Einsatz.

Für Reporting wird JasperReports genutzt um Excel und PDF Auswertungen zu generieren.

Versionierung ist mit git gelöst. Das Repository ist auf github gehostet.

Datenhaltung wird mit der integrierten h2 in-Memory Datenbank gelöst, zumindest während der Entwicklung. Eine separate qa Datenbank wird mit dem QA Profil angesprochen, deren Tabellenstruktur (DDLs) wird mit "Migrations" durch flyway gepflegt. Einige Tabellen/Daten sind historisiert, dies wird mit hibernate-envers realisiert.

Dieser Artikel und weitere Dokumentation ist mit asciidoc Markup erstellt. Einige Diagramme sind mit plantuml erstellt und generiert. Ein nettes Gimmick: github kann asciidoc Documente "on the fly" direkt aus dem Repository im Browser als Html rendern. Live zu sehen unter https://github.com/man-at-home/totask2/blob/master/src/docs/totask2.article.asciidoc

Für das Build Management nutze ich gradle, mit einigen Plugins wie asciidoctor. Diverse Build-Server laufen in der Cloud, auf openshift jenkins, dazu travis-ci, codeship, circleci sowie shippable

Qualitätsanalyse erfolgt mit diversen Tools die im Build oder in der IDE eingebunden sind: CheckStyle, FindBugs, PMD, jDepend, jacoco. Zudem als Analysewerkzeug SonarQube. Zusätzlich triggert der travis-ci Server eine cloud-basierte Codeprüfung auf an coverity.com Auf veraltete Libraries prüft versioneye.

Experimentell ist selenium als Web Test Tool.

Als "echter" Appserver für das Deployment fungiert der WildFly Application Server von redhat - sowohl lokal installiert als auch in der cloud.

Metriken sind mit boot-actuator und mit dropwizard metrics bereitgestellt, derzeit als REST Endpoint. Optionales weiteres Performance Monitoring erfolgt mit newrelic. Dazu ist der lokale wildfly Server instrumentiert und schickt Informationen an newrelic.

Hosting der Anwendung in der cloud erfolgt mit openShift in einer WildFly Cardridge, zudem automatisiert (und immer Aktualisiert über den codeship ci-server) auf einen dyno in der heroku cloud.

Das Monitoring der bei heroku laufenden Anwendung erfolgt mit monitor.us, die neben Web Charts und Alert E-Mails auch android und iphone apps herfür bereitstellen.

Ebenfalls zur Überwachung sowie zur Erfassung und Auswertung oben beschriebenen Metriken erfolgt mit circonus.com[Circonus]. Aktiviert sind zudem AlertSite (mit der Besonderheit der Ausführung von soapUI Tests gegen totask2), ruxit, anturis und pingdom, die jeweils die Verfügbarkeit der totask2 Webseiten von verschiedenen Standorten weltweit prüfen als weitere Server Überwachung.

Weitere Auswertung können mit dem Analytic Provider keen.io erfolgen. Dazu ist ein entsprechender Service in totask2 implementiert, der Kennzahlen an keen.io schicken kann.

Als Kommunikation (mit mir selber: "ha ha") generieren Codeänderungen (github) und Blob-Einträge (wordpress) twitter tweets auf @totask2tweeter, diese werden auch weitergeleitet an einen slack Chat Account, ebenso wie weitere Informationen (z.B. von den Build Servern).

3.1. Anforderungen zum Entwickeln

  • java8 jdk and runtime

  • git versioning

  • gradle build system

4. Ergebnis

hier kurze Blicke auf die laufende Anwendung:

screenshot1
Figure 2. Startseite

Eine Liste mit allen verwalteten Projekten:

screenshot2
Figure 3. Projektübersicht

editierbar das Projekt, inklusive Projektleiterselektion mit Ajax-Control selectize.js

screenshot3
Figure 4. Projektbearbeitung

die geplante Projektlaufzeit (je Task und Assignment) als Gantt-Diagramm:

screenshot3
Figure 5. Projektanzeige als Gantt Chart

Die eigentliche Stundenerfassung für "normale" Nutzer:

screenshot4
Figure 6. Zeiterfassung

Diverse Client Seitige (JavaScript/jquery) Funktionalitäten:

screenshot5
Figure 7. Zeiterfassung Client Funktionen

Eingaben lassen sich als Excel Report herunterladen (Reporting Tool Jasper Reports ist integriert):

screenshot6
Figure 8. Zeiterfassung Reporting

Die Zeiteingaben führen "on the fly" zur graphischen Rückmeldung als Balkendiagramm (chart.js):

screenshot7
Figure 9. Zeiterfassung Chart

Die Benutzereingabe nutzt ein "autocomplete" ajax Control von jquery-ui:

screenshot8
Figure 10. Zeiterfassung Ajax Autocompletion

Login Seite (integriert mit spring-security):

screenshot9
Figure 11. login

5. Entwicklungsumgebung

Einblicke in die Entwicklung von totask2:

screenshot_DEV_0
Figure 12. desktop developing totask2

eclipse / springIDE

screenshot_DEV_0b
Figure 13. desktop ide

Für die REST Datenquellen stellt swagger-ui einen automatische generierten Client zur Verfügung:

screenshot_DEV_swagger_0c
Figure 14. wagger-ui

PlantUML ermgöglicht das einfache Einbetten von UML Diagrammen in die javadoc-Dokumentation:

screenshot_DEV_1
Figure 15. javadoc plantuml Dokumentation

Den Inhalt der Datenbank H2 kann man mit der mitgelieferten Console einsehen und ändern:

screenshot_DEV_2
Figure 16. h2console DB Abfragetool

Tests mit junit 4:

screenshot_DEV_0
Figure 17. junit

experimentelle Selenium Tests:

screenshot_DEV_20
Figure 18. selenium ide

git Repository und Versionierung:

screenshot_DEV_20
Figure 19. git SourceTree UI

6. QA

diverse qa tools (findBugs, checkstyle, PMD) prüfen den Code statisch, hier als Beispiel checkstyle:

screenshot_QA_checkstyle
Figure 20. checkstyle eclipse plugin

das Ganze dann auch auswertbar mit Trends in einem SonarQube Server aufbereitet.

screenshot_QA_sonar
Figure 21. sonar dashboard
screenshot_QA_sonarIDE
Figure 22. sonar ide integration
screenshot_QA_sonarCoverate
Figure 23. sonar jacobo test coverage
screenshot_QA_coverity
Figure 24. coverity static analyse in der cloud

7. Deployment

7.1. Lokal

Neben der einfachsten Ausführung als Stand Alone App hier ein Deployment im RedHat WildFly Application Server:

screenshot_EE
Figure 25. lokale Installation im wildfly Container

7.2. Cloud

deployment_CLOUD_1
Figure 26. deploymentpipeline

Automatisierte Builds mit dem build Server jenkins finden in der cloud auf einer openShift Applikation (== Runtime Umgebung in der cloud von red hat) statt. Der Build-Server holt sich den totask2 Source im master-Branch von github und generiert Dokumentation (alternativ: compile).

screenshot_CLOUD_1
Figure 27. jenkins on openshift
screenshot_CLOUD_2
Figure 28. totask2 running on openshift log tail
screenshot_CLOUD_HEROKU
Figure 29. totask2 ci-server codeship catches changes on github, builds totask2, deploying result afterwards on heroku dyno.

8. Monitoring

Option zur Logauswertung (direct in der cloud).

screenshot_loggly
Figure 30. totask2 logging into the cloud

lokale Alternative dazu wäre die Kombi aus logstash, elasticsearch und kibana.

Monitoring der lokalen Wildfly Instanz mit newrelic.

screenshot_newrelic
Figure 31. totask2 app monitoring into the cloud
screenshot_monitor-us
Figure 32. totask2 app monitoring into the cloud

9. weitere Details

10. Erfahrungen

Details hoffentlich bald im blog https://totask2.wordpress.com/

10.1. positiv

  • kein Xml, einfach zu durchschauen,

  • lokale Stand-Alone Entwicklung: nur git und Java notwendig für den Start, der Rest lädt automagisch nach!

  • entwicklerfreundliche Bibliotheken

  • springMVC unterstützt den Test der Controller gut

  • Datenbank und Datenmodell (mit jpa) schlank

  • Komplett Repository, Tracker, Homepage und Test-Server in der (free!) cloud (github und openShift)

10.2. negativ

Wo hakt es (noch?)

  • check von html inline JavaScipt mit jshint aufgegeben, gradle Plugin kennt --export option nicht

  • gradle Tests laufen derzeit nicht auf dem Jenkins Cloud Server (Inkompatibilität gradle 2 und openShift?)

  • Deployment auf openShift erfolgt mit sftp, der "empfohlene Weg" über git scheitert bei mir an der notwendigen zusätzlichen gradle Installation (zu wenig disk quota im free plan von openShift hierfür)

  • bekomme asciidoctor-diagram im gradle Build nicht ans laufen, daher mit Umweg (umkopieren der generierten Bilder aus der JavaDoc Erzeugung)