Quellcodeverwaltung – ein entscheidender Punkt für alle LabVIEW-Entwickler

[LabVIEW-Blog-Team]

Bremsenprüfstand_1; Bremsenprüfstand_Stand_Feb_2014; Bremsenprüfstand_Neu … So oder so ähnlich sieht es oft in den Verzeichnissen von Projekten aus. Gerade bei LabVIEW-Anwendungen kann es durch die Doppeldeutigkeiten von VI-Namen hier zu großen Problemen kommen. Dennoch möchte man alte Softwarestände behalten und archivieren. Dies kann mehrere Gründe haben: Zunächst, weil man sich sicher ist, dass dieser Softwarestand funktioniert. Eventuell aber auch, weil eine bestimmte Norm dazu zwingt, jederzeit Tests auch mit einem definierten Softwarestand zu wiederholen. Die Lösung dieses Problems ist die richtige Quellcodeverwaltung mit den entsprechenden Tools. LabVIEW bietet hier keine eigene Lösung, sondern wartet mit Schnittstellen zu den gängigen Tools auf.

Im Rahmen der diesjährigen LabVIEW Developer Days ist durch das Feedback der Anwender ein Dokument zum Thema „Beste Herangehensweisen zum Thema Source Code Control in LabVIEW“ entstanden. Da wir dieses Dokument gerne weiter wachsen lassen – also mit Ihrem Feedback erweitern wollen –, haben wir uns entschieden, es an dieser Stelle zu posten, sodass Sie direkt in den Kommentaren weiteres Feedback geben und sich austauschen können.

Alle Informationen zu unseren LabVIEW Developer Days finden Sie hier.

Download „Beste Herangehensweisen zum Thema Source Code Control in LabVIEW“

Download Präsentationen LabVIEW Developer Days

[Ludwig72]

Das ist ein ganz wichtiges Thema, wenn es an die Entwicklung größerer Projekte geht und sollte deshalb so früh wie möglich im Projekt geklärt sein. Leider hakt es im Alltag dann doch an vielen Dingen, wie z.B. der Philosophie der Firma in Sachen SCC, der Zeit, die man eigentlich programmieren will usw. Ich finde es sehr gut, dieses Thema aufzugreifen!

[comrade]

Danke für das Aufgreifen dieses Themas.

Insbesondere der Hinweis auf die Trennung vom kompilierten Code ist wichtig, denn ungewünschte Änderungen treten nicht nur auf, wenn SubVI Callers neu kompiliert werden sollen, sondern auch, wenn zwei Entwickler-PCs einen unterschiedlichen Stand bei den Hardwaretreibern haben. Damit muss dann jedes Mal beim PC-Wechsel (zB Laptop - BüroPC oder Rechner zweier verschiedener Entwickler) alles, was bspw. DAQmx oder IMAQ benutzt, neu kompiliert werden. Obwohl man diese VIs nicht mal offen, geschweige denn editiert hatte.

Vor allem muss aber allen Beteiligten, den Programmierer, den Projektleitern und auch dem Management, klar sein, dass die tatsächliche Programmierzeit im Normalfall etwas sinken wird, denn SCC sinnvoll zu benutzen kostet Zeit, in der nicht entwickelt wird. Zeit (und Geld) gespart wird dadurch im Falle von Festplattenausfall oder (ganz wichtig) bei "Fehlentwicklung", die nicht mehr so einfach manuell rückgängig zu machen ist.

Im einfachsten Fall macht man morgens ein Update vor Beginn des Programmierens, um Änderungen durch andere Programmierer auf der eigenen WorkingCopy zu aktualisieren, wogegen spätestens bei Arbeitsende ein Commit durchgeführt wird, um die eigenen Änderungen ins Repository zu spielen und somit für andere nutzbar zu machen. Eigentlich sollten jedoch auch einzelne Änderungen an einzelnen VIs schon "committed" werden: Wer weiß denn bei 8h Programmierarbeit am Ende des Tages noch ganz genau, was er in welchem VI geändert hat und welche neuen VIs genau wozu geschrieben wurden? Und da beginnt die SCC dann schon etwas aufwändiger zu werden, weil bei jedem Commit die erfolgten Änderungen ja auch im Log dokumentiert werden sollten - aber nur so macht es auch wirklich Sinn. Ein Teil der Software-Doku verlagert sich somit auch ins Log der SCC...

[berel]

Guten Tag

Der Link zum Dokument funktioniert leider nicht mehr.