Zum Inhalt springen

  • Beiträge
    37
  • Kommentare
    108
  • Aufrufe
    8.458

Meet my new friend.... Travis (-CI)!


jSchmalhofer

686 Aufrufe

Ich würde mich nicht als "echten Softwareentwickler" bezeichnen. Dafür habe ich (leider... oder doch eher zum Glück?!) zu oft wirklich, wirklich, wiiiirklich (!) guten, eleganten und effizienten Code von anderen Leuten gesehen und weiß, welche Lücke zwischen meinen Code-Pamphleten und deren Werken klafft. Trotzdem wurde mir irgendwo entlang meines Studiums auch Codeschreiben als Handwerkszeug mitgegeben, das ich immer wieder auch gerne mal nutze oder sogar nutzen muss - so auch für meine Masterarbeit.

 

Und obwohl ich nun kein wirklicher Vollblut-Coder bin, so schätze ich doch sehr die immensen Weiterentwicklungen, die sich in der Welt der Softwareentwicklung in den letzten Jahren ergeben haben. Und damit meine ich nicht nur neue Sprachen (python) oder Sprachversionen (bye bye C89, helloooo C++14 :)), sondern insbesondere auch neue Arbeitsmodelle und Arbeitsweisen. Ein starker Trend der letzten Jahre war und ist immer noch die agile Softwareentwicklung und so sehr sie auch einige eingefahrene und (stellenweise auch) bewährte Arbeitsprozesse, die ich bisher so kannte, "gefährdet" und in Frage stellt, so bin ich im Grunde doch - zumindest insgeheim - ein absoluter Befürworter selbiger. Wie sehr sich agile Entwicklung auch auf andere Branchen und Arbeitsbereiche erfolgreich ausweiten kann oder schon verbreitet hat, weiß ich ehrlich gesagt gar nicht - ein agiler Experte bin ich noch lange nicht. Aber ich weiß, dass ich Prinzipien wie "fail quick" und "deliver fast" als sehr angenehm und produktiv empfinde.

 

Aber was genau hat das mit meiner Masterarbeit zu tun? Und wer verdammt ist Travis? Nun, darf ich vorstellen, mein bisher fleißigster "Mitarbeiter" meiner Masterarbeit (und seine gleichnamige Kollegin) - TRAVIS.

 

travis_male.PNG.8ef50ba9526274b3756100f87007ea3c.PNGtravis_female.jpg.6556e395c9e951e2df62fde75d919d28.jpg

 

Travis, naja genauer gesagt travis-ci.org, ist eine Continuous Integration (CI) Serviceplattform mit direkter GitHub.com-Integration, welche stellenweise auch kostenlos genutzt werden kann. Im Rahmen meiner Masterarbeit Mechatronik muss/sollte ich auch etwas Code schreiben. Da ich bezweifle, einen Million-Dollar-Code (u.a. wegen oben genannter Gründe :)) zu produzieren, habe ich mich für ein Hosting auf Github.com entschieden. Nun, seit meinem Einstieg ins Berufsleben bin ich ein großer Befürworter der Versionierung geworden (und ich meine keine Postfix-Orgien wie XXXXX_v_0_1.doc, XXXXX_v_1_0_final_3_last.doc, .....). Während ich erste Erfahrungen mit SVN gemacht habe bin ich mittlerweile von dem Konzept, den Möglichkeiten und auch der Verbreitung von git schlichtweg begeistert. Ja, git kann manchmal auch etwas brainfuck sein, generell ist es aber ein tolles Versionierungs- und Kollaborationstool. Auch für meine MBA-Masterarbeit habe ich es (damals mit Bitbucket) verwendet.

Mindestens am Ende eines jeden Arbeitstages committe und pushe ich meine Änderungen in mein Github.com-Projekt. Damit habe ich meinen aktuellsten Stand immer verfügbar, egal an welchem Rechner ich sitze, und muss mir keine Gedanken machen, ob ich denn auch ein Backup auf meinem USB-Stick, meiner Festplatte oder einer Dropbox gemacht habe :)  Aber erst das Zusammenspiel mit Travis, macht die Geschichte wirklich interessant:

 

Hat schon mal jemand von euch mit anderen Leuten zusammen an einem Softwareprojekt gearbeitet? Kennt ihr so Sätze wie "Bei mir baut es nicht?", "Ach, diese Datei musst du lokal ändern...." oder "Nein, mit der Version klappt das nicht...."?! Ich wette manche von euch können ein Lied davon singen. Nun, Travis löst diese Probleme nicht direkt, aber bietet mindestens einen Workaround dazu. Ein CI ist im Endeffekt nichts als ein automatisierter Rechenknecht, der zu festgelegten Events (ob nun täglich zu einer festen Uhrzeit, oder jedesmal wenn ein neuer Code-Stad existiert) den zu prüfenden Code kopiert, compiliert und testet. Und egal, ob nur ein Leerzeichen hinzugefügt, einen Schreibfehler korrigiert oder ein komplettes Softwaremodul hinzugefügt hast - der CI arbeitet es durch und nimmt durch Automatisierung dir als Entwickler einiges an Arbeit zur Sicherung der Codequalität ab. Kleinere aber nette Vorteile, die ich in Zusammenhang mit Travis nutze: Ich brauche nicht auf jedem Rechner eine vollständige Entwicklungsumgebung: Ein Texteditor und eine GIT-Installation mit Internetzugang genügen mir, um in meinem Repository zu arbeiten und Code auf Baubarkeit und Funktion&Qualität zu testen. Wie genau das funktioniert? Naja eigtl. nach dem folgenden sehr einfachen Workflow:

 

workflow.PNG.62465bf99a87f2ecd5e3a00bb86750c0.PNG

 

 

  1. Ich schreibe neuen/geänderten Code (i.d.R. versuche ich mich mittlerweile an die Reihenfolge des Test-Driven Development zu orientieren, d.h. erst Tests schreiben und dann dazu die Funktion bis die Tests grün werden).
  2. Ich lade (commit & push) meinen Code in mein Github-Repository --> damit ist mein Code schon mal vor Datenverlust geschützt
  3. Travis CI holt sich meinen Code, baut ihn nach meinen Vorgaben und führt meine definierten Tests (z.B. Unit-Tests, Komponenten-Tests) durch. Und wenn alles fertig ist, bekomme ich sogar per Email eine Benachrichtigung, wenn etwas fehl schlug oder ein Fehler behoben wurde und alles wieder auf grün geschaltet wurde :) 

 

Nun, es steckt natürlich etwas mehr Arbeit dahinter, als sich hier im Text versteckt. Das Aufsetzen von Travis hat - und ich habe mich an direkten Vorgaben von Blogs und anderen Seiten gehalten - alleine ca. 2-3 Tage gedauert. Und selbst jeder Build braucht wegen meiner Dependencies zu anderen riesigen Tools (ROS, aber dazu ein ander mal mehr) ewig zu bauen - bis zu 8min aktuell. Im Vergleich: In meiner virtuellen Maschine (ja, ich arbeite auf einem Win-Rechner aber Code unter Linux) braucht der Build ca. 20s. Aber sofern man sich an die Arbeitsweise mit solch einem CI hält, kann dies auch für durchgängig bessere Codequalität bzw. zumindest Sicherheit bzgl. Baufähigkeit & Testing ermöglichen. Das Code-Schreiben nimmt einem Travis noch nicht ab. Aber ich denke das ist vorerst auch gut so.

 

Tja, soviel mal zu meinem kleinen ersten eigenen Exkurs in die CI-Welt. Hat jemand von euch Erfahrung mit agiler Entwicklung? Mit Github und Konsorten? Oder gar auch mit TRAVIS? Ich bin an jeglichen Tipps aber auch an generellem Info-Austausch sehr interessiert, also nur her damit :) 

 

 

 

 

 

1 Kommentar


Empfohlene Kommentare

Nachtrag: Ich fange an Travis nicht mehr zu mögen :37_disappointed: Die Buildumgebung auf dem Buildserver scheint doch etwas anders konfiguriert zu sein (ROS in einem Docker-Container statt nativ installiert) und damit bauen manche Pakete zwar lokal aber nicht mehr auf Travis. Aktuell ist es aber schwer nachvollziehen, wieso es nicht baut, weil das Debugging auf Travis schwerer fällt als lokal.... Ich hoffe ich kriege das noch um Laufen und es war keine "kurze Gastvorstellung" :) 

Link zu diesem Kommentar

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden


×
  • Neu erstellen...