Mit der Digitalisierung ist zweifellos ein goldenes Zeitalter für Software-Entwickler angebrochen. Durch Megatrends wie Industrie 4.0 wird Software zunehmend auch in den Fabrik­hallen allgegenwärtig: Maschinen müssen vernetzt, Kommunikationsprotokolle entwickelt, SPS-Steuerungen angepasst werden. Der Bedarf an kompetenten Entwicklern ist daher hoch wie nie – und nicht selten konfrontieren diese ihre ­potenziellen Arbeitgeber schon bei der Erstanstellung mit Bedingungen, etwa im künftigen Berufsalltag mit dem Entwicklungswerkzeug ihrer Wahl arbeiten zu dürfen. Ganz oben auf der Beliebtheitsskala findet sich dabei das Open-Source-Tool Git: Mit einer Nutzungsrate von laut Gartner knapp 30 % gehören DVCS-Lösungen (für die verteilte Versionskontrolle) wie Git aktuell zu den am weitesten verbreiteten Entwicklertools. 

Git wurde ursprünglich von Linus Torvalds für die Versionierung des Linux-Kernels entwickelt und hat auch dank GitHub (eine Online-Hosting-Lösung, die heutzutage große Teile der Open-Source-Projekte verwaltet) weite Verbreitung gefunden. Git speichert Änderungen als Knoten in einem DAG (Directed Acyclic Graph) ab, und identifiziert diese mit einem kryptografischen Schlüssel. Jedes Projekt in Git wird in einem eigenen sogenannten ‚Repository‘ gespeichert. Ein Repository enthält nicht nur alle Dateien eines Projektes, sondern auch die gesamte Historie des Projektes. Ein Anwender lädt (‚clone‘) das gesamte Repository von einer zentralen Kopie in den lokalen Arbeitsbereich, fügt lokal Änderungen hinzu und schickt diese Änderungen dann wieder zurück zur zentralen Version.

Während Anwender an Git vor allem dessen Offenheit sowie die Möglichkeit schätzen, mit einem lokalen R­epository arbeiten zu können, erweisen sich seine konzeptuellen und funktionalen Beschränkungen im Unternehmenskontext unter Umständen als problematisch. So arbeitet Git ab einer bestimmten Repository-Größe nicht mehr mit bestmöglicher Effizienz, große Dateien und nicht-text­basierte Assets werden nur eingeschränkt beziehungsweise gar nicht unterstützt. Auch bezüglich Nachverfolgbarkeit, Fehlerbehebung und Sicherheit kann die Lösung den Anfor­derungen moderner Software-Entwicklung nicht uneingeschränkt gerecht werden. Wer hat wann welche Änderungen am Quellcode vorgenommen und warum? Welche Änderung führte zu einem Fehler? Wie lässt sich das geistige Eigentum bestmöglich gegen Verlust oder Diebstahl von innen absichern? Auf Fragen wie diese kann Git keine Antworten liefern, denn dafür ist das Werkzeug nie konzipiert worden.

Um dem Spannungsfeld zwischen den Vorlieben der Entwickler auf der einen und den Anforderungen des Unternehmens auf der anderen Seite gerecht zu werden, bedarf es daher einer Möglichkeit, die bestehenden Einschränkungen von Git durch Erweiterungen und neue Funktionen aufzulösen. Git muss zu einer flexiblen, leistungsstarken und teamorientierten Lösung für eine effiziente Software-Eentwicklung werden – zu einer Art zentralem ‚Facebook für Entwickler‘.

Skalierung statt epository-Wucher

Über die Frage, auf welche Größe ein Git-Repository anwachsen kann, bevor die Performance darunter leidet und eine effiziente Verwaltung zu komplex wird, lässt sich streiten. Die meisten Anwender sind sich jedoch darüber einig, dass dieses Limit bei etwa 1 bis 5 GByte liegt. Da Git-Repositories typischerweise ihre gesamte Bearbeitungshistorie bei sich behalten, wird die ­Größe eines einzigen aktiv genutzten Repositories aber auch dann mit der Zeit anwachsen, wenn die Code-Basis selbst nicht an Größe zunimmt.

Gerade für große Projekte ist diese Einschränkung problematisch, denn je nach Komplexität und Umfang der entwickelten Software ist dieses Limit schnell überschritten. Eine weit verbreitete Möglichkeit, diese Einschränkung zu umgehen, besteht darin, das Projekt in mehrere kleine Teile aufzuteilen, von denen jeder sein eigenes Repository besitzt. Ein extremes Beispiel hierfür ist der Quellcode von Android: Mittlerweile erstreckt sich dieser über mehr als 1000 Repositories. Per se ist die Verteilung von Code auf mehrere Repositories noch keine schlechte Sache – solange jedes Repository eine eigenständige Komponente beinhaltet, die sich unabhängig von allen anderen Projektteilen weiterentwickelt. 

In der Realität ist eine solche echte Komponentenstruktur jedoch oft nur schwer erreichbar, und das Aufteilen einer bestehenden monolithischen Applikation in autonome Teile gestaltet sich als komplizierter und kostenintensiver Prozess. Wer sich dennoch dafür entscheidet, muss akribisch darauf achten, am Ende keinerlei Kopplungen zwischen unterschiedlichen Repositories zu übersehen. Denn bleibt die Abgrenzung unvollständig – und dies ist leider tatsächlich nicht selten der Fall – gefährdet die fehlende Kohärenz bei Änderungen in den getrennten Repositories schnell die Stabilität des gesamten Projekts. In solchen Fällen diejenige Änderung aufzuspüren und zu berichtigen, welche die Störung verursacht hat, ist in Szenarien mit einer Vielzahl an unabhängigen Repositories extrem kompliziert. 

In Projekten mit besonders umfassender oder stark anwachsender Code-Basis kann eine zentralisierte Git-Management-Lösung dafür sorgen, dass auch beliebig große Quelltextmengen sowie Dateien beliebiger Größe in Git verwaltet und genutzt werden können. Eine Zerstückelung des Projekts ist dann nicht mehr notwendig, so dass auch bei großen Projekten dieselbe effiziente Arbeitsweise und lückenlose Nachverfolgbarkeit von Fehlerquellen sichergestellt bleibt wie bei kleineren Projekten. 

Mehr als nur Quelltext ­versionieren

Git-Management-Lösungen brechen die Einschränkungen von Git auf und erleichtern die Arbeit im Team. Git erlaubt auch die Inter­aktion unter den verschiedenen Projektbeteiligten.

© Perforce

Eine weitere Einschränkung bei der Git-Nutzung im Unternehmenskontext ist der unausgereifte Umgang mit großen Binärdateien, die schnell für ein deutliches Anwachsen der Repository-Größe sorgen können. Git ist dabei nicht in der Lage, Datei-Inhalt zu komprimieren, so dass zentrale Aktionen wie das Erstellen einer Arbeitskopie des Repository (‚git clone‘), das Herunterladen von Objekten aus dem zentralen Repository (‚git fetch‘) oder das Übermitteln von Änderungen an das zentrale Repository (‚git push‘) durch große Binärdateien verlangsamt werden. Hinzu kommt die Tatsache, dass Git – sobald es eine lokale Datei-Änderung erkennt – die SHA-1-Prüfsumme berechnet. Für (kleine) Textdateien wie Quellcode ist dies schnell erledigt, für große Binär­dateien hingegen nimmt dieser Prozess deutlich mehr Zeit in Anspruch. 

Aus diesem Grund vermeiden es viele Git-Anwender, große Binärdateien in ein Git-Repository zu geben. Stattdessen verwenden sie für deren Versionierung ein separates Repository. Hierdurch ergibt sich jedoch dasselbe Problem, mit dem Unternehmen auch beim Aufteilen ihrer Code-Basis auf mehrere kleinere Repositories konfrontiert werden: Änderungen, die sich über unterschiedliche Repositories erstrecken, lassen sich nur bedingt nachverfolgen. Das Aufspüren und Beheben von Fehlern wird dadurch deutlich erschwert.

Um dem entgegenzuwirken, sollte ein flexibles Git-Management-Tool auf effiziente Art und Weise mit großen Binärdateien umgehen können. Eine Möglichkeit besteht etwa darin, die Dateien in einem separaten Repository zu speichern und gleichzeitig nur eine Verknüpfung zu ihnen im Haupt-Repository beizubehalten. Da gleichzeitige Änderungen an Binär-Assets durch unterschiedliche Nutzer im Gegensatz zu Textdateien nur eingeschränkt automatisiert zusammengeführt werden können, sollte zudem die Option bestehen, die aktuelle Datei, die ein Entwickler gerade bearbeitet, für die Bearbeitung durch andere zu sperren. Auf diese Weise lässt sich verhindern, dass zwei Personen gleichzeitig dieselbe Binärdatei bearbeiten – und wichtige Änderungen dabei im schlimmsten Fall verloren gehen.
 

Geistiges Eigentum schützen

Gerade in Zeiten innovativer Produktionsszenarien in der smarten Fabrik spielt auch die Sicherheit des softwarebezogenen geistigen Eigentums eine immer zentralere Rolle, stellt dieses doch ein wichtiges wettbewerbsrelevantes Kapital des Unternehmens dar. Während für einen bestmöglichen Schutz vor Angriffen von außen das höchstmögliche Sicherheitsniveau jederzeit sichergestellt bleiben muss, darf gleichzeitig die Gefahr von Innentätern nicht aus den Augen gelassen werden: 

Durch Abweichungen vom normalen Verhalten können Spionageversuche von Mitarbeitern erkannt werden.

© Fotolia / Creativa

So schätzt das Bundesamt für Verfassungsschutz im Bereich Wirtschaftsspionage das Verhältnis zwischen Angriffen von innen zu solchen von außen bereits auf 70 zu 30 – knapp zwei Drittel aller Angriffe werden demnach von Mitarbeitern aus dem eigenen Unternehmen durchgeführt.

Spezielle Funktionalitäten, um solche Bedrohungen zu erkennen und ihnen zuvorzukommen, bietet Git seinen Anwendern nicht. Auch in diesem Bereich müssen Unternehmen daher mit Hilfe spezieller Erweiterungen für den bestmöglichen Schutz ihrer wertvollen Entwicklungs-Assets sorgen. Dabei bietet eine Versionsmanagement-Lösung mit ihren umfassenden, detaillierten Protokollen bereits per se die besten Voraussetzungen, schädliche Aktivitäten innerhalb des Unternehmens zu erkennen. Denn auf Basis des Verhaltens der Anwender sind moderne Verhaltensanalysen unter anderem in der Lage, Spio­nageversuche frühzeitig zu identifizieren. 

Hierzu verschaffen sich die entsprechenden Lösungen zunächst einen Überblick über die bisherige Aktivitätshistorie des jeweiligen Unternehmens und gewinnen auf diese Weise ein ­Verständnis dafür, wie das ‚normale‘ Verhalten der Anwender in der Regel aussieht. Mit Hilfe spezieller mathe­matischer Verfahren lassen sich so schließlich Abweichungen von diesem normalen Verhalten ermitteln: Wird beispielsweise der Zugriff eines Anwenders auf ein wichtiges Entwicklungsprojekt protokolliert, das dieser – gemessen an seinem historischen Zugriffsverhalten – normalerweise nicht aufruft, wird dies als Unregelmäßigkeit erkannt. Da es sich dabei jedoch ebenso nur um einen harmlosen Zufall handeln kann, erhöht sich der Risikowert erst durch das Zusammentreffen mehrerer ungewöhnlicher Ereignisse innerhalb kurzer Zeit: Greifen beispielsweise die Kollegen im selben Team ihrerseits nicht auf das Projekt zu und wurden die Dateien zu einer Tages- oder Nachtzeit abgerufen, zu der der Mitarbeiter noch nie zuvor gearbeitet hat, weist dies da-rauf hin, dass das Risiko, das vom Nutzer ausgeht, graduell ansteigt.

Mit der Erweiterung von Git um solche verhaltensbasierten Analysefunktionen erhalten Unternehmen demnach die Möglichkeit, den notwendigen Schutz ihrer geschäftskritischen Entwicklungen bestmöglich sicherzustellen: Denn in begründeten Verdachtsfällen wird es möglich, in Abstimmung mit dem Betriebsrat die Anonymität des betreffenden Nutzers aufzuheben und damit einen weiteren Abfluss von geistigem Eigentum aus dem Unternehmen zu unterbinden.
 

Das Beste aus beiden Welten

Mit der zunehmenden Ausbreitung von intelligenten Maschinen und vernetzten Steuerungssystemen steigt der Bedarf an spezialisierten Programmierern im industriellen Kontext kontinuierlich an. Um die besten Talente gewinnen und dauerhaft an das Unternehmen binden zu können, sind Zugeständnisse oft unvermeidbar. Abstriche bezüglich Effizienz, Qualität und Sicherheit hingegen dürfen Unternehmen in dieser Branche keinesfalls in Kauf nehmen. Mit Hilfe eines integrierten, zentralisierten Git-Management-Tools auf Master- beziehungsweise Mono-Repository-Basis wird Git zu einem offenen, teamorientierten Facebook für Entwickler, das den Anforderungen beider Seiten gerecht wird: Die Möglichkeit, weiterhin in der vertrauten Umgebung eines der beliebtesten Open-Source-Entwicklungstools arbeiten zu können, kombiniert mit der Flexibilität, Skalierbarkeit und Sicherheit, welche die komplexen Softwareprojekte unseres digitalen Zeit­alters unerlässlich machen.

Autor: 
Sven Erik Knop ist Senior Technical Specialist bei Perforce Software.