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. Entwickler/in 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/in 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/in testet, gibt Feedback (bei Bedarf aktualisiert Entwickler/in Pull-Request und die Version auf Staging mehrfach), und schließt die Begutachtung mit einem "+1" Kommentar ab, weist das Issue Entwickler/in zu, und verschiebt es in 'Deploy'.
Code Review
Nach Abschluss des Functional Reviews weist Entwickler/in den zum Issue gehörigen Pull-Request 2. Entwickler/in zur Begutachtung zu (Code Review).
Reviewer/in 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, Reviewer/in weist das Issue wieder Entwickler/in zu, und verschiebt es in 'Deploy'.
Deploy
Nach dem Review schaltet Entwickler/in 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: