Erkunden der Förderung des Inner-Source-Ansatzes

  • 3 Minuten

Der auf Fork basierende Pull-Anfrage-Workflow ist bei Open-Source-Projekten beliebt, da jeder an einem Projekt mitwirken kann. Sie müssen kein vorhandener Mitwirkender sein oder schreibzugriff auf ein Projekt haben, um Ihre Änderungen anzubieten.

Dieser Workflow ist nicht nur für Open Source gedacht: Forks helfen auch bei der Unterstützung von Inner-Source-Workflows in Ihrem Unternehmen.

Herkömmlicher Teamworkflow

Bevor es Forks gab, konnten Sie mithilfe von Pull-Requests zu einem Projekt beitragen. Der Workflow ist einfach:

  1. Pushen Sie eine neue Verzweigung in Ihr Repository.
  2. Öffnen Sie eine Pull-Anforderung, um eine Codeüberprüfung von Ihrem Team zu erhalten.
  3. Lassen Sie Azure Repos Ihre Branchrichtlinien prüfen.
  4. 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 geschieht, wenn Sie einem von Ihnen verwendeten Projekt ein Feature hinzufügen möchten, aber ein anderes Team entwickelt?

Hier kommen Forks zum Einsatz; Forks sind das Herzstück der Inner Source-Praktiken.

Was ist innere Quelle?

Innere Quelle – manchmal als "interne Open Source" bezeichnet – bringt alle Vorteile der Open-Source-Softwareentwicklung in Ihrer Unternehmensfirewall.

Innere Quelle öffnet Ihre Softwareentwicklungsprozesse, damit Ihre Entwickler problemlos an Projekten in Ihrem Unternehmen zusammenarbeiten können. Es verwendet die gleichen Prozesse, die in den Open-Source-Software-Communitys beliebt sind, aber es sorgt dafür, dass Ihr Code in Ihrer Organisation sicher und sicher bleibt.

Vorteile der inneren Quelle

  • Teamübergreifende Zusammenarbeit: Teams können an Projekten zusammenarbeiten, auch wenn sie normalerweise nicht zusammenarbeiten.
  • Wissensaustausch: Entwickler können aus Code lernen, der von anderen Teams geschrieben wurde, und diese Lektionen auf ihre eigene Arbeit anwenden.
  • Codewiederverwendung: Anstatt die gleiche Funktionalität mehrmals zu erstellen, können Teams auf vorhandenen Arbeiten aufbauen.
  • Qualitätsverbesserung: Mehr Personen, die code überprüfen und beitragen, führen in der Regel zu einer besseren Qualität von Software.
  • Schnellere Innovation: Teams können schneller vorankommen, indem sie auf vorhandenen Lösungen aufbauen, anstatt von Grund auf neu zu beginnen.

Die innere Quellreise von Microsoft

Microsoft verwendet in hohem Maße den Inner-Source-Ansatz. Als Teil der Bemühungen, ein Engineering-System im gesamten Unternehmen – unterstützt von Azure Repos – zu erstellen, hat Microsoft den Quellcode aller Projekte für alle Projekte innerhalb des Unternehmens geöffnet.

Vor innerer Quelle

Vor dem Wechsel zu Inner Source war Microsoft isoliert.

  • Nur Ingenieure, die unter Windows arbeiten, konnten den Windows-Quellcode lesen.
  • Nur Entwickler, die an Office arbeiten, konnten den Office-Quellcode einsehen.
  • Wenn Sie ein Techniker waren, der an Visual Studio arbeitet und einen Fehler in Windows oder Office gefunden hat oder ein neues Feature hinzufügen wollte, waren Sie nicht erfolgreich.

Nach Inner Source

Durch den Wechsel zu Inner Source im gesamten Unternehmen, unterstützt von Azure Repos, ist es einfach, ein Repository zu verzweigen, um mitzuwirken. Als Einzelperson, die Änderungen vornimmt, müssen Sie keinen Schreibzugriff auf das ursprüngliche Repository haben, sondern lediglich die Fähigkeit, es zu lesen und einen Fork zu erstellen.

Dieser Ansatz hat Folgendes ermöglicht:

  • Bessere teamübergreifende Zusammenarbeit.
  • Schnellere Fehlerbehebungen und Featureentwicklung.
  • Verbesserte Codequalität durch umfassendere Überprüfung.
  • Verringerte Duplizierung des Aufwands für alle Projekte.