Software Entwicklung

Wir arbeiten grundsätzlich agil, orientiert an SCRUM.

Alle identifizierten Aufgaben werden als Issues im GitLab abgelegt. Sie definieren das Backlog.
Im Rahmen eines Sprints wandern die entsprechend priorisierten Aufgaben in den Sprint Meilenstein.

Ein Sprint beginnt mit einem Sprint Planning Meeting. Ein Sprint hat eine definierte Dauer (momentan etwa einen Monat), typisch wären eher drei Wochen.
Im Sprint Planning Meeting werden gemeinsam die Aufgaben aus dem Backlog ausgewählt, die am wichtigsten sind, und die im Gesamtumfang gut in diesem Sprint abgearbeitet werden können.
Die Aufgaben in einem Sprint werden typischerweise nicht geändert. Ausnahme sind allerdings ggf. die Behebung von Softwarefehlern oder kurzfristig sehr dringenden Aufgaben.
Am Burn-Down-Chart kann man nachvollziehen, ob der Sprint tatsächlich in der entsprechenden Zeit sein Ziel erreicht. Man sollte sich deshalb immer möglichst auf eine Aufgabe konzentrieren und diese abschliessen.
Am Ende eine Sprints gibt es ein Sprint Review Meeting bzw. Sprint Retrospection Meeting

Definition of Done (DoD) für Issues

Idealerweise sollten alle Issues als Branches (nach der Namenskonvention von GitLab und https://nvie.com/posts/a-successful-git-branching-model/) abgearbeitet werden. Ausnahmen: "Triviale" Änderungen: Verbesserungen Testcoverage, Überschaubare Behebung von Code Smells, sehr lokale Änderungen ohne erwartbare Auswirkungen auf andere Entwickler.
Vier Augenprinzip (ein anderer Entwickler/Tester/Nutzer) akkzeptiert die Lösung. Bitte nicht selbst einen Issue schliessen, sondern typsicherweise demjenigen zurückgeben, der den Issue angelegt hat.
- Nach erfolgreichem "Review" kann der Tester oder der Entwickler den Branch mergen. Anschliessend sollte der Branch gelöscht werden.
keine bekannten offenen Probleme (Funktionale Verbesserungen die im Laufe der Entwicklung/Tests identifiziert wurden ggf. ins Backlog)
Dokumentation: kritische Konzepte: Interfaces, Komplexe Datenstrukturen müssen dokumentiert sein.
- Zielsetzung der Dokumentation:
  - Ein neuer Entwickler, der sich in JHipster, ElasticSearch, ... allgemein eingearbeitet hat, soll sich mit der CodeAbility-Dokumentation im Projekt zurechtfinden. D.h. Sonderlocken, komplexe Umsetzungen, zusätzliche Architekturprinzipien sollten dokumentiert werden.
Saubere Code Basis: Aufräumen von Zwischencode
Erfolgreiche Unit Tests: hinreichende Testüberdeckung für neuen Code
Automatisierte Continuous Integration

Entwicklung und Tests finden ausschliesslich in der Entwicklungsumgebung (bzw. auf lokalen Umgebungen) statt
Änderungen an Produktivumgebungen nur, wenn diese vorher in der Entwicklungsumgebung auf ihre Auswirkungen sauber geprüft worden sind.
Minimale Unterbrechungen des produktiven Betriebs. Soweit möglich/sinnvoll angekündigt (z.B. ArTEMiS: Systemmitteilungen, Sharing Plattform: Systemmitteilung über GitLab Messages). Idealerweise außerhalb der Kernzeiten.
Nutzerfreundliche Upgrade Strategien: Beim Update von Formaten (z.B. MetaDaten) sollte eine automatische Migration weitgehend möglich sein.
Das Aufsetzen der Produktivumgebung muss sauber dokumentiert sein. Theoretisch muss anhand der Dokumentation jeder Entwickler in der Lage sein, eine Entwicklungs-/Produktivumgebung aufzusetzen.

Starke Passwörter für alle Accounts! Keine Wiederverwendung von Passwörtern!
- Password management im Team mit KeePass)
Möglichst keine Gruppenuser: adminMock, studentMock, ... !
Dokumentation der Backup-Strategie
- TODO: Festlegen der Anforderung: Maximale Ausfallzeiten, Maximale Wiederherstellungszeit, Maximale Datenverluste