Der Lobid-Entwicklungsprozess

Fabian Steeg, Linked Open Data, hbz NRW

hbz, Köln, 2016-05-12

Diese Präsentation:
https://hbz.github.io/slides/lobid-entwicklungsprozess

Lobid

Team: 1 Bibliothekar, 2-5 Entwickler; Aufgaben:

Linked-Data-Dienst des hbz: Web-APIs für Titel- und Normdaten

Nordrhein-Westfälische Bibliographie auf Basis der Lobid-APIs

Team z.T. auch in OER World Map involviert, ähnlicher Prozess

GitHub

Wir entwickeln Open-Source-Software auf GitHub

Nicht nur Ergebnisse veröffentlichen, sondern Prozess dort

d.h. Planen, Issue-Tracking, Code, Testen, Diskussion

GitHub = Eine Art Social Network für Softwareentwicklung

 
 
 

GitHub Issues

GitHub hat einen integrierten Issue-Tracker

Primäres Organisationsmittel: beliebige Labels mit Farben

Integriert: Links zu Code, Commits, Usern, Markdown

 
 
 

 
 
 

Board

GitHub-Issues immer mit 1 GitHub-Repo assoziiert

Für einheitlichen Blick auf alle vom Team bearbeiteten Issues: Kanban-Board zur Visualisierung des Workflows

Waffle: Kanban-Board mit GitHub-Integration:
jedes Issue entspricht 1 Karte, Spalten entsprechen Labels

 
 
 

Prozess

Generell: Links → Rechts

Backlog Ready Working Review Deploy Done
Neue Issues ohne Label Bereit, d.h. Anforderungen und Abhängigkeiten sind klar In Bearbeitung In Überprüfung Bereit für Produktion In Produktion

Priorisierte Karten nach oben in der Spalte; Bugs generell priorisiert

Tägliche Treffen

Priorisierung unter anderem in täglichen kurzen Besprechungen
(vor dem Mittagessen, 12 Uhr, 5-15 Minuten)

Jeder: 1) Was zuletzt 2) Was aktuell, ev. Probleme 3) Als nächstes

Wenn alle im hbz sind: im Stehen; sonst Skype oder Google Hangout

Planungstreffen

Nach Bedarf, alle paar Monate, längeres Planungstreffen (1-2 Std.)

Gemeinsam am Board Tickets durchgehen und priorisieren

GitHub Flow

GitHub basiert auf dem Versionskontrollsystem Git

Git macht Branching und Merging einfach

Neue Features oder Bugfixes werden in eigenem Branch umgesetzt

GitHub Flow = einfacher, Branch-basierter Workflow, den GitHub auch selbst verwendet, um GitHub zu entwickeln

 
 
 

Working: Board

Bei Beginn der Arbeit an einem Issue: in 'Working' ziehen

Ziel: Jedes Team-Mitglied nur 1 Karte in 'Working', so Visualisierung der tatsächlichen Situation

Nur eigene Karten in und aus 'Working' ziehen, nur selbst reassignen (zur Vermeidung von Doppelarbeiten etc.)

Working: Code

Vor Beginn: neuen Branch vom Master-Branch abzweigen.

In Commit-Nachrichten eine Referenz zum korrespondierenden Issue einfügen, dadurch erscheinen automatisch Referenzen zu den Committs im Issue.

Wenn Issue abgearbeitet ist: Pull-Request aufmachen, in der Beschreibung auch hier Referenz zum Issue, dadurch in Waffle gruppiert. Der Entwickler weist sich den Pull-Request zunächst selbst zu und kann das Ergebnis des automatischen Builds (mit Travis CI) direkt im Pull-Request verfolgen.

 
 
 

 
 
 

Functional Review

Entwickler stellt neue oder reparierte Funktionalität auf Staging-System bereit, beschreibt im Issue, wie getestet werden kann (z.B. Links auf die betreffenden Seiten im Staging-System) und weist das Issue einem Team-Mitglied zur Begutachtung zu (Functional Review).

Functional Reviewer testet, gibt Feedback (bei Bedarf aktualisiert der Entwickler den Pull-Request und die Version auf Staging mehrfach), und schließt die Begutachtung mit einem "+1" Kommentar ab, weist das Issue dem Entwickler zu, und verschiebt es in 'Deploy'.

Code Review

Nach Abschluss des Functional Reviews weist der Entwickler den zum Issue gehörigen Pull-Request einem anderen Entwickler zur Begutachtung zu (Code Review).

Der Reviewer inspiziert je nach Fall nur den Diff im Pull-Request oder testet den Branch lokal. Die Ausführung des Builds und der Tests erfolgt automatisch im Pull Request (mit Travis CI).

Auch hier wird die Begutachtung mit einem "+1" Kommentar abgeschlossen, der Reviewer weist das Issue wieder dem Entwickler zu, und verschiebt es in 'Deploy'.

Deploy

Nach dem Review schaltet der Entwickler seinen Code produktiv und merged den Code in den Master-Branch.

Dazu wird auf dem Produktivserver der Feature/Bugfix/Topic-Branch lokal in den Master-Branch gemerged und das Resultat getestet. Bei Erfolg wird vom Produktivserver in den Master auf GitHub gepushed und der Feature/Bugfix/Topic-Branch auf GitHub gelöscht. Der Pull-Request wird dabei automatisch geschlossen.

So ist der Master-Branch immer der aktuelle Produktivstand.

Done

In 'Done' befinden sich die zuletzt geschlossenen Issues und Pull-Requests. Issues können über die GitHub-Oberfläche geschlossen werden oder in 'Done' geschoben werden.

Wir schließen Issues über eine Referenz im Merge-Commit, in dem wir auch auf die produktive Änderung verweisen, z.B.
Resolves #140; See: http://beta.lobid.org/organisations/search?q=name:Stadtbibliothek+Berlin

Infos & Links

Mehr Informationen und Links, u.a. zu GitHub-Doku, gibt es unter:

https://hbz.github.io/#dev-process