Add-ons für GitHub Repositories im Überblick

Eine Schippe drauflegen mit GitHub Add-ons
Keine Kommentare

Der webbasierte Codehoster GitHub setzt auf der Versionsverwaltung Git auf und verwaltet kostenlos öffentlich einsehbare Softwareprojekte. Mittlerweile gibt es viele Onlinedienste, die mit dortigen Repositories verknüpft werden können. Dieser Artikel stellt einige wichtige Vertreter aus den Bereichen Continuous Integration, statische Codeüberprüfung und Securityscanning vor.

GitHub ist eine Erfolgsgeschichte, und der maßgeblich auf dem Versionskontrollsystem Git basierende Codehoster braucht bei Entwicklern mittlerweile keine große Vorstellung mehr. Die Onlineplattform ist äußerst beliebt und hat die anderen größeren Mitbewerber wie Bitbucket oder GitLab in der Anzahl der gehosteten Softwareprojekte hinter sich gelassen. Die meisten Repositories gehören einzelnen Entwicklern, aber gerade prominente große Projekte wie der Linux-Kernel, der offizielle Python-Interpreter, Puppet, Docker, Bitcoin, jQuery und PHP haben hier in einer Überzahl ihre Heimstätte gefunden. GitHub ist für quelloffene und frei lizensierte Software kostenlos und fungiert mit vielfältigen und nützlichen Funktionen für die kollaborative Softwareentwicklung praktisch auch als soziales Netzwerk. Außerdem sucht mancher Headhunter gerade auf den Profilseiten dieses „Facebooks für Programmierer“ nach geeignetem Personal.

Parallel dazu hat sich geradezu ein ganzes Biotop von Onlinediensten entwickelt, die mit GitHub Repositories verknüpfbar sind und mit denen sich die Entwicklung von dort aufbewahrtem Code unterstützen lässt. Mittlerweile ist darum ein vielfältiges Angebot von Hilfsmitteln verfügbar. Dieser Artikel stellt einige wichtige GitHub-Add-ons aus den Bereichen Continuous Integration und Codeüberprüfung allgemein und mit einem Fokus auf Programmsicherheit vor. Als Einführung in das Thema stehen in diesem Artikel Services im Vordergrund, die – wie GitHub auch – ein kostenloses Angebot für öffentlich zugänglichen Code in dortigen Repositories haben. Die Beispiele beziehen sich zwar auf Python-Code, aber auch die Entwickler anderer Programmiersprachen werden die Eckpunkte auf ihr eigenes Projekt übertragen können.

Travis CI

Travis CI ist eine webbasierte Plattform für Continuous Integration. Der Anbieter unterstützt die Open-Source-Gemeinschaft mit einem kostenlosen Service; für kommerzielle bzw. proprietäre Projekte gibt es ein erweitertes Angebot. Mit Travis können Softwareprojekte probeweise gebaut und getestet werden, wenn neuer Code bzw. Änderungen im GitHub Repository eingespielt werden. Die Projektentwickler selbst, Downstream-Developer, aber auch Endbenutzer, die sich die aktuellsten Fassungen herunterladen anstatt auf neue Veröffentlichungen warten zu wollen, können dann sofort sehen, ob der aktuelle Commit sich überhaupt bauen bzw. kompilieren lässt, oder ob sich Fehler in die Codebasis eingeschlichen haben, die Probleme bereiten.

Travis fügt sich dabei harmonisch in GitHub ein. So werden zum Beispiel auch automatisch alle wartenden Pull Requests, also Codevorschläge von assoziierten Entwicklern, erst einmal zur Probe gebaut (Abb. 1). Funktionen wie diese unterstützen die kollaborative Softwareentwicklung auf GitHub, denn das erspart den Projektbesitzern die Mühe, jeden kleinen Patch vor der Annahme zunächst einmal herunterzuladen und lokal auszuprobieren, ob er überhaupt integrierbar ist. Ein Bauergebnis kann per E-Mail versendet oder auch als JSON-Report an beliebige URLs geschickt werden, etwa um weitere Prozesse anzustoßen. Auf der umfangreichen Liste der von Travis CI unterstützten Programmiersprachen finden sich unter anderem C/C++, Golang, Java, JavaScript, PHP und Python. Travis berücksichtigt aber auch die statistischen und wissenschaftlichen Sprachen R und Julia und kann mit vielen relativ neuen Programmiersprachen wie zum Beispiel Rust umgehen. Android ist als eigene Bauumgebung verfügbar, Windows hingegen nicht.

Abb. 1: Ein Pull Request wird mit Travis und Appveyor getestet

Abb. 1: Ein Pull Request wird mit Travis und Appveyor getestet

Travis kann unkompliziert an bestehende GitHub Repositories angedockt werden. Dafür ist noch nicht einmal ein eigener Travis-Benutzeraccount notwendig. Von der Hauptseite des CI-Diensts landet man per „Sign in with GitHub“ direkt auf einer GitHub-Seite für die Freischaltung von Travis CI als externe Applikationen, wenn man in einem anderen Fenster bereits dort eingeloggt ist. Danach können auf der Benutzerseite die gewünschten Repositories vom Anwender für die Continuous Integration freigeschaltet werden. Das dauert nicht einmal eine Minute und ist online erst einmal alles, was man zum Einstieg durchführen muss.

Damit Travis weiß, wie es mit einem Softwareprojekt konkret verfahren soll, benötigt der Service darüber hinaus auch noch eine versteckte Konfigurationsdatei .travis.yml im Wurzelverzeichnis des Repositories, die dem eigenen Projekt einfach hinzugefügt wird. In dieser im YAML-Markup geschrieben Steuerdatei gibt der Anwender zunächst die verwendete Sprache an. Bei einem Python-Projekt steht hier zum Beispiel language: python. Dann können verschiedene Python-Laufzeitumgebungen festgelegt werden, in denen das Projekt nach einem Commit getestet werden soll (Listing 1) – Travis arbeitet das übrigens parallel ab. Die Liste kann den Interpreterversionen entsprechen, für die eine Applikation oder eine Bibliothek entwickelt wird; die Auswahl für Travis kann bei Bedarf auch eingeschränkt oder erweitert werden.

Wenn in der Konfiguration nichts besonderes eingestellt ist, zieht Travis für einen Testbau automatisch die in requirements.txt angegebenen Abhängigkeiten aus dem Python Package Index, ein install:-Feld kann der Anwender aber mitgeben, um dieses Standardverhalten bei Bedarf zu verändern, zum Beispiel, wenn diese Datei gar nicht vorhanden ist. Dabei sind jeweils Shell-Befehle wie auf einem Linux-System anzugeben, denn Travis verrichtet seine Arbeit in einem Ubuntu-Container – per Voreinstellung zum Zeitpunkt des Verfassens dieses Artikels auf Ubuntu 12.04 LTS, wobei 14.04 optional verfügbar ist. Es kann hier also pip install verwendet werden, um die in einer Ubuntu-Basisinstallation vom Projekt noch benötigten Python-Pakete in die jeweilige Umgebung zu bekommen.

Anders als zum Beispiel ein C/C++-Projekt zur Probe zu bauen, ist es wenig sinnvoll, bei einem reinen Python-Projekt ohne Maschinencode-Extensions python setup.py build auszulösen, und auch der Befehl python setup.py install kopiert lediglich die Skriptdateien herum. Falls hierbei Fehler auftreten, die zu einem Abbruch führen, gibt es zwar irgendein Problem mit dem Set-up-Skript, darüber hinaus lässt sich aber nicht viel daraus ablesen, wenn dieser Vorgang ohne Fehler abschließt. Viel ergiebiger ist es, von Travis aus die (idealerweise vorhandene) Testsuite eines Python-Projekts durchlaufen zu lassen, um festzustellen, ob die Software mit dem aktuellen Commit bzw. dem Pull-Request tatsächlich wie beabsichtigt funktioniert. Die Tests kann der Anwender einfach mit dem Feld script: in der Konfigurationsdatei starten. Hier werden etwa nosetests oder pytest wieder wie auf der Kommandozeile in den von Travis zur Verfügung gestellten Umgebungen verwendet. Der Service stellt übrigens Nose, Py.test und das häufig verwendete Hilfsmittel Mock automatisch für jede Python-Umgebung bereit; diese Testprogramme müssen also nicht noch extra angegeben werden, um sie zu installieren.

language: python
python:
  - "2.7"
  - "3.4"
  - "3.5"
install:
  - pip install foo
  - pip install bar
script:
  - nosetests --with-doctest --verbose tests/
notifications:
  email:
    - "max.mustermann@emailadresse.de"

Nachdem eine derartige Konfigurationsdatei einem Projekt hinzugefügt und in das GitHub Repo hochgeladen worden ist, laufen die Tests bei Travis CI unverzüglich an. Auf der dem Projekt bzw. dem Repository zugehörigen Seite finden sich dann die aktuellen Ergebnisse (Abb. 2), und auch die detaillierten Protokolle aus jeder Umgebung sind dort verfügbar. Für die README-Datei des eigenen Projekts (die günstigerweise in Markdown oder REST geschrieben ist) stellt Travis darüber hinaus kleine Images für HTML-Buttons zur Verfügung, mit denen der aktuelle Status (passing oder failing) auch direkt auf der GitHub-Seite angezeigt werden kann (Abb. 3).

Abb. 2: Die aktuellen Ergebnisse eines Travis-Durchlaufs

Abb. 2: Die aktuellen Ergebnisse eines Travis-Durchlaufs

Abb 3: Die Badges von Travis CI und Codacy

Abb 3: Die Badges von Travis CI und Codacy

Weitere CI-Dienste

Travis CI hat einige Mitbewerber, die nach demselben Prinzip arbeiten. Circle CI zum Beispiel ist eine vergleichbare Continuous-Integration-Plattform, die sich an GitHub und andere Codehoster wie Bitbucket anbinden lässt. Die dazugehörige Konfigurationsdatei in Repositories heißt circle.yml. AppVeyor funktioniert genauso wie Travis CI, bietet allerdings Integration mit Microsoft Windows in virtuellen Maschinen an. Wird dieser Service benutzt, findet sich in Repositories eine Konfigurationsdatei mit Namen appveyor.yml. Außerdem ist es ohne Weiteres möglich, bei einem Projekt auf GitHub mehrere CI-Dienste nebeneinander einzusetzen (Abb. 1).

Codacy

Eine andere Methode, um Missstände in Software aufzuspüren, ist die statische Codeüberprüfung. Dafür werden spezielle Programme eingesetzt, die den Quellcode einer bestimmten Sprache lesen und auf bestimmte Mängel hin untersuchen, wobei es eine breite Palette an Dingen gibt, nach denen Ausschau gehalten wird bzw. werden kann. Das Spektrum der überprüften Metriken reicht dabei von reinen Stilangelegenheiten wie der Missachtung einer Schreibkonvention über unbenutzte Variablen und Funktionen bis hin zu unnötig ressourcenverbrauchenden Mängeln wie überflüssige Komplexität im Programmcode. Auch wenn das statische Codereviewing seine Grenzen hat (ob zum Beispiel Programmbestandteile unausgeführt bleiben, stellt sich effektiver bei einer dynamischen Überprüfung heraus, bei der der Code auch ausgeführt wird), so fördern gute Codelinter doch oftmals eine ganze Reihe relevanter Punkte zu Tage.

Ein Web Service, der diese Untersuchungsmethode für GitHub Repositories anbietet, ist Codacy, wobei sich auch dieser Dienst mit anderen Git-basierten Codehostern verknüpfen lässt. Codacy hat wie die meisten der Add-ons ein kostenloses Angebot für quelloffene Softwareprojekte und analysiert unter anderem die Sprachen Python, Java, JavaScript, PHP, Ruby und Scala. Die Anbindung des eigenen Repositorys an diesen Testserver geht genauso unkompliziert wie bei Travis CI vonstatten – und zwar wieder einfach per Mausklick von der Homepage des Anbieters aus. Dieser Dienst benötigt nicht einmal eine Konfigurationsdatei, sondern stellt die verwendete Programmiersprache automatisch fest. Besondere Einstellungen vom Benutzer sind erst einmal nicht notwendig. Es werden einfach ein oder mehrere Repositories auf der Benutzerseite bei Codacy freigeschaltet und die erste Überprüfung beginnt unmittelbar darauf.

Je nach Umfang des Projekts braucht ein Review-Prozess mit der eingebauten Intelligenz ein wenig Zeit, bis der Quellcode vollständig untersucht ist. Die Ergebnisse werden danach sofort auf einer Seite bei Codacy ausführlich dargestellt, wobei der Dienst hinsichtlich der festgestellten Codequalität zunächst ein Zertifikat über eine bestimmte Rangstufe vergibt (Abb. 4). Hat das eigene Projekt eine hohe Güteklasse (z. B. „A“) erreicht, möchte man das eventuell gerne auch auf der Projektseite bei GitHub ausstellen. Codacy bietet hierfür einen HTML-Badge für die README-Datei an (Abb. 3). Neben dem Gesamtergebnis und den in bestimmten Kategorien erreichten Prozentraten gibt es bei Codacy auf dem Dashboard des eigenen Projekts auch noch eine detaillierte Liste mit den festgestellten Einzelproblemen (Issues Breakdown), zu denen auch jeweils der beanstandete Codeabschnitt angeführt wird. Die Liste der verbleibenden Codemängel über einen Button auf GitHub erreichbar öffentlich auszustellen – wenn es kein Armutszeugnis darstellt – lädt nicht zuletzt vielleicht auch dazu ein, einige Punkte abzuarbeiten und hilft so dabei, Entwickler für die Mitarbeit an einem Projekt zu gewinnen.

Abb. 4: Ein Dashboard bei Codacy

Abb. 4: Ein Dashboard bei Codacy

Landscape

Ein anderer für GitHub geeigneter Codereviewservice speziell für Python-Software ist Landscape. Die Eckpunkte für den Einsatz dieses Service für eigene Repositories entsprechen denen anderer bereits besprochener Add-ons. Ein nützliches Spin-off von Landscape ist der Codelinter prospector, der als normale Kommandozeilenapplikation lokal und unabhängig vom Internet eingesetzt werden kann. prospector läuft im Backend von Landscape unter der Haube und überprüft den Code umfassend nach Konventionen gemäß PEP-8 und PEP-257. Außerdem setzt er unter anderem die unabhängigen Programme Pylint, Pyflakes und Vulture ein und prüft auf zu hohe zyklomatische Komplexität nach McCabe. Der CLI-Ableger eignet sich auch dafür, neuen Code schon zu überprüfen, bevor man ihn auf GitHub hochlädt und danach immer erst den Onlinedienst mit eventuell negativem Ergebnis drüberlaufen lässt.

SourceClear

SourceClear fällt ein wenig aus dem Rahmen der hier besprochenen GitHub-Add-ons, denn es gibt hier gegenüber dem sehr teuren Professional-Plan nur ein stark eingeschränktes kostenloses Angebot für Hobbybenutzer. Quelloffene bzw. freie Projekte, die oftmals keinen kommerziellen Hintergrund haben, sind hier also nicht freigestellt. Es handelt sich bei diesem Service um einen auf Sicherheitslücken spezialisierten Codescanner. Anders als bei den oben besprochenen statischen Lintern sucht SourceClear (abgekürzt: SRC:CLR) den Programmcode nicht nach vorher definierten, allgemeinen Merkmalen ab, sondern ist auf das Feststellen von Sicherheitsproblemen aus verwendeten Open-Source-Bibliotheken spezialisiert. Quelloffener bzw. frei lizenzierter Code von Bibliotheken wird von anderen Softwareprojekten benutzt; auf diesem Wege gelangen Sicherheitsprobleme von dort unter dem Radar der Nutzer gerade auch in viele kommerzielle Anwendungen. Dieses brisante Thema ist unter anderem in dem im Frühjahr erschienenen Report 2017 Open Source Security & Risk Analysis von Black Duck ausführlich besprochen worden.

BASTA! 2018

Testing in prouction

mit Nico Orschel (AIT GmbH & Co. KG)

Microservices: Technologien im Vergleich

mit Eberhard Wolff (INNOQ)

Survival Guide: Vom Monolithen zu Microservices

mit Lars Röwekamp (Open Knowledge)

Dieser Service lässt sich in eine sehr große Anzahl von unterschiedlichen Workflows einfügen und unterstützt bisher Java, JavaScript, Ruby, Scala, und Python 2.x. Die Liste mag kürzer sein als bei den anderen Add-ons, aber es wird hier für jede Sprache auch ein sehr viel größerer Aufwand betrieben. Der Anwender muss sich zunächst auf der SourceClear-Seite anmelden, wobei immer zunächst eine Gruppe angelegt wird, zu der später auch andere Personen mittels ihrer E-Mail-Adresse eingeladen werden können. Auf der Hauptseite der Gruppe finden sich dann Informationen dazu, wie der Scanserver in bestehende Workflows unter anderem mit Travis CI eingefügt wird. Dafür benötigt man erst einmal einen neuen Arbeitsbereich (auf CREATE NEW WORKSPACE klicken). Für die Zusammenarbeit mit Travis muss der Anwender dann zunächst eine neue Zugriffs-ID generieren (auf REGENERATE TOKEN klicken), die dann auf der Seite des eigenen Softwareprojekts – unter Settings | Environment Variables als SRCCLR_API_TOKEN abzulegen ist. Danach muss die .travis.yml-Datei um den Eintrag addons: srcclr: true ergänzt werden. Wenn dann der nächste Commit bei GitHub hochgeladen ist, läuft dieser Dienst automatisch an und scannt den Quellcode durch, nachdem Travis das Projekt zunächst gebaut bzw. getestet hat. SourceClear bietet aber auch ein Kommandozeilenwerkzeug für macOS und Linux an, mit dem der Dienst auch ohne die Anbindung an Travis vom eigenen Rechner aus gestartet und auf beliebige GitHub Repositories angewendet werden kann.

Auf der Gruppenseite finden sich dann die Informationen zum überprüften Projekt – und zwar über die verwendeten Bibliotheken, eine Auflistung der Lizenzen, die im Spiel sind, und eine Liste mit offenen Sicherheitsproblemen (Abb. 5). Diese Liste der Insights ist natürlich nicht öffentlich zugänglich. Unter den einzelnen Punkten zum Thema Sicherheit finden sich detaillierte Informationen inklusive der CVE-Nummer (der von US-Institutionen vergebene Common Vulnerabilities und Exposures Identifier), falls für das Sicherheitsleck bereits eine ausgestellt worden ist. Zu den Informationen gehört auch eine von SourceClear vorgenommene Kategorisierung des Problems mit Schweregrad und Hinweisen, ob eventuell ein Fix in einer aktuelleren Fassung der Bibliothek zur Verfügung steht. Der Entwickler sollte dann auf jeden Fall die eingestellte Abhängigkeit aktualisieren; gegebenenfalls muss dafür auch der eigene Code an die neuere Version angepasst werden.

Abb. 5: Das Resultat eines Scans bei SourceClear

Abb. 5: Das Resultat eines Scans bei SourceClear

Coverity Scan

Ein weiterer Securityscanner, der dafür vorgesehen ist, mit GitHub Repositories zusammenzuarbeiten, ist Coverity Scan. Es handelt sich dabei um einen wiederum für Open-Source-Projekte kostenlosen Ableger von Coverity Static Analysis – einer Applikation für die statische Codeüberprüfung mit Fokus auf Programmsicherheit –, der unter anderem Java-, JavaScript-, C/C++-, Ruby- und Python-Programmcode untersuchen kann. Coverity ist sehr einschlägig im Auffinden von versteckten Softwarebugs und wird/wurde erfolgreich unter anderem beim Linux-Kernel, im CERN für den Teilchenbeschleuniger und beim Marsrover „Curiosity“ eingesetzt – und was für die gut ist, ist auch gut für das eigene Projekt. Bei diesem Add-on funktioniert es ähnlich wie bei den anderen: Nachdem man einen Benutzer angelegt hat, können die eigenen GitHub Repositories zur Überprüfung freigeschaltet werden, wobei der öffentliche Zugang zu den Ergebnissen auch eingeschränkt werden kann. Dann muss allerdings erst mit einem speziellen Self-build-Tool von Coverity ein Tarball vom Projekt erstellt und hochgeladen werden. Etwas unkomplizierter ist es, den Service in einen bereits vorhandenen Workflow mit Travis CI einzubinden – auf der Seite von Coverity gibt es eine Anleitung dafür.

Fazit

Tatsächlich ist dies nur ein Ausschnitt aus dem Bereich GitHub-Add-ons, denn es gibt noch einige weitere Kategorien von Angeboten, zum Beispiel Testabdeckung (Coveralls.io und Codecov.io), API-Monitoring (Runscope) sowie Dokumentationsbau und -hosting (Read the Docs für Python). Darüber hinaus gibt es auch noch einige rein kommerzielle Anbieter wie zum Beispiel Scrutinizer. Auf einer weiteren Schicht um die GitHub-Repos herum lassen sich die assoziierbaren Services auch noch mit anderen Onlinediensten verknüpfen, zum Beispiel mit Hostingprovidern wie Heroku, AWS Code Deploy oder OpenShift. So lässt sich ohne großen Aufwand und sozusagen beinahe per Knopfdruck eine ganze DevOps-Kette aufsetzen, die vom Codehosting auf GitHub bis zum unmittelbaren Deployment reicht.

Viele Programmierer heißen dieses üppige Buffet sehr willkommen und bauen dies und das gewinnbringend in den eigenen Workflow ein. Problematisch wird es allerdings schnell bei der professionellen bzw. kommerziellen Softwareentwicklung. Wenn externe Services wie diese zu maßgeblichen Bestandteilen der Produktionskette werden, sollte man immer vorsichtig sein, damit man nicht im berüchtigten Vendor Lock-in in zu starke Abhängigkeit gerät, aus der man sich nicht mehr ohne Weiteres befreien kann. Das betrifft sicherlich mehr die kommerziellen Angebote der hier vorgestellten Dienste, die zwar erfahrungsgemäß besseren Support als bei den kostenlosen Plänen genießen, aber auch nicht vor bestimmten Risiken gefeit sind. Es kann zum Beispiel passieren, dass ein Anbieter plötzlich aufgekauft wird und sich das Angebot danach von dem gewohnten Merkmalen weg entwickelt, oder dass ein Service durch einen DDOS-Angriff zeitweise stillgelegt wird – meistens gerade, wenn man es gar nicht gebrauchen kann. Sich mit freier Software lokal eine vollständig kontrollierbare Infrastruktur für die Softwareentwicklung aufzubauen, bedeutet zwar einen ungleich höheren Aufwand, hat aber auch gewichtige Vorteile – das betrifft auch GitHub selbst. Trotzdem ist das große Add-on-Angebot innovativ, durchweg gut gemacht und sehr nützlich.

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -