Erkunden der Förderung des Inner-Source-Ansatzes
Der Fork-basierte Pull Request-Workflow ist bei Open-Source-Projekten beliebt, da er es jedem ermöglicht, an einem Projekt mitzuwirken.
Sie müssen kein vorhandener Mitwirkender sein oder über Schreibzugriff für ein Projekt verfügen, um Ihre Änderungen anbieten zu können.
Dieser Workflow ist nicht nur für Open Source gedacht: Forks helfen auch bei der Unterstützung von Inner-Source-Workflows in Ihrem Unternehmen.
Vor der Verwendung von Forks hatten Sie die Möglichkeit, etwas mithilfe von Pull Requests zu einem Projekt beizutragen.
Der Workflow ist denkbar einfach: Pushen Sie einen neuen Branch in Ihr Repository, öffnen Sie ein Pull Request, um eine Codeüberprüfung durch Ihr Team zu erhalten, und lassen Sie Azure Repos Ihre Branchrichtlinien bewerten.
Mit einem Klick können Sie Ihr Pull Request im Mainbranch zusammenführen und bereitstellen, sobald Ihr Code genehmigt ist.
Dieser Workflow eignet sich hervorragend für die Arbeit an Ihren Projekten mit Ihrem Team. Was aber, wenn Sie einen einfachen Fehler in einem anderen Projekt Ihres Unternehmens bemerken und ihn selbst beheben möchten?
Was ist, wenn Sie ein Feature zu einem von Ihnen verwendeten Projekt hinzufügen möchten, das aber von einem anderen Team entwickelt wird?
Hier kommen Forks ins Spiel. Forks sind das Herzstück der Inner-Source-Methoden.
Inner Source
Inner Source – manchmal auch als „internes Open Source“ bezeichnet – bringt alle Vorteile der Open-Source-Softwareentwicklung innerhalb Ihrer Firewall mit sich.
Es öffnet Ihre Softwareentwicklungsprozesse, sodass Ihre Entwickler problemlos unternehmensweit an Projekten zusammenarbeiten können.
Es werden dieselben Prozesse verwendet, die in den Open-Source-Softwarecommunitys beliebt sind.
Aber es wird dafür gesorgt, dass Ihr Code in Ihrem Unternehmen sicher ist und bleibt.
Microsoft verwendet in hohem Maße den Inner-Source-Ansatz.
Im Rahmen der Bemühungen, ein einheitliches Entwicklungssystem im gesamten Unternehmen zu standardisieren – unterstützt durch Azure Repos – hat Microsoft auch den Quellcode aller unserer Projekte für alle Mitarbeiter des Unternehmens geöffnet.
Vor der Umstellung zum Inner-Source-Ansatz war Microsoft „abgeschottet“: Nur Techniker, die an Windows arbeiteten, konnten den Windows-Quellcode lesen.
Nur Entwickler, die an Office arbeiten, konnten den Office-Quellcode einsehen.
Wenn Sie also ein Techniker sind, der an Visual Studio arbeitet und der Meinung ist, dass Sie in Windows oder Office einen Fehler gefunden haben oder ein neues Feature hinzufügen möchten, haben Sie leider Pech.
Aber durch den Wechsel zur Bereitstellung interner Quellen im gesamten Unternehmen, der von Azure Repos unterstützt wird, ist es einfach, ein Repository zu forken, um einen Beitrag zu leisten.
Als Einzelperson, die eine Änderung vornimmt, benötigen Sie keinen Schreibzugriff auf das ursprüngliche Repository, sondern nur die Möglichkeit, es zu lesen und ein Fork zu erstellen.