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
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.
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:
Eine Liste mit allen verwalteten Projekten:
editierbar das Projekt, inklusive Projektleiterselektion mit Ajax-Control selectize.js
die geplante Projektlaufzeit (je Task und Assignment) als Gantt-Diagramm:
Die eigentliche Stundenerfassung für "normale" Nutzer:
Diverse Client Seitige (JavaScript/jquery) Funktionalitäten:
Eingaben lassen sich als Excel Report herunterladen (Reporting Tool Jasper Reports ist integriert):
Die Zeiteingaben führen "on the fly" zur graphischen Rückmeldung als Balkendiagramm (chart.js):
Die Benutzereingabe nutzt ein "autocomplete" ajax Control von jquery-ui:
Login Seite (integriert mit spring-security):
5. Entwicklungsumgebung
Einblicke in die Entwicklung von totask2:
eclipse / springIDE
Für die REST Datenquellen stellt swagger-ui einen automatische generierten Client zur Verfügung:
PlantUML ermgöglicht das einfache Einbetten von UML Diagrammen in die javadoc-Dokumentation:
Den Inhalt der Datenbank H2 kann man mit der mitgelieferten Console einsehen und ändern:
Tests mit junit 4:
experimentelle Selenium Tests:
git Repository und Versionierung:
6. QA
diverse qa tools (findBugs, checkstyle, PMD) prüfen den Code statisch, hier als Beispiel checkstyle:
das Ganze dann auch auswertbar mit Trends in einem SonarQube Server aufbereitet.
7. Deployment
7.1. Lokal
Neben der einfachsten Ausführung als Stand Alone App hier ein Deployment im RedHat WildFly Application Server:
7.2. Cloud
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).
8. Monitoring
Option zur Logauswertung (direct in der cloud).
lokale Alternative dazu wäre die Kombi aus logstash, elasticsearch und kibana.
Monitoring der lokalen Wildfly Instanz mit newrelic.
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)