Eksplorowanie zastępczego źródła wewnętrznego

Przepływ pracy żądania ściągnięcia oparty na forkowaniu jest popularny w projektach typu open source, ponieważ umożliwia każdemu zainteresowanemu współtworzenie projektu. Nie musisz być obecnym współautorem ani mieć uprawnień do zapisu w projekcie, aby zaproponować swoje zmiany.

Ten przepływ pracy nie jest przeznaczony tylko dla typu open source: rozwidlenia ułatwiają również obsługę przepływów pracy źródła wewnętrznego w firmie.

Tradycyjny przepływ pracy zespołu

Przed rozwidleniami można było przyczynić się do projektu, używając Pull Requestów. Przepływ pracy jest prosty:

1. Wypchnij nową gałąź do repozytorium.
2. Otwórz pull request, aby uzyskać przegląd kodu od zespołu.
3. Poproś usługę Azure Repos o sprawdzenie zasad gałęzi.
4. Kliknij jeden przycisk, aby scalić żądanie ściągnięcia z serwerem głównym i wdrożyć po zatwierdzeniu kodu.

Ten przepływ pracy doskonale nadaje się do pracy nad projektami z zespołem. Ale co zrobić, jeśli zauważysz prostą usterkę w innym projekcie w firmie i chcesz go naprawić samodzielnie? Co zrobić, jeśli chcesz dodać funkcję do projektu, którego używasz, ale inny zespół opracowuje?

W tym miejscu pojawiają się forki; Forki znajdują się w centrum praktyk inner source.

Co to jest źródło wewnętrzne?

Źródło wewnętrzne — czasami nazywane "wewnętrznym oprogramowaniem typu open source" — przynosi wszystkie korzyści wynikające z tworzenia oprogramowania typu open source w zaporze firmy.

Źródło wewnętrzne otwiera procesy tworzenia oprogramowania, dzięki czemu deweloperzy mogą łatwo współpracować nad projektami w całej firmie. Używa on tych samych procesów, które są popularne w społecznościach oprogramowania typu open source, ale zapewnia bezpieczeństwo kodu w organizacji.

Zalety źródła wewnętrznego

• Współpraca między zespołami: zespoły mogą współpracować nad projektami, nawet jeśli zwykle nie współpracują.
• Udostępnianie wiedzy: Deweloperzy mogą uczyć się od kodu napisanego przez inne zespoły i stosować te lekcje do własnej pracy.
• Ponowne użycie kodu: zamiast wielokrotnie tworzyć te same funkcje, zespoły mogą opierać się na istniejącej pracy.
• Poprawa jakości: Więcej osób przeglądających i przyczyniających się do kodu zwykle prowadzi do lepszej jakości oprogramowania.
• Szybsze innowacje: zespoły mogą poruszać się szybciej, opierając się na istniejących rozwiązaniach, a nie zaczynając od podstaw.

Wewnętrzna podróż źródłowa firmy Microsoft

Firma Microsoft intensywnie korzysta z wewnętrznego podejścia źródłowego. W ramach wysiłków związanych z tworzeniem jednego systemu inżynieryjnego w całej firmie — wspieranego przez usługę Azure Repos — firma Microsoft otworzyła kod źródłowy wszystkich projektów wszystkim osobom w firmie.

Przed źródłem wewnętrznym

Przed przejściem do źródła wewnętrznego firma Microsoft była "silosowana":

• Tylko inżynierowie pracujący w systemie Windows mogą odczytać kod źródłowy systemu Windows.
• Tylko deweloperzy pracujący nad pakietem Office mogą przyjrzeć się kodowi źródłowego pakietu Office.
• Jeśli jesteś inżynierem pracującym nad programem Visual Studio i znalazłeś usterkę w systemie Windows lub Pakiecie Office lub chcesz dodać nową funkcję , nie masz szczęścia.

Po źródle wewnętrznym

Dzięki przejściu do źródła wewnętrznego w całej firmie, obsługiwanej przez usługę Azure Repos, łatwo jest utworzyć rozwidlenie repozytorium w celu ponownego współtworzenia. Jako osoba wprowadzająca zmianę nie potrzebujesz uprawnień do zapisu do oryginalnego repozytorium, tylko możliwość jego odczytania i utworzenia forka.

Podejście to umożliwiło:

• Lepsza współpraca między zespołami.
• Szybsze poprawki błędów i programowanie funkcji.
• Ulepszona jakość kodu dzięki szerszemu przeglądowi.
• Zmniejszenie duplikacji nakładu pracy w projektach.