Compliance in der DVCS-Verwaltung im Unternehmenskontext: Was ist von einer Umstellung von CVCS (Perforce) zu erwarten?

Question

Ich arbeite als Softwareentwickler in einem großen multinationalen Unternehmen und führe derzeit ein sehr gutes Gespräch mit der IT und anderen Entwicklern über die Einführung eines DVCS (Mercurial und/oder Git).

Eines der von der IT angesprochenen Themen war Compliance und geistiges Eigentum (Übrigens,Notgedrungen spricht man laut darüberund in Bezug auf Git). Mir scheint, die IT-Abteilung hat den Eindruck, dass aufgrund der verteilten Architektur von Mercurial/Git die Verfügbarkeit von Repositorys auf jedem Entwicklercomputer ein unkontrollierbares Szenario darstellt und sie jedes einzelne Repository prüfen müssten.

Ein weiterer Punkt, der meiner Meinung nach die IT beunruhigt, ist die Tatsache, dass es jetzt „100“ Repositories gibt statt „10“ riesiger. Ich habe den Eindruck, dass sie denken, ihr Verwaltungsaufwand für deren Wartung/Überwachung würde sich „verzehnfachen“. Ich denke, Repository-Verwaltungssoftware (Rhodecode, Atlassian Stash) wäre der erste Schritt in Richtung Zugriffskontrolle und Rückverfolgbarkeit.

Meine Fragen sind:

1. Reicht eine Repository-Verwaltungssoftware für ein Unternehmen dieser Größe (sagen wir etwa 2.000 Entwickler und etwa 50 Perforce-Depots auf etwa 10 Servern) aus, um konform zu sein (und andere Unternehmensanforderungen zu erfüllen)?

2. Was genau ist mit dieser „Compliance“-Anforderung verbunden? Können Sie Referenzen angeben (z. B. einen IEEE-Standard oder etwas Ähnliches)?

Meine Firma verwendet Perforce seit ca. 10 Jahren

Answer 1

Wenn Sie zu einem DVCS wechseln, ändert sich eigentlich nicht viel. Der große Unterschied besteht darin, dass die Kopie des Quellcodes auf der Workstation jedes Entwicklers nun ebenfalls ein eigenes Repository ist.

Ich bezweifle, dass die IT-Abteilung sich darüber viele Gedanken machen muss. Nur weil Git und Mercurial verteilt sind, heißt das nicht, dass Sie direkt vom Desktop eines Entwicklers aus bereitstellen/liefern können. Es ist immer noch möglich – und mit ziemlicher Sicherheit auch notwendig –, weiterhin einige zentrale Repos zu verwenden, in die jeder zum Testen, zur Qualitätssicherung und zur endgültigen Veröffentlichung eincheckt.

Ob die IT den Quellcode auf den Workstations der Entwickler überwacht oder nicht, ändert nichts wirklich. Sie erhalten den Änderungsverlauf immer noch in den zentralen Repos, sobald sie übertragen werden, und ich vermute, das ist es, was ihnen wirklich am Herzen liegt.

Was dugewinnenAus IT-Sicht bedeutet dies, dass Sie nicht alle paar Minuten (oder Sekunden!) auf die zentralen Repos zugreifen, wenn die Entwickler ein Commit durchführen. Entwickler können die Arbeit an etwas beenden und es erst dann hochladen, wenn es fertig ist, haben aber dennoch die vollständige Versionskontrolle auf ihrer Workstation, ohne annähernd so oft auf das Netzwerk zugreifen zu müssen.

Schließlich müssen Sie mit der IT-Abteilung ausführlicher über die genaue Art der Compliance-Probleme sprechen, von denen sie sprechen. Dabei kann es sich um alles Mögliche handeln, von der Verwaltung geistigen Eigentums über ISO 9000 bis hin zu bestimmten Gesetzen/Vorschriften.

(An alle: Fühlt euch frei, diese Antwort zu verbessern; dies istnichtmein Fachgebiet...)