Beim Schreiben von Python Software kann man auf eine Vielzahl von Tools zurückgreifen, die hilfreich das Projekt begleiten.
Es fängt bei der Entwicklungsumgebung an, einer Testing Umgebung, und endet bei der Dokumentation und dem Deploymentprozess.

 

Entwicklungsumgebung

Das MSS Autoren Team wendet pycharm in der Community Edition an. Die Vielzahl der Integrativen Möglichkeiten der Entwicklungsumgebung hilft uns bereits während dem Schreiben von Quellcode kleine Fehler zu entdecken. Unser Test Environment wird vollständig unterstützt und die Entwicklungsumgebung ermöglicht gleichzeitig den Server und den Client zu starten bzw.  diese zu debuggen.

 

Versionsverwaltung und Issue-Tracker

Für die Software MSS, die aktuell für die Planung von Forschungsflügen in Nepal und über großen Städten in Europa eingesetzt wird, verwenden wir eine Reihe offener Werkzeuge, damit wir diese Software an den Bedarf der User anpassen können. Der Autor Dr. Marc Rautenhaus, hat  ein Git Repository der Software mit einer Apache Version 2.0  Lizenz auf dem Software-Hoster Bitbucket angelegt. Als Repository bezeichnet man im Allgemeinem ein Verzeichnis mit einer Versionsverwaltung.

Git ermöglicht eine verteilte Versionsverwaltung aller Dateien unserer Software. Dadurch hat jeder Entwickler immer alle Dateien des Projektes mit deren gesamter History im Zugriff.
Praktisch daran ist, das wir eine Weiterentwicklung an der Software durchführen können auch wenn wir keinen Netzwerkzugriff haben. Nicht unüblich ist das Entwickler lange Zugfahrten nutzen, um das eine oder andere Issue zu bearbeiten.

Issues sind Reports von Usern, die sie uns auf dem Bitbucket Server schreiben, in der Regel Fehler Reports oder Erweiterungswünsche. Der Bitbucket Server gibt uns im Netz eine Management Möglichkeit, einen Workflow anzuwenden, der einen Codereview enthält, so dass nicht unbeachtet Änderungen in die Software einfließen. Zur Zeit hat das Hauptrepository zwei Maintainer, deren Aufgabe u.a. Änderungen an der Software durch andere einzupflegen.

Mitarbeiten am Quellcode

Möchte jemand an der Entwicklung des Quellcodes mitwirken, ist ein Account auf dem Bitbucket Server nötig. Dieser ist für öffentliche Repositories kostenlos. Das Arbeiten mit dem Bitbucket Server gestaltet sich so, dass  die Software MSS dann in den eigenen Account Workspace verzweigt wird. Man nennt diesen Prozess „forken“. Dort darf jeder alles mit der Software MSS machen, was ihm durch die Apache 2.0 Lizenz erlaubt ist. Üblicherweise „cloned“ man sich dann die MSS Software von seinem Account auf Bitbucket auf den eigenen Computer.  Das Wort „clonen“ lässt schon erahnen, dass es etwas anderes als „kopieren“ ist. Tatsächlich ist es so das Git einen Mechanismus kennt, beide Ablagen des Software Repositories identisch zu halten. D.h. Arbeiten die auf dem lokalem System abgeschlossen sind, können dann mit dem gesamten Entwicklungsprozess, der Geschichte derselben, anderen Entwicklern auf dem Bitbucket  Server im eigenem Workspace gezeigt werden. Erst wenn ein Entwickler sich entschließt, das seine Änderungen ins Haupt-Repository sollen, wählt er auf Bitbucket in seinem eigenem Repository die Option „Create Pull Request“. Dabei hat er noch die Möglichkeit einen weiteren Text dazu zuschreiben. Nun kann ein Maintainer entscheiden, ob er diesen „Pull Request“ annimmt und die Änderungen übernimmt.

Darstellung der Änderungswünsche

 

Eine andere Aufgabe der Maintainer ist, das Einsortieren der Issues in den Release Cycle. Z.B. machen wir nur Bugfixes in Minor Releases, z.B. 1.5.6. Im  nächsten Major Release 1.6.0 fließen größere Änderungen ein, die alle in dem Issue Tracker diskuttiert sind. Neben der Kommunikation über den Issue Tracker nutzen wir ein weiteres Werkzeug Slack. Wir haben für die Entwicklung von MSS ein Team und thematische Channels um uns schnell austauschen zu können.

Dokumentation mit Sphinx

Die Dokumentation der MSS Software erfolgt mit Hilfe der Software Sphinx. Im Repository selber liegt die gesamte Dokumentation, von jedem Entwickler anpassbar. Damit wir einen zentralen Platz für alle Benutzer der Software haben, verwenden wir readthedocs. Die Plattform readthedocs wird von der Python Community gepflegt und die Nutzung ist kostenlos. Auf mss.rtfd.io liegt die aktuelle Anleitung für den User zur Installation, für einen Entwickler um in den Entwicklungsprozess einzusteigen.

Dokumentation auf readthedocs

Neues Software Release

 

Steht ein neues Release der Software an, prüft der Maintainer alle Issues die für dieses im Issue-Tracker einsortiert sind. Diese müssen entweder geschlossen oder verschoben sein.  Abschliessend führt er noch einmal alle Unit Tests aus.

Python Unit Tests

Sollte ein Fehler auftreten muss dieser vor dem Release behoben sein.

Release bedeutet in unserem Fall, dass wir die Software MSS über einen Softwareverteilungs Server dem User als ein conda Paket bereitstellen. Für ein neues Release signiert der Maintainer mit seinem gpg Key einen Entwicklungsstand der Software in einem „tag“. Dieser „tag“ beinhaltet die Versionsnummer.

Das Software Paket MSS ist auf Linux, Windows und MacOSX in der Anaconda Python Distribution installierbar. Für die Anaconda Plattform gibt es verschiedene Softwarechannels die u.a. von Communities verwaltet werden. Das MSS Installations Rezept, gehört zur conda-forge github community. Die conda-forge Community pflegt eine Vielzahl von Installations-Rezepten für die Erstellung von Installations-Paketen. Verschiedene Continous Integration Services auf bereitgestellten Plattformen gewährleisten, das vor der Bereitstellung des Installationspakets der MSS Software deren Lauffähigkeit überprüft ist.

Sind alle Tests erfolgreich, steht wenig später das neue Release im conda-forge channel zur Verfügung.

Erfolgreicher Build und Funktionaler Test auf allen Plattformen.

 

No Comments

Be the first to start a conversation

Leave a Reply

  • (will not be published)