Planowanie zależności kompilacji dla potoku
- 10 min
W tej lekcji dowiesz się więcej na temat tworzenia pakietów kodu, aby ułatwić udostępnianie. Dowiesz się, dlaczego należy tworzyć pakiety, rodzaje pakietów, które można tworzyć, gdzie można hostować pakiety i jak można uzyskiwać do nich dostęp podczas ich hostowania. Zapoznasz się również z przechowywaniem wersji pakietów.
Bazy kodu zawsze rosną coraz bardziej złożone. Zespół nie może napisać całego kodu używanego przez aplikację. Zamiast tego zespół zawiera istniejący kod napisany przez innych deweloperów. W aplikacji może istnieć wiele z tych pakietów lub zależności. Ważne jest, aby aktywnie zarządzać zależnościami, aby móc je prawidłowo obsługiwać i upewnić się, że spełniają one wymagania dotyczące zabezpieczeń.
Sprawdź, jak sobie radzi zespół. Andy zwołał zespół, aby porozmawiać o potencjalnej zmianie w kodzie, która pomogłaby innemu zespołowi.
Spotkanie zespołu
Andy: Witaj wszystkich. Rozmawiałem z zespołem, który pracuje nad systemem zaplecza dla Space Game. Mogą używać modeli używanych dla witryny internetowej w aplikacji zaplecza, którą planują napisać.
Amita: Co masz na myśli, mówiąc o modelach?
Andy: Jak wiesz, witryna internetowa Space Game jest aplikacją ASP.NET Core. Używa wzorca Model-View-Controller (MVC) w celu oddzielenia danych od sposobu wyświetlania tych danych w interfejsie użytkownika. Myślałem, że możemy utworzyć pakiet zawierający nasze klasy modeli, aby każda aplikacja mogła z nich korzystać.
Amita: Jaki jest dokładnie cel?
Andy: Oba nasze zespoły będą współdzielić tę samą bazę danych. Gra wysyła najlepsze wyniki do bazy danych, a my odczytujemy te wyniki, aby wyświetlić je w rankingu.
Amita: To ma sens. Jak utworzymy ten pakiet?
Andy: Dlatego chciałem porozmawiać z tobą. Mamy kilka możliwości i jestem otwarty na pomysły.
Tim: Chciałbym pomóc, ale najpierw mam kilka pytań. To dla mnie nowość i chcę dowiedzieć się, jak to działa.
Co to jest pakiet?
Pakiet zawiera kod wielokrotnego użytku, którego inni deweloperzy mogą używać we własnych projektach, mimo że nie napisali go.
W przypadku skompilowanych języków pakiet zazwyczaj zawiera skompilowany kod binarny, taki jak pliki .dll w plikach .NET lub .class w języku Java. W przypadku języków, które są interpretowane, a nie kompilowane, takich jak JavaScript lub Python, pakiet może zawierać kod źródłowy.
W obu przypadkach pakiety są zwykle kompresowane do pliku ZIP lub podobnego formatu. Systemy pakietów często definiują unikatowe rozszerzenia plików, takie jak .nupkg lub .jar, aby użycie pakietu było jasne. Kompresja może pomóc skrócić czas pobierania, a także utworzyć pojedynczy plik, aby uprościć zarządzanie.
Pakiety często zawierają również jeden lub więcej plików, które udostępniają metadane lub informacje o pakiecie. Te metadane mogą opisywać działania pakietu, określać postanowienia licencyjne, informacje kontaktowe autora i wersję pakietu.
Dlaczego warto utworzyć pakiet?
Tworzenie pakietu ma wiele korzyści w porównaniu do duplikowania kodu.
Jednym z powodów tworzenia pakietu zamiast duplikowania kodu jest zapobieganie rozbieżności. Gdy kod jest duplikowany, każda kopia może szybko odbiegać od wymagań określonej aplikacji. Migrowanie zmian z jednej kopii do pozostałych staje się trudne. Innymi słowy: traci się możliwość poprawiania kodu w sposób korzystny dla wszystkich.
Pakiety grupują również powiązane funkcje w ramach jednego składnika wielokrotnego użytku. W zależności od języka programowania pakiet może zapewnić aplikacjom dostęp do niektórych typów i funkcji, jednocześnie ograniczając dostęp do szczegółów implementacji.
Innym powodem tworzenia pakietu jest zapewnienie spójnego sposobu kompilowania i testowania funkcjonalności tego pakietu. Gdy kod jest duplikowany, każda aplikacja może kompilować i testować ten kod na różne sposoby. Jeden zestaw testów może obejmować kontrole, z których inny zestaw może przynieść korzyści.
Jednym z kompromisów jest to, że masz inną bazę kodu do testowania i konserwacji przy użyciu pakietu. Podczas dodawania funkcji należy również zachować ostrożność. Ogólnie rzecz biorąc, pakiet powinien zawierać funkcje, które korzystają z wielu rodzajów aplikacji. Na przykład Json.NET to popularny pakiet NuGet dla platformy .NET, który umożliwia pracę z plikami JSON. Json.NET jest składnikiem typu open source, dlatego społeczność może sugerować usprawnienia i zgłaszać problemy.
Jeśli wiele aplikacji może korzystać z tego samego kodu, zalety znacznie przewyższają wady. Istnieje tylko jedna baza kodu, tylko jeden zestaw testów i tylko jeden proces kompilacji, którym trzeba zarządzać.
Jak mogę zidentyfikować zależności?
Jeśli celem jest zreorganizowanie kodu na oddzielne składniki, należy zidentyfikować te elementy aplikacji, które można usunąć, spakować do wielokrotnego użytku, przechowywać w centralnej lokalizacji i wersjonować. Możesz nawet zastąpić własny kod składnikami partnerskimi, które są albo oprogramowaniem open source, albo są dostępne na licencji.
Istnieje wiele sposobów identyfikowania potencjalnych zależności w bazie kodu. Te podejścia obejmują skanowanie kodu pod kątem wzorców ponownego użycia i analizowanie architektury rozwiązania. Oto kilka sposobów identyfikowania zależności:
Zduplikowany kod.
Jeśli niektóre fragmenty kodu pojawiają się w kilku miejscach, oznacza to, że można ponownie użyć kodu. Scentralizuj te zduplikowane fragmenty kodu i odpowiednio je ponownie pakuj.
Wysoka spójność i niskie sprzężenia.
Drugim podejściem jest wyszukanie elementów kodu, które mają wysoką spójność nawzajem i niskie sprzężenie z innymi częściami kodu. W istocie wysoka spójność oznacza utrzymanie części bazy kodu, które są ze sobą powiązane w jednym miejscu. W tym samym czasie niskie sprzężenie polega na rozdzieleniu niepowiązanych części podstawy kodu tak bardzo, jak to możliwe.
Indywidualny cykl życia.
Poszukaj części kodu, które mają podobny cykl życia, który można wdrożyć i wydać osobno. Jeśli oddzielny zespół może obsługiwać ten kod, jest to dobry wskaźnik, że można go przygotować jako komponent zewnętrzny poza rozwiązaniem.
Stabilne części.
Niektóre części bazy kodu mogą być stabilne i zmieniane rzadko. Sprawdź repozytorium kodu, aby znaleźć kod o niskiej częstotliwości zmiany.
Niezależny kod i składniki.
Za każdym razem, gdy kod i składniki są niezależne i niepowiązane z innymi częściami systemu, można je potencjalnie odizolować do oddzielnych zależności.
Możesz użyć różnych narzędzi, aby ułatwić skanowanie i badanie bazy kodu. Przykłady obejmują narzędzia, które skanują pod kątem zduplikowanego kodu i rysują wykresy zależności rozwiązania do narzędzi, które mogą obliczyć metryki w celu sprzężenia i spójności.
Jakie rodzaje pakietów są dostępne?
Każdy język programowania lub struktura zapewnia swój własny sposób tworzenia pakietów. Popularne systemy pakietów zawierają dokumentację dotyczącą sposobu działania procesu.
Być może znasz już te popularne systemy pakietów:
- NuGet: pakiety bibliotek .NET
- NPM: pakiety bibliotek JavaScript
- Maven: pakiety bibliotek Java
- Docker: pakiety oprogramowania w izolowanych jednostkach nazywanych kontenerami
Gdzie są hostowane pakiety?
Pakiety można hostować we własnej sieci lub użyć usługi hostingu. Usługa hostingu jest często nazywana repozytorium pakietów lub rejestrem pakietów. Wiele z tych usług zapewnia bezpłatny hosting dla projektów open source.
Oto kilka popularnych usług hostingowych dla typów pakietów, które właśnie opisaliśmy:
-
Pakiety NuGet są używane na potrzeby artefaktów kodu platformy .NET. Te artefakty obejmują zestawy .NET i powiązane pliki, narzędzia, a czasami metadane. NuGet definiuje sposób tworzenia, przechowywania i używania pakietów. Pakiet NuGet jest zasadniczo skompresowaną strukturą folderów z plikami w formacie ZIP i ma rozszerzenie nupkg .
-
Pakiet NPM jest używany dla języka JavaScript. Pakiet NPM to plik lub folder zawierający pliki JavaScript i plik package.json opisujący metadane pakietu. W przypadku node.js pakiet zwykle zawiera jeden lub więcej modułów, które można załadować po użyciu pakietu.
-
Narzędzie Maven jest używane w projektach opartych na języku Java. Każdy pakiet ma plik Project Object Model opisujący metadane projektu i jest podstawową jednostką do definiowania pakietu i pracy z nim.
-
Pakiety platformy Docker są nazywane obrazami i zawierają kompletne, samodzielne wdrożenia. Najczęściej obraz platformy Docker reprezentuje składnik oprogramowania, który może być hostowany i uruchamiany samodzielnie, bez żadnych zależności od innych obrazów. Obrazy platformy Docker są warstwowe i mogą być zależne od innych obrazów.
Źródło danych pakietów odwołuje się do serwera repozytorium pakietów. Ten serwer może znajdować się w Internecie lub za zaporą w sieci. Możesz na przykład hostować własne źródła danych NuGet przy użyciu produktów hostingowych, takich jak Azure Artifacts i MyGet. Możesz również hostować pakiety w udziale plików.
Hostowanie pakietów za zaporą umożliwia dołączanie źródeł danych do własnych pakietów. Możesz również buforować pakiety zaufane w sieci, gdy systemy nie mogą łączyć się z Internetem.
Jakie elementy tworzą dobrą strategię zarządzania zależnościami?
Dobra strategia zarządzania zależnościami zależy od tych trzech elementów:
Standaryzacja.
Standaryzacja sposobu deklarowania i rozwiązywania zależności ułatwia powtarzalny i przewidywalny zautomatyzowany proces wydawania.
Formaty i źródła pakietów.
Każda zależność powinna być spakowana przy użyciu odpowiedniego formatu i przechowywana w centralnej lokalizacji.
Wersjonowanie.
Należy śledzić zmiany występujące w czasie w zależnościach, podobnie jak w przypadku własnego kodu. Oznacza to, że zależności powinny być wersjonowane.
Kto ma dostęp do pakietów?
Wiele źródeł pakietów zapewnia nieograniczony dostęp do pakietów. Możesz na przykład pobrać Json.NET z nuget.org bez konieczności logowania się lub uwierzytelniania.
Inne źródła danych pakietów wymagają uwierzytelniania. Dostęp do źródła danych można uwierzytelnić na kilka sposobów. Na przykład niektóre kanały wymagają nazwy użytkownika i hasła. Inne kanały informacyjne wymagają tokenu dostępu, który jest zazwyczaj długą serią znaków określających, kim jesteś i do jakich zasobów masz dostęp. Tokeny dostępu można ustawić tak, aby wygasały po danym okresie.
W jaki sposób określane są wersje pakietów?
Schemat wersjonowania zależy od używanego systemu tworzenia pakietów.
Na przykład pakiety NuGet używają semantycznego przechowywania wersji.
Wersjonowanie semantyczne jest popularnym schematem wersjonowania. Format jest następujący:
Major.Minor.Patch[-sufiks]
Oto, co oznacza każdy z tych parametrów:
- Nowa wersja główna wprowadza zmiany powodujące niezgodność. Aplikacje zazwyczaj muszą aktualizować sposób używania pakietu do pracy z nową wersją główną.
- Nowa wersja pomocnicza wprowadza nowe funkcje, ale jest zgodna z poprzednimi wersjami.
- Nowa poprawka wprowadza poprawki błędów zgodne z poprzednimi wersjami, ale nie nowe funkcje.
- Część -Sufiks jest opcjonalna i identyfikuje pakiet jako wersję wstępną. Na przykład 1.0.0.0-beta1 może zidentyfikować pakiet jako pierwszą kompilację wersji wstępnej w wersji beta dla wersji 1.0.0.
Odwołanie do pakietu powinno zawierać numer wersji.
Oto przykład instalowania pakietu przy użyciu programu PowerShell i określonego numeru wersji:
Install-Package Newtonsoft.Json -Version 13.0.1
Co się stanie w przypadku zmiany pakietu?
Gdy odwołujesz się do pakietu z aplikacji, zazwyczaj przypinasz lub określasz wersję pakietu, której chcesz używać.
Wiele platform umożliwia określenie dozwolonych zakresów wersji pakietów do zainstalowania. Niektóre umożliwiają również określenie symboli wieloznacznych, które nazywamy zmienną wersją.
Na przykład w pakiecie NuGet wersja 1.0 oznacza pierwszą wersję równą lub większą niż 1.0. [1.0] określa, że dozwolona jest instalacja tylko wersji 1.0, ale nie nowszych wersji.
Oto kilka innych przykładów:
| Notacja: | Wybór: |
|---|---|
| (1.0,) | Pierwsza wersja większa niż 1 |
| [1.0,2.0] | Pierwsza wersja, która jest większa lub równa 1.0, i mniejsza niż lub równa 2.0 |
| (1.0,2.0) | Pierwsza wersja większa niż 1.0 i mniejsza niż 2.0 |
| [1.0,2.0) | Pierwsza wersja, która jest większa lub równa 1.0, i mniejsza niż 2.0 |
Gdy każdy z opiekunów wyda nową wersję pakietu, możesz ocenić zmiany i przetestować aplikację. Gdy wszystko będzie gotowe, możesz zaktualizować numer wersji pakietu w konfiguracji i przesłać zmianę do potoku kompilacji.
Oto przykład sposobu uwzględnienia pakietu Newtonsoft.Json w projekcie aplikacji C# (csproj). W tym przykładzie określono wersję 13.0.1 tego pakietu:
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
</ItemGroup>