Projektowanie podstaw samoobsługi dla deweloperów

Po zrozumieniu celu systemów inżynieryjnych możesz utworzyć bardziej zaawansowane środowiska samoobsługowe dla deweloperów. Środowisko samoobsługowe dla deweloperów opiera się na podstawach pojęć, wzorców i składników.

Chociaż obecnie nie potrzebujesz wszystkiego opisanego w twojej organizacji, należy pamiętać o tych pojęciach, jeśli tworzysz coś niestandardowego lub oceniasz powiązane produkty. Model samoobsługowego środowiska dla deweloperów może składać się z kombinacji produktów typu home-grown, off-the-shelf i open-source. Produkty lub zestawy narzędzi portalu open source, takie jak Backstage.io , mogą używać różnych terminów dla niektórych elementów modelu opisanych poniżej, ale model nadal może pomóc w zorientowaniu.

Automatyzowanie przepływów pracy, agregowanie danych, uruchamianie proste i stopniowe rozwijanie

Twoim celem jest włączenie samoobsługi z barierami zabezpieczającymi poprzez kontrolowane, zarządzane wykonywanie zadań i aprowizację wraz ze scentralizowaną widocznością. Obszary, które są najcenniejsze, aby skupić się na tych, które są żmudne lub są rzeczy, których deweloper nie może zrobić ze względu na złożoność lub uprawnienia. Ten ostatni element jest ważny, aby umożliwić przestrzeganie zasady najniższych uprawnień bez zmuszania deweloperów do ręcznego procesu pomocy technicznej.

Chociaż możesz rozszerzyć pakiet DevOps w celu spełnienia tych potrzeb, prawdopodobnie trzeba będzie obsługiwać wiele platform aplikacji w czasie, a także konkretne narzędzia i procesy, które je obsługują, również będą musiały ulec zmianie. Podstawowym problemem jest to, że standardy są ruchomym celem. Jak stwierdził jeden z praktyków inżynierów platformy:

Trudności obejmują standaryzację ... i radzenie sobie z "porzuconym oprogramowaniem"... Standaryzacja nie jest często osiągana z powodu potencjalnych zakłóceń zautomatyzowanych procesów i czasochłonnego zadania identyfikowania niezbędnych zmian. - Martin, inżynier DevOps, duża firma logistyczna

Szybkie przełączanie do nowego lub zaktualizowanego standardu zwykle nie jest możliwe, a porzucenie istniejących procesów stwarza ryzyko. Twoja organizacja może już używać wielu zestawów DevOps lub różnych kombinacji poszczególnych narzędzi i usług deweloperskich według scenariusza. Nawet w przypadku centralnego zespołu i standardowego rozwiązania, w miarę wzrostu potrzeb samoobsługi zmienność jest nieunikniona. Dlatego należy włączyć kontrolowane eksperymenty, w których wyznaczone zespoły mogą wypróbować nowe technologie, strategie wdrażania itd., a następnie celowe wdrożenie i wdrożenie przyrostowe.

Ogólnie rzecz biorąc, środowiska samoobsługowe należą do dwóch podstawowych kategorii: automatyzacji i agregacji danych.

Chociaż agregacja danych tworzy dobre środowiska użytkownika, automatyzacja jest ważniejsza:

Automatyzacja jest kluczem i będzie kochana przez wszystkich. Agregacja [Dane] jest pomocnicza. – Peter, lider inżynierii platformy, międzynarodowa firma technologiczna

W podróży inżynieryjnej platformy zidentyfikowano potencjalnie problemy rozwiązane przez automatyzację. Poza zmniejszeniem obciążenia poznawczego i trudem dewelopera automatyzacja może również pomóc w zapewnieniu, że aplikacje są połączone z najlepszymi narzędziami i usługami dla operacji, zabezpieczeń i innych ról do wykonywania swojej pracy.

Jeśli jednak pracujesz z więcej niż jednym systemem w celu zwiększenia automatyzacji, pewien poziom agregacji danych jest przydatny do śledzenia zautomatyzowanych żądań i skojarzonych wyników. Możesz zacząć od połączenia z systemami zewnętrznymi, aby spełnić inne potrzeby lub szczegółowe informacje. Agregacja i widoczność danych jest również ważna dla inspekcji, ładu i zmniejszenia strat (na przykład: nieużywane środowiska).

Automatyzacja takich czynności jak aprowizowanie infrastruktury może odbywać się przy użyciu integracji systemu, ale można również wyzwalać i ułatwiać ręczny proces przepływu pracy, który wygląda automatycznie dla dewelopera. Jest to przydatne na wczesnym etapie platformy, w przypadku nowych produktów, które wprowadzasz do ekosystemu, lub w obszarach, których nie masz lub nie można zautomatyzować przy użyciu systemu (na przykład przypisania licencji na oprogramowanie). Dzięki właściwemu projektowi możesz rozpocząć od ręcznego procesu obsługiwanego przez usługę Power Automate, którą można przełączyć do w pełni zautomatyzowanego przepływu w czasie. Dlatego projektowanie automatyzacji od samego początku.

Zacznij od ponownego korzystania z istniejących inwestycji, takich jak systemy inżynieryjne lub portal wewnętrzny, a następnie tworzenie interfejsów CLI, podstawowych stron internetowych, a nawet stron usługi Power Pages, usługi Power BI lub pulpitów nawigacyjnych usługi Microsoft Fabric i rozszerzanie się w miarę pojawiania się potrzeby. Posiadanie spójnego interfejsu API używanego przez środowisko użytkownika może pomóc w obsłudze wielu interfejsów w miarę zmian potrzeb i preferencji.

Składniki samoobsługowej platformy dla deweloperów: interfejs API, graf, orkiestrator, dostawcy i metadane

Rozważ podstawy samoobsługi deweloperów:

Jak pokazano na ilustracji, następujące składniki składają się na rdzeń koncepcji podstaw samoobsługi dewelopera:

Składnik	opis
Interfejs API platformy deweloperów	Jest to pojedynczy punkt kontaktu dla środowisk użytkownika. Jest to skutecznie umowa systemu z innymi systemami.
Wykres platformy deweloperów	Zarządzany i bezpieczny wykres danych, który umożliwia odnajdywanie, kojarzenie i używanie różnych rodzajów jednostek i szablonów. Jednostka jest obiektem, który umożliwia agregację danych z wielu źródeł, a szablony napędzają dane wejściowe użytkownika, które umożliwiają automatyzację.
Orkiestrator platformy deweloperów	Możliwość kierowania i kierowania żądań opartych na szablonach w celu wykonywania akcji w systemie lub przez proces ręczny. Te żądania są kierowane do jednego z zestawów dostawców platformy deweloperów, którzy mogą integrować się z dowolną liczbą różnych systemów przepływu pracy lub innych usług.
Dostawcy platformy deweloperów	Zestaw składników, które hermetyzują logikę potrzebną do integracji z systemami podrzędnymi w celu obsługi operacji CRUD na jednostkach i/lub realizacji żądań akcji opartych na szablonach. Każdy dostawca może obsługiwać własny określony typ szablonów i emitować unikatowe lub typowe typy jednostek.
Metadane profilu użytkownika i zespołu	Możliwość utrwalania informacji o zestawie osób powiązanych z zespołem koncepcyjnym umożliwiającym grupowanie i dostęp do interfejsu API platformy deweloperów. Użytkownik jest ściśle skojarzony z kontem dostawcy tożsamości (na przykład logowaniem microsoft Entra ID), ale zarówno on, jak i zespół mogą powiązać dowolną liczbę powiązanych reprezentacji systemu podrzędnego. Jedną z implementacji tego magazynu informacji jest ponowne użycie grafu platformy deweloperów. Podstawy samoobsługi dewelopera mogą ustanowić wspólny typ jednostki zarówno dla użytkownika, jak i zespołu, i utrwalać te informacje na grafie. Jednak zachowamy ten sklep oddzielnie ze względu na jasność tutaj.

Te podstawowe składniki umożliwiają używanie i zamianę różnych bloków konstrukcyjnych w czasie.

Czy muszę utworzyć wszystko, aby rozpocząć pracę?

L.p. Po pierwsze, jest to model koncepcyjny, który pomoże Ci zastanowić się, jak fundament powinien być w stanie wykonać po zakończeniu. Po drugie, specyfika implementacji jest mniej ważna, ponieważ interfejs API platformy deweloperów staje się twoim kluczowym interfejsem. Początkowa implementacja może rozpocząć korzystanie z interfejsów i klas w kodzie dla różnych warstw opisanych lub mieszanych w innych produktach. Możesz również pominąć aspekty, ponieważ programowanie klientów informuje o tym, że jest to po prostu niższy priorytet. Zacznij od tego, co masz i rozwijasz.

Interfejs API platformy deweloperów

Należy zdefiniować interfejs API platformy deweloperskiej, który będzie działać jako kontrakt systemu. Interfejs API jest używany przez różne interfejsy użytkownika w celu umożliwienia dostępu do danych lub inicjowania obsługi administracyjnej oraz innych akcji.

Ten interfejs API działa jako ważna warstwa uwierzytelniania i zabezpieczeń, ograniczając dostęp do pierwotnych bazowych interfejsów API w innych systemach do bardziej szczegółowych, kontrolowanych danych i operacji. Interfejs API zapewnia dostęp do własnej reprezentacji profilu użytkownika, roli wysokiego poziomu użytkownika w ramach platformy (członka zespołu, administratora itp.) i identyfikatorów systemu podstawowego dostawcy tożsamości. Aby uzyskać więcej informacji, zobacz Użytkownicy i zespoły.

Dostawcy platformy deweloperów

Biorąc pod uwagę szerokość wewnętrznej platformy deweloperów, utwórz lub zidentyfikuj systemy, które są zgodne z rozszerzalnym modelem dostawcy, aby wprowadzić funkcje do interfejsu API. Chodzi o to, że kluczowe funkcje, takie jak automatyzacja i agregacja danych, są udostępniane przez interakcję ze składnikami podłączonymi z dobrze zdefiniowanymi interfejsami. To luźne sprzężenie pomaga w przewodach, które są potrzebne przyrostowo i zwiększa łatwość konserwacji, ponieważ można testować funkcje niezależne od reszty podstawy.

Jest to również ważny sposób, aby umożliwić skalowalną mentalność źródła wewnętrznego dla platformy. Zazwyczaj wewnętrzne wysiłki związane z pozyskiwaniem zasobów w zakresie inżynierii platformy nie mogą uzyskać trakcji ze względu na wyzwania związane z ciągłą konserwacją. Inne zespoły mogą być skłonne do współtworzenia funkcji, ale są mniej skłonne do utrzymania i testowania czegoś wewnątrz platformy. Z drugiej strony każdy scentralizowany zespół ma ograniczoną pojemność do obsługi współtworzynego kodu, a nawet przeglądania żądań ściągnięcia. Koncepcja dostawcy platformy deweloperów złagodzi to napięcie, umożliwiając niezależne pisanie kodu "podłączanie" do podstawowych funkcji w ramach samoobsługi dewelopera. Mimo że należy dokładnie zarządzać dostawcami, których używasz, przejrzeć dowolny kod dostawcy i ograniczyć obszar powierzchni, do którego dany dostawca może uzyskać dostęp na platformie deweloperów, wtyczkowe podejście może pomóc w korzystaniu z większej liczby czynności przez skalowanie nakładu pracy w szerszej części organizacji.

Kluczowe pojęcia dotyczące dostawcy platformy deweloperów

Jednostki

Pojęcie jednostki jest czymś, co deweloper lub inny system na wewnętrznej platformie deweloperów musi śledzić, aktualizować, prezentować lub podejmować działania. Jednostki mogą mieć relacje ze sobą, które w połączeniu tworzą graf zawierający krytyczne informacje o elementach wewnętrznej platformy deweloperów. Dostawcy platformy deweloperów mogą następnie wyświetlać jednostki wyjściowe, aby umożliwić korzystanie z podstawowych funkcji, w tym:

• Udostępnianie zewnętrznie aprowiowanych zasobów/środowisk lub dostępnych interfejsów API na potrzeby odnajdywania i używania
• Uwidacznianie relacji na potrzeby analizy zależności, analizy wpływu, odnajdywania itp.
• Informacje o zachowaniu/własności na potrzeby odnajdywania i współpracy
• Uzyskiwanie większej ilości danych do użycia w środowiskach użytkownika

Hermetyzowanie tej funkcji w dobrze zdefiniowanym interfejsie dostawcy platformy deweloperów upraszcza integrację i testowanie, umożliwia niezależne wdrażanie i umożliwia deweloperom spoza podstawowego wewnętrznego zespołu platformy deweloperów współtworzenie dostawców i zarządzanie nimi. Jest to ważne w dużych lub dzielnych organizacjach, w których nie wszystkie narzędzia, usługi lub platformy są zarządzane centralnie, ale szersza organizacja nadal chce udostępniać możliwości. Tak więc, nawet jeśli nie udać się w dół tej ścieżki początkowo, jest to coś, o czym należy myśleć w dłuższej perspektywie.

Wspólne właściwości

Każda jednostka powinna mieć zestaw wspólnych właściwości, aby umożliwić fundacji zarządzanie nimi. Niektóre właściwości, które należy wziąć pod uwagę, obejmują:

• Unikatowy identyfikator
• Nazwisko
• Dostawca źródłowy
• Opcjonalne skojarzenia:
  • Użytkownik będący właścicielem
  • Zespół właścicieli
  • Inne jednostki

Właściwości użytkownika i zespołu są ważne z trzech powodów: kontrola dostępu oparta na rolach (RBAC), odnajdywanie i agregacja danych (na przykład podsumowania na poziomie zespołu). Tworzenie kontroli dostępu opartej na rolach od początku ma kluczowe znaczenie dla zabezpieczeń i rozwoju wewnętrznej platformy deweloperów w czasie. Biorąc pod uwagę rozwój jest sportem zespołowym, odkrywając, kto rozmawia o jednostce, szybko stanie się krytyczny dla ponownego użycia, wsparcia i wewnętrznej jednostki.

Typowe i specyficzne dla dostawcy jednostki

Powinno być również możliwe ustanowienie zestawu typowych, znormalizowanych jednostek wysokiego poziomu, które mogą wyprowadzać wielu dostawców. Na przykład:

• Środowiska
• Zasoby
• Interfejsy API
• Repozytoria
• Składniki
• Narzędzia

Zazwyczaj powinny one znajdować się na wysokim poziomie, tak jak w kontekście modelu C4 lub na większości diagramów składników wysokiego poziomu. Na przykład w przypadku środowiska nie trzeba uwzględniać szczegółów topografii infrastruktury wewnętrznej: wystarczy uzyskać wystarczające informacje, aby wyświetlić listę i skojarzyć różne środowiska koncepcyjne od wielu dostawców w tym samym środowisku użytkownika. Jednostka może wskazywać niższe poziomy szczegółów poza systemem, zamiast próbować korzystać ze wszystkiego. Zapewniają one punkty początkowe odnajdywania, które są kluczowe w celu umożliwienia agregacji danych w czasie.

Inne będą specyficzne dla konkretnego przypadku użycia lub dostawcy, więc należy zastanowić się, jak można uwzględnić rosnący zestaw typów jednostek w czasie.

Szablony

Koncepcja szablonu w tym kontekście różni się od idei jednostek, które mają na celu podjęcie akcji. Przykładowe scenariusze obejmują aprowizowanie infrastruktury, tworzenie repozytorium i inne długotrwałe procesy. Te szablony powinny być również dostępne za pośrednictwem rozszerzalnych dostawców platformy deweloperów i powinny obsługiwać te same wspólne właściwości co jednostki — w tym skojarzenia jednostek.

Mogą jednak również definiować wymagane dane wejściowe, niezależnie od tego, czy określono system, czy użytkownik, które są potrzebne do wykonania akcji. Mogą one obejmować różne elementy, takie jak nazewnictwo zasobu do opcjonalnych dodatków.

Przykłady szablonów obejmują:

• Szablony infrastruktury jako kodu (IaC)
• Szablony aplikacji (początek po prawej) lub repozytoria szablonów
• Tworzenie potoku/szablonów przepływu pracy
• Potok wdrażania/ szablony przepływów pracy
• Skrypty sparametryzowane
• Sparametryzowane przepływy usługi Power Automate (na przykład: przepływ wyzwolony przez żądanie HTTP w chmurze)
• Szablony wiadomości e-mail

Podobnie jak jednostki, szablony mogą zawierać właściwości specyficzne dla dostawcy.

Każdy szablon może mieć inną reprezentację unikatową dla dostawcy. Mogą one dotyczyć narzędzi Terraform lub ARM, wykresów helm, sparametryzowanych przepływów pracy funkcji GitHub Actions lub usługi Azure Pipelines, prostych skryptów lub formatów niestandardowych.

Rzeczywiste szczegóły szablonu bazowego nie muszą być przechowywane centralnie. Mogą istnieć w różnych repozytoriach, rejestrach lub katalogach. Można na przykład użyć repozytoriów szablonów usługi GitHub dla szablonów aplikacji, podczas gdy szablony IaC mogą istnieć w repozytorium katalogu z ograniczeniami, do którego deweloperzy mogą uzyskiwać dostęp tylko pośrednio za pośrednictwem środowiska wdrażania platformy Azure. Inne szablony IaC mogą być przechowywane w rejestrze artefaktów OCI, takich jak wykresy helm. W innych przypadkach szablon może być odwołaniem do sparametryzowanego punktu końcowego HTTP. Dostawca platformy deweloperów powinien podać wystarczającą ilość informacji o każdym typie szablonu, aby można było do nich odwoływać się, oraz wszelkie opcje udostępniane do użycia w środowiskach użytkownika. Jednak szablony można samodzielnie pomieścić w najbardziej naturalnej lokalizacji dla Twoich przypadków użycia.

Inżynierowie platformy lub eksperci w określonym obszarze piszą szablony, a następnie udostępniają je zespołom deweloperów w celu ponownego użycia. Scentralizowanie korzystania z tych szablonów za pomocą systemu umożliwia samoobsługowe korzystanie z deweloperów i tworzenie barier zabezpieczających, które pomagają wymuszać zgodność ze standardami organizacyjnymi lub zasadami. Więcej na ten temat, gdy nieco omówimy orkiestrator platformy deweloperów.

Wykres platformy dewelopera

Wykres platformy deweloperów można traktować jako coś, co pozwala na kojarzenie jednostek i szablonów z wielu dostawców do grafu z możliwością wyszukiwania. Jednak rzeczywiste dane jednostek nie muszą być utrwalane bezpośrednio w grafowej bazie danych. Zamiast tego interakcje z dostawcami mogą być buforowane wraz z wymaganymi metadanymi, aby wszystko pasowało do siebie.

Wykres jest zaawansowany w przypadku użycia z typowymi jednostkami, które mogą współtworzyć wielu dostawców. Na przykład lista interfejsów API może pochodzić z produktu, takiego jak Centrum interfejsów API platformy Azure, ale możesz również chcieć automatycznie podawać źródła danych we wdrożeniach i środowiskach z systemów ciągłego wdrażania. W czasie można przełączać się między różnymi systemami wdrażania, a nawet obsługiwać więcej niż jeden system wdrażania. Tak długo, jak każdy system wdrażania ma dostawcę platformy deweloperów, nadal powinno być możliwe skojarzenie.

Każde środowisko użytkownika, które kompiluje się na podstawie tego grafu, może następnie korzystać z wspólnego interfejsu API do odnajdywania, wyszukiwania, zapewniania ładu i nie tylko. Orkiestrator platformy deweloperów może następnie skorzystać z tego samego grafu, aby wszystkie akcje wykonywane przez dostawcę platformy deweloperów automatycznie współtworzyły jednostki dostępne dla tego samego interfejsu API.

Orkiestrator platformy deweloperów

Orkiestrator platformy deweloperów umożliwia deweloperom lub systemom tworzenie żądań wykonania akcji przy użyciu szablonu. Nie wykonuje tych akcji, ale zamiast tego koordynuje się z aparatem zadań, aparatem przepływu pracy lub innym orkiestratorem, aby to zrobić. Jest to jeden z krytycznych elementów, które chcesz mieć pewność, że jest częścią samoobsługowej podstawy. Umożliwia deweloperom tworzenie żądań za pomocą szablonu lub wykonywanie akcji bez bezpośredniego uprawnienia. Ponadto, w przeciwieństwie do koncepcji ciągłej integracji lub ciągłego wdrażania, te akcje nie muszą być powiązane z kodem źródłowym aplikacji.

Możesz użyć funkcji GitHub Actions, usługi Azure Pipelines lub innego aparatu przepływu pracy jako koordynatora. Jest to rozsądne miejsce do rozpoczęcia, ale warto mieć trochę abstrakcji, aby umożliwić różnym typom szablonów korzystanie z różnych aparatów bazowych. Może to być przydatne z kilku powodów:

• Po pierwsze, prawdopodobnie będzie można wybrać różne aparaty przepływu pracy i wykonywania zadań w czasie bez konieczności flashowania cięcia. Zezwalając na więcej niż jeden aparat, można przeprowadzić migrację w czasie lub po prostu użyć nowego aparatu do nowych akcji bez wpływu na starsze.
• Niektóre procesy, które chcesz pomóc w organizowaniu, mogą wymagać ręcznych kroków, nawet jeśli planujesz je w pełni zautomatyzować później.
• Inne akcje mogą kierować role spoza zespołu deweloperskiego, takie jak konta płatne lub administrator licencji. Aparaty z małą ilością kodu, takie jak Power Automate, często działają dobrze dla tych ról.
• Inne akcje mogą być obsługiwane za pośrednictwem prostych żądań HTTP, w których tworzenie czegoś tak zdolnego, jak funkcja GitHub Actions lub usługa Azure Pipelines , nie jest konieczne ani opłacalne do skalowania.

Na szczęście rozszerzenie pomysłu dostawcy platformy deweloperów na pokrycie wyzwalania i śledzenia kroków automatyzacji może zapewnić tę wymaganą abstrakcję. Rozważmy następującą ilustrację:

Poniżej przedstawiono ogólną koncepcję:

• Szablony mogą opcjonalnie określać zestaw danych wejściowych, które użytkownik może wprowadzić. Gdy deweloper wyzwoli określoną akcję, wybierze szablon (nawet jeśli nie został opisany w ten sposób) i wprowadzi wszelkie dane wejściowe.
• Odwołanie do danych wejściowych powiązanych z szablonem staje się żądaniem w interfejsie API platformy deweloperów.
• Po przesłaniu żądania składnik routingu i obsługi żądań w orkiestratorze rozpoczyna śledzenie cyklu życia żądania. Szablon routingu żądań i obsługi tras składników w żądaniu do dostawcy platformy dewelopera, z którego pochodzi szablon.
• Następnie dostawca platformy deweloperów wykona odpowiednie kroki dla jego implementacji.
• (Opcjonalnie) Dostawca platformy deweloperów aktualizuje stan żądania podczas wykonywania akcji.
• Po spełnieniu żądania dostawca platformy deweloperów może zwrócić zestaw jednostek w celu dodania/zaktualizowania w grafie platformy deweloperów. Mogą to być specyficzne dla dostawcy lub typowe jednostki.

Opcjonalnie, aby obsługiwać bardziej zaawansowane interakcje, dostawcy platformy deweloperów mogą wywoływać interfejs API platformy deweloperów bezpośrednio, aby uzyskać więcej jednostek jako dane wejściowe, a nawet zażądać innej powiązanej akcji.

Wybierz dostawcę platformy dewelopera, który używa ogólnego zadania lub aparatu przepływu pracy. W szczególności chcesz połączyć coś, co należy połączyć w ramach stosowania systemów inżynierii oprogramowania. Jednym z ogólnych aparatów przepływu pracy lub wykonywania zadań do inwestowania w program jest system ciągłej integracji/ciągłego wdrażania.

Przykład użycia funkcji GitHub Actions lub usługi Azure Pipelines

Przyjrzyjmy się krótko, jak działa usługa GitHub Actions lub Azure Pipelines jako dostawca platformy deweloperskiej.

W przypadku funkcji GitHub Actions kluczem do wykonania tej pracy jest to, że dostawca platformy deweloperskiej może nawiązać połączenie z określonym wystąpieniem usługi GitHub i użyć interfejsu API REST akcji, aby wyzwolić uruchomienie przepływu pracy . Każdy przepływ pracy może obsługiwać zestaw danych wejściowych, dodając konfigurację workflow_dispatch do pliku YAML przepływu pracy. Wyzwalacze usługi Azure DevOps są podobne i można również użyć interfejsu API potoku usługi Azure DevOps do uruchamiania. Prawdopodobnie zobaczysz te same możliwości w innych produktach.

Te przepływy pracy lub potoki nie muszą znajdować się w repozytoriach kodu źródłowego aplikacji. Koncepcja polegałaby na wykorzystaniu tego faktu, aby zrobić coś takiego:

• Inżynierowie platformy lub członkowie zespołu DevOps mogą obsługiwać przepływy pracy/potoki w co najmniej jednym centralnym repozytorium, do którego deweloperzy nie mają dostępu, ale dostawca platformy deweloperów jest skonfigurowany do użycia. To samo repozytorium może zawierać skrypty i fragmenty kodu IaC używane przez przepływy pracy/potoki.
• Aby zezwolić tym przepływom pracy/potokom na interakcję z odpowiednim systemem podrzędnym, ops lub innymi członkami zespołu inżynierów platformy może dodać potrzebne wpisy tajne w centralnym repozytorium. Zobacz dokumentację funkcji GitHub Actions i usługi Azure DevOps, aby uzyskać szczegółowe informacje na temat tego, jak to zrobić, lub możesz zdecydować się na scentralizowanie wpisów tajnych przy użyciu czegoś takiego jak usługa Azure Key Vault.
• Te przepływy pracy/potoki mogą następnie postępować zgodnie z modelem, w którym publikują wszystkie wynikowe jednostki jako artefakt kompilacji/wdrożenia (dokumentacja usługi GitHub, dokumentacja usługi Azure DevOps).
• Podczas uruchamiania dostawca platformy deweloperów może następnie obserwować stan przepływu pracy/potoku i aktualizować stan cyklu życia w orkiestratorze do momentu jego ukończenia. Możesz na przykład użyć elementów webhook z funkcją GitHub Actions i punktami zaczepienia usług za pomocą usługi Azure Pipelines , aby śledzić aktualizacje.
• Po zakończeniu dostawca może następnie korzystać z opublikowanego artefaktu do dołączenia do grafu platformy deweloperów zgodnie z potrzebami.

Na koniec możesz skonfigurować tego dostawcę platformy deweloperów, aby wyświetlić zestaw szablonów w grafie platformy deweloperów, który odwołuje się do odpowiedniego repozytorium i przepływu pracy/potoku, wraz z danymi wejściowymi dla danego zadania.

Doskonałym rozwiązaniem w przypadku korzystania z systemu ciągłej integracji/ciągłego wdrażania jest to, że są one często skonfigurowane do obsługi dowolnych interfejsów CLI, więc nie potrzebujesz pierwszej klasy, unikatowej integracji dla wszystkiego, co robisz. Można je dodawać w miarę potrzeb.

Większość tego, co zostało opisane w tym przykładzie, stosuje sposób działania innych typów dostawców. Należy również pamiętać, że użycie funkcji GitHub Actions lub usługi Azure Pipelines w tym kontekście nie wymaga również używania ich do rzeczywistych potoków ciągłej integracji/ciągłego wdrażania.

Inne przykłady

Oto kilka przykładów innych typów dostawców platformy deweloperów, którzy mogą przetwarzać szablony.

Przykład	opis
Operacje kontroli źródła	W niektórych przypadkach może być konieczne utworzenie lub zaktualizowanie repozytorium, przesłanie żądania ściągnięcia lub wykonanie innej innej operacji związanej z kontrolą źródła. Chociaż ogólne aparaty asynchronicznych przepływów pracy mogą zarządzać tego rodzaju operacjami, możliwość wykonywania podstawowych operacji usługi Git bez ich użycia może być przydatna.
Aprowizatory infrastruktury	Chociaż usługi GitHub Actions i Azure Pipelines dobrze sprawdzają się w zarządzaniu aprowizacją infrastruktury, możesz również wybrać bardziej bezpośrednie integracje. Dedykowany dostawca może usprawnić konfigurację i uniknąć narzutów. Usługi, takie jak Środowiska wdrażania platformy Azure lub Terraform Cloud , są bardziej bezpośrednio skoncentrowane na włączaniu aprowizacji opartej na szablonach IaC i bezpieczne i bezpieczne. Inne przykłady mogą obejmować takie elementy jak tworzenie przestrzeni nazw Kubernetes dla aplikacji w udostępnionych klastrach lub używanie usługi GitOps z przepływami pracy usługi GitOps przy użyciu usługi Flux lub Argo CD jako określonego typu dostawcy. Jeszcze więcej modeli skoncentrowanych na aplikacjach, takich jak eksperymentalny projekt inkubacji systemu operacyjnego Radius z własnymi interfejsami WIERSZA, może mieć własnych dostawców platform deweloperskich w czasie. Kluczową rzeczą jest wyszukanie i zaplanowanie rozszerzalności, aby można było dostosować się.
Tworzenie szkieletów aplikacji/rozmieszczanie	Szablony aplikacji są ważną częścią tego, gdzie inżynieria platformy prowadzi w czasie. Możesz obsługiwać wybrany aparat szablonów, udostępniając dedykowanego dostawcę platformy deweloperów, który jest przeznaczony nie tylko do tworzenia szkieletu drzewa źródłowego aplikacji, ale także tworzenia i wypychania zawartości do repozytorium kodu źródłowego i dodawania wynikowych jednostek do grafu. Każdy ekosystem ma własne preferencje tworzenia szkieletów aplikacji, niezależnie od tego, czy yeoman, cookiecutter, czy coś takiego jak interfejs wiersza polecenia dewelopera platformy Azure, więc model dostawcy w tym miejscu może umożliwić obsługę więcej niż jednego z tych samych interfejsów. Tutaj ponownie jest to rozszerzalność, która jest kluczem.
Procesy ręczne	Niezależnie od tego, czy automatyczne generowanie żądania ściągnięcia na potrzeby ręcznego zatwierdzania, czy ręcznego przepływu pracy dla osób niebędących deweloperami w odpowiedzi na użycie czegoś takiego jak platforma Power Platform, ten sam model oparty na szablonach może być używany w dostawcy platformy deweloperów. Możesz nawet przejść do bardziej zautomatyzowanych kroków w czasie.

Chociaż nie potrzebujesz wszystkich tych dostawców, aby rozpocząć, możesz zobaczyć, jak rozszerzalność za pośrednictwem czegoś takiego jak dostawca platformy deweloperów może pomóc w rozwoju możliwości automatyzacji w czasie.

Użytkownicy i zespoły

Inżynieria platformy jest z natury sprawą z wieloma systemami, dlatego ważne jest, aby zaplanować sposób, w jaki podstawy samoobsługi powinny obsługiwać trudniejsze problemy z integrowaniem tych systemów razem. Oto strategia rozwiązywania typowych wyzwań związanych z tożsamościami, użytkownikami i zespołami.

Zalecenie	opis
Integrowanie interfejsu API platformy deweloperów bezpośrednio z dostawcą tożsamości w celu uzyskania optymalnego bezpieczeństwa	Aby zabezpieczyć interfejs API platformy deweloperskiej, zalecamy bezpośrednią integrację z dostawcą tożsamości, na przykład Microsoft Entra ID, biorąc pod uwagę jego niezawodną tożsamość i możliwości kontroli dostępu opartej na rolach (RBAC) identyfikatora Entra. Istnieje wiele zalet bezpośredniego używania natywnych zestawów SDK i interfejsów API dostawcy tożsamości (na przykład za pośrednictwem identyfikatora entra biblioteki MSAL), a nie abstrakcji. Kompleksowe zabezpieczenia można zwiększyć i polegać na tym samym modelu kontroli dostępu opartej na rolach w całym czasie, zapewniając stałe ocenianie zasad dostępu warunkowego (w przeciwieństwie do tylko w momencie logowania).
Korzystanie z integracji grup dostawców tożsamości i logowania jednokrotnego w systemach podrzędnych	Integracje logowania jednokrotnego (SSO) powinny używać tego samego dostawcy tożsamości i dzierżawy, którego używasz dla interfejsu API platformy deweloperów. Pamiętaj również, aby korzystać z obsługi dowolnych protokołów, takich jak SCIM do komunikacji sieciowej w grupach dostawców tożsamości (takich jak grupy usługi AD). Wiązanie tych grup dostawców tożsamości z uprawnieniami systemu podrzędnego nie zawsze jest automatyczne, ale co najmniej można ręcznie skojarzyć grupy dostawców z pojęciami grupowania poszczególnych narzędzi bez ręcznego zarządzania członkostwem. Możesz na przykład połączyć obsługę enterprise user (EMU) w usłudze GitHub, a także ręcznie korzystać z możliwości łączenia grup dostawców tożsamości z zespołami usługi GitHub. Usługa Azure DevOps ma podobne możliwości.

Ustanawianie koncepcji zespołu poza pojedynczą grupą dostawców tożsamości

W miarę kontynuowania podróży inżynieryjnej platformy prawdopodobnie okaże się, że grupy dostawców tożsamości doskonale nadają się do zarządzania członkostwem, ale wiele grup naprawdę musi zebrać się w celu utworzenia koncepcji zespołu do kontroli dostępu opartej na rolach (RBAC) i agregacji danych.

W kontekście inżynierii platformy definiujemy zespół jako zestaw osób w różnych rolach, które współpracują ze sobą. W przypadku agregacji danych pomysł zespołu wielorolnego ma kluczowe znaczenie dla odnajdywania i wprowadzania informacji w miejscach, takich jak pulpity nawigacyjne raportowania. Z drugiej strony grupa jest ogólną koncepcją dostawcy tożsamości dla zestawu użytkowników i została zaprojektowana z myślą o dodawaniu wielu osób do określonej roli, a nie na odwrót. Dzięki kontroli dostępu opartej na rolach zespół może zatem odnosić się do wielu grup dostawców tożsamości za pomocą różnych ról.

Źródło danych zespołu może pochodzić z kilku różnych miejsc. Jeśli na przykład używasz zespołów jako wzorca kodu (TaC), dostawca platformy deweloperów może obserwować zmiany plików w repozytorium i buforować je w magazynie metadanych profilu użytkownika i zespołu. Możesz też zintegrować bezpośrednio z projektem usługi Azure Centrum deweloperów, który ma już dostępne podstawowe konstrukcje kontroli dostępu opartej na rolach.

Ustanawianie modelu integracji z systemami podrzędnymi na poziomie zespołu lub użytkownika

Chociaż niektóre narzędzia deweloperskie i operacyjne/usługi będą natywnie integrować i używać koncepcji dostawcy tożsamości bezpośrednio, wiele z nich wyodrębni je z własną reprezentacją grupy lub użytkownika (nawet z logowaniem jednokrotnym). Poza włączaniem dostępu między narzędziami ta rzeczywistość może również stanowić problemy z agregacją danych. W szczególności można stwierdzić, że interfejsy API w systemie podrzędnym używają własnych identyfikatorów, a nie identyfikatorów dostawcy tożsamości (na przykład identyfikator obiektu w identyfikatorze Entra nie jest bezpośrednio używany). Sprawia to, że filtrowanie i kojarzenie danych na poziomie użytkownika lub zespołu jest trudne, chyba że można mapować między różnymi identyfikatorami.

Różnice między zespołami i grupami

Wzorce, takie jak TaC , umożliwiają przechowywanie relacji między zespołem lub grupami poszczególnych systemów i uzyskiwanie do nich dostępu, dzięki czemu można je mapować. Aby podsumować, bezpieczne, poddawane inspekcji repozytorium Git staje się źródłem zespołu, a żądania ściągnięcia zapewniają kontrolowany interfejs użytkownika w celu wprowadzania aktualizacji. Systemy ciągłej integracji/ciągłego wdrażania mogą następnie aktualizować systemy podrzędne i utrwalać powiązane relacje identyfikatorów dla zespołu, który to zrobił.

Umożliwia to na przykład przechowywanie następujących relacji w wywołaniach interfejsu API:

Jeśli wolisz użyć źródła danych innego niż pliki w repozytorium Twoich zespołów, to samo ogólne pojęcie można zastosować za pomocą orkiestratora platformy deweloperów, aby osiągnąć to samo. W ramach tego modelu dostawca platformy deweloperów dla źródła danych zespołu może wyzwolić zdarzenie aktualizacji zespołu, które wszyscy inni dostawcy otrzymują i działają zgodnie z potrzebami.

Rozwiązywanie problemów z identyfikatorem użytkownika

Innym powiązanym wyzwaniem związanym z dostępem do danych i agregacją są różnice identyfikatorów użytkowników. Podobnie jak w przypadku zespołu, jeśli używasz integracji system-system do wysyłania zapytań dotyczących danych o użytkowniku, nie można założyć, że dostawcy tożsamości natywny identyfikator (na przykład identyfikator obiektu dla identyfikatora Entra) obsługuje dany interfejs API. W tym miejscu ponownie można przechowywać mapowanie identyfikatora użytkownika, który uzyskuje dostęp do danych za pośrednictwem interfejsu API platformy deweloperów. Rozważmy na przykład usługę GitHub:

W przypadku każdego systemu, jeśli możesz wyszukać identyfikator użytkownika inny system za pośrednictwem interfejsu API bez tokenu użytkownika, dany dostawca platformy deweloperów może wygenerować to mapowanie na bieżąco. W niektórych przypadkach może to być skomplikowane, ponieważ może być konieczne zbiorcze wykonanie tej operacji i buforowanie wyników w celu uzyskania odwołania do zachowania wydajności.

Powrót przy użyciu wielu tokenów użytkownika

W sytuacjach, w których dostawcy muszą uzyskiwać dostęp do danych na poziomie użytkownika bez możliwości tłumaczenia identyfikatora użytkownika, które działałoby, interfejs API platformy deweloperów można skonfigurować do zarządzania wieloma tokenami użytkowników. Na przykład:

• Interfejs API platformy deweloperów może obsługiwać pamięć podręczną tokenów użytkownika specyficznych dla dostawcy do użycia z systemami podrzędnymi.
• Wszelkie interakcje z danym dostawcą wyzwalane przez interfejs API będą uwzględniane w tokenie użytkownika dostawcy, jeśli jest dostępny.
• Aby obsłużyć przypadek, w którym nie jest dostępny token użytkownika, dostawca wyzwoli przepływ OAuth, aby go uzyskać.
• Aby rozpocząć, interfejs API platformy dewelopera przekaże identyfikator URI uwierzytelniania dla przepływu OAuth z identyfikatorem URI przekierowania przekazanym do dostawcy. Przekazany identyfikator URI będzie zawierać kod nieobsługiwalny/jednorazowy.
• Następnie interfejs API zwraca odpowiedź "nieuwierzytelnione" z identyfikatorem URI.
• Każdy interfejs użytkownika może następnie używać tego identyfikatora URI do napędzania odpowiedniego przepływu uwierzytelniania w przeglądarce.
• Po zakończeniu przekierowania platforma deweloperów otrzyma wymagany token użytkownika i będzie buforował go w celu uzyskania przyszłego odwołania wraz z identyfikatorem użytkownika.
• Klient może następnie ponowić próbę wywołania interfejsu API, co następnie powiedzie się.

W tej koncepcji opisano sposób radzenia sobie ze skomplikowanym uwierzytelnianiem, ponieważ można używać ponownie identyfikatorów tam, gdzie to możliwe, i nie trzeba utrzymywać oddzielnych identyfikatorów URI przekierowania na system podrzędny.

Używanie linków bezpośrednich obsługujących kontekst do narzędzi i systemów raportowania

Do tego momentu mówiliśmy o aspekcie automatyzacji przestrzeni problemu. Ten sam proces może trwać długo, ponieważ interfejs użytkownika może używać wartości w jednostkach zwracanych podczas automatyzacji, aby tworzyć głębokie linki do innych systemów dla zespołu.

Nawet jeśli nie są związane z automatyzacją, dostawcy platformy deweloperów mogą emitować wszelkiego rodzaju potrzeby jednostki. Jednak zazwyczaj nie chcesz wprowadzać wszystkich szczegółowych danych na całej wewnętrznej platformie deweloperów do wykresu platformy deweloperów. Pulpity nawigacyjne w rozwiązaniach do obserwacji, takich jak Grafana, Prometheus, DataDog lub analiza kodu w produktach, takich jak SonarQube, i możliwości natywne w pakietach DevOps, takich jak GitHub i Azure DevOps, są bardzo zdolne. Zamiast tego najlepszym rozwiązaniem jest często tworzenie głębokich powiązań z tymi innymi systemami. Jednostki mogą dostarczać wystarczające informacje, aby tworzyć linki bez bezpośredniego przechowywania szczegółowych informacji, takich jak zawartość dziennika.

W przypadku, gdy chcesz zagregować i podsumować dane między narzędziami lub użyć niestandardowych metryk, rozwiązania raportowania usługi Power BI lub usługi Microsoft Fabric mogą być następnym portem wywołania. Aby scalić dane zespołu, możesz nawiązać połączenie z bazą danych fundacji lub przejść przez interfejs API platformy deweloperskiej. Na przykład, zgodnie z opisem w temacie Planowanie i określanie priorytetów, jednym z miejsc, w których może być potrzebny niestandardowy pulpit nawigacyjny, jest mierzenie sukcesu wewnętrznej platformy deweloperów.

Bądź selektywny przy użyciu każdego dodatkowego środowiska, które tworzysz

Chociaż może to być atrakcyjne, aby ponownie utworzyć istniejące funkcje w podobny sposób do wspólnego portalu, należy również pamiętać, że należy je zachować. Jest to obszar, w którym ważne jest przestrzeganie myślenia o produkcie. Interfejsy stylu pulpitu nawigacyjnego są łatwe do zrozumienia, ale deweloperzy mogą znaleźć więcej wartości w innych miejscach.

Oznacza to, że model w tym miejscu umożliwia używanie zagregowanych danych w grafie platformy deweloperów do tworzenia niestandardowych środowisk użytkownika. Jednostki powinny mieć wbudowaną obsługę, aby mogły powiązać się z użytkownikiem lub zespołem. Dzięki temu interfejs API platformy dewelopera może określać zakres danych wyjściowych (wraz z użyciem indeksowania i buforowania).

Jednak nawet w przypadku konieczności utworzenia niestandardowego środowiska użytkownika, a nie linku głębokiego, ściąganie wszystkich danych do grafu platformy deweloperów zwykle nie jest najlepszym rozwiązaniem. Rozważmy na przykład sytuację, w której możesz wyświetlić dzienniki w środowisku użytkownika, które mają już dobrze zdefiniowany i zarządzany dom. Informacje w powiązanych jednostkach ułatwiają środowisku użytkownika zbieranie informacji bezpośrednio z systemów podrzędnych.

Aby rozpocząć, może być konieczne użycie integracji między systemami w celu nawiązania połączenia, ale po zaimplementowaniu jednego z modeli opisanych w aplikacjach i zespołach można użyć dowolnych przechowywanych identyfikatorów użytkowników podrzędnych/zespołu lub tokenów uwierzytelniania użytkownika w razie potrzeby.

Oto kilka przykładów typowych środowisk, które należy wziąć pod uwagę:

Przykład	opis
Odnajdywanie i odnajdywanie	Jak ujął to jeden z praktyk inżynierów platformy, "To, co spowalnia projekty, to komunikacja, a nie umiejętności deweloperskie". – Daniel, Inżynier chmury, Fortune 500 Media Company. Ponieważ oprogramowanie jest sportem zespołowym, tworzenie interfejsu użytkownika ułatwiającego odnajdywanie zespołów, a własne jednostki są zazwyczaj jedną z pierwszych rzeczy do rozwiązania. Wyszukiwanie między zespołami, odnajdywanie i dokumentacja ułatwiają promowanie ponownego użycia oraz pomoc w zakresie określania źródła wewnętrznego lub pomocy technicznej. Zespoły korzystają również z jednego sklepu, aby znaleźć rzeczy, które posiadają, w tym środowiska, repozytoria i inne zasoby, takie jak dokumenty.
Ręczna rejestracja środowisk lub zasobów	Chociaż wiele elementów można aprowizować i śledzić za pośrednictwem orkiestratora platformy deweloperów, możesz również zarejestrować zasoby lub środowiska, które już istnieją lub nie zostały jeszcze zautomatyzowane. Prosty dostawca, który pobiera informacje z repozytorium Git i dodaje informacje do zasobów/zarządzania środowiskiem, może być przydatny tutaj. Jeśli masz już katalog oprogramowania, stanie się to również sposobem zintegrowania go z modelem.
Wykaz interfejsów API	Śledzenie interfejsów API, których deweloperzy powinni używać, może przejść długą drogę. Jeśli nie masz jeszcze czegoś, możesz nawet zacząć od prostego repozytorium Git z serią plików reprezentujących interfejsy API, ich stan, użyć żądania ściągnięcia do zarządzania przepływem pracy zatwierdzania. Można je dodać do grafu platformy deweloperów, aby mogły być wyświetlane lub skojarzone z innymi jednostkami. Aby uzyskać bardziej niezawodne możliwości, możesz zintegrować coś takiego jak Centrum interfejsów API firmy Microsoft lub inny produkt.
Zgodność licencji	W niektórych przypadkach możesz również zapewnić wgląd w zgodność licencji oprogramowania i użycie licencji. Platformy deweloperskie mogą również dodać automatyzację wymaganą do korzystania z licencji, ale nawet jeśli licencje są przypisywane ręcznie (na przykład za pośrednictwem procesu żądania ściągnięcia w repozytorium Git), wgląd deweloperów w to, co mają (i możliwość wyświetlania przez administratora wszystkich elementów).
Widok skoncentrowany na aplikacji platformy Kubernetes	W przypadku korzystania z udostępnionego klastra Kubernetes deweloperzy mogą trudno znaleźć i zrozumieć stan swoich aplikacji za pośrednictwem środowiska użytkownika administratora klastra. Różne organizacje mogą zdecydować się na różne rozwiązanie tego problemu, ale użycie przestrzeni nazw do reprezentowania aplikacji jest jednym dobrze znanym sposobem, aby to zrobić. W tym miejscu można użyć jednostek do ustanowienia skojarzeń między przestrzenią nazw aplikacji w klastrze i zespołem oraz utworzyć bardziej skoncentrowany dla deweloperów widok stanu aplikacji i udostępnić szczegółowe linki do innych narzędzi lub internetowych interfejsów użytkownika.

Środowiska użytkownika

Różne role w organizacji mają narzędzia lub usługi, które reprezentują środek ciężkości ich codziennej pracy. Ściąganie tych systemów może utrudnić nowe środowisko użytkownika poza tymi centrami grawitacji, aby uzyskać przyczepność. W idealnym świecie deweloperzy, operacje i inne role mogą nadal pracować w środowisku, które ma dla nich sens — często tych, których już używają.

Mając to na uwadze, planowanie wielu interfejsów użytkownika w miarę postępu w podróży inżynieryjnej platformy jest dobrym pomysłem. Może to również stanowić okazję do rozpoczęcia prostych, udowodnienia wartości i zwiększania się w kierunku bardziej złożonych interfejsów w miarę pojawiania się potrzeby.

Integrowanie posiadanych danych

Jeśli zapoznasz się z artykułami Stosowanie systemów inżynierii oprogramowania i Uściślij platformę aplikacji, prawdopodobnie zidentyfikowano systemy, które chcesz nadal używać. W obu przypadkach oceń, czy możesz ulepszyć i rozszerzyć to, co masz przed rozpoczęciem tworzenia nowych środowisk od podstaw. (Zadaj sobie pytanie, czy ludzie będą lepiej reagować na inne nowe środowisko użytkownika lub ulepszoną wersję czegoś, co mają teraz?)

Niektóre narzędzia, narzędzia lub aplikacje internetowe, które chcesz nadal używać, będą niestandardowe i są to dobre kandydaty do ulepszenia. Nie zapomnij jednak zwrócić uwagi na to, czy ulubione narzędzia i usługi mają model rozszerzalności, którego można użyć. Otrzymasz wiele korzyści od rozpoczęcia. Może to wyeliminować bóle głowy związane z konserwacją i zabezpieczeniami oraz skupić się na problemie, który próbujesz rozwiązać

Na przykład możesz rozszerzyć następujące powierzchnie, których już używasz:

• Edytory i środowiska IDE.
• Pakiet DevOps.
• Interfejsy CLI są coraz bardziej rozszerzalne.
• Środowiska o niskim/braku kodu, takie jak Power Pages.

Każdy może zapewnić lepszy punkt wyjścia dla danej roli niż coś, co zostało skonfigurowane od podstaw, ponieważ są one istniejącymi centrami grawitacji. Posiadanie wspólnego interfejsu API platformy deweloperów jako punktu odniesienia umożliwi zamianę elementów, eksperymentów i zmian w czasie.

Rozważ użycie rozszerzeń edytora sieci Web w celu utworzenia portalu dla deweloperów

Jeśli szukasz środowiska internetowego dla deweloperów, pamiętaj, że niedawny trend to internetowe wersje edytorów i środowisk IDE. Wiele z nich, takich jak te korzystające z programu VS Code, ma obsługę rozszerzeń. Dzięki programowi VS Code wszystko, co tworzysz dla tych środowisk internetowych, a następnie przekłada się lokalnie na podwójną korzyść.

Poza usługami, takimi jak GitHub Codespaces, vscode.dev jest bezpłatną wersją internetową edytora programu VS Code bez obliczeń, ale obejmuje obsługę niektórych typów rozszerzeń , w tym tych, które korzystają z widoków internetowych dla niestandardowego interfejsu użytkownika.

Nawet jeśli deweloperzy nie używają samego programu VS Code, wzorce środowiska użytkownika są dobrze znane i można je znaleźć w innych narzędziach deweloperskich. Korzystanie z vscode.dev może zapewnić wygodną i znaną podstawę internetową dla środowisk deweloperskich oprócz samego narzędzia.

Mogą one działać jako portal skoncentrowany na deweloperach w znanej formie, która może również przełożyć się na użycie lokalne.

ChatOps

Kolejną możliwością, która jest często pomijana, jest implementacja interfejsu ChatOps. Biorąc pod uwagę wzrost liczby interfejsów opartych na czacie z powodu wzrostu produktów sztucznej inteligencji, takich jak ChatGPT i GitHub Copilot, polecenia akcji lub polecenia ukośnika mogą zapewnić przydatny sposób wyzwalania przepływów pracy automatyzacji, sprawdzania stanu i nie tylko. Ze względu na to, że większość platform ciągłej integracji/ciągłego wdrażania aplikacji obsługuje gotowe systemy, takie jak Microsoft Teams, Slack lub Discord, może to być naturalny sposób integracji z innymi deweloperami interfejsu użytkownika i powiązanymi rolami operacji używać każdego dnia. Ponadto wszystkie te produkty mają model rozszerzalności.

Inwestowanie w nowy portal deweloperów

Zakładając, że nie masz istniejącego portalu ani interfejsu, którego chcesz użyć jako podstawy, możesz zdecydować się na utworzenie nowego portalu deweloperów. Pomyśl o tym jako miejscu docelowym, a nie o punkcie wyjścia. Jeśli nie masz jeszcze zespołu programistycznego, zacznij od tego czasu. Każda organizacja jest inna, więc nie ma żadnej uniwersalnej odpowiedzi na to, co powinno być w tym rodzaju doświadczenia. W związku z tym nie ma odpowiedzi defacto dla wstępnie pakowanego produktu, który można spin up i używać as-is dla czegoś takiego dzisiaj.

W przypadku niestandardowych wbudowanych opcji self-hosted ogólne struktury portalu internetowego nie są nowe, a zespoły programistyczne mogą już korzystać z tej platformy, którą można wykorzystać. Jeśli próbujesz wydostać coś przed użytkownikami w celu uzyskania wczesnej opinii, możesz nawet zacząć od czegoś prostego, ponieważ usługa Power Pages o niskim kodzie łączy się z typowym interfejsem API platformy deweloperów.

Nowsze wysiłki portalu dla deweloperów są bardziej opiniowane. Na przykład Backstage.io to niestandardowy zestaw narzędzi portalu dla deweloperów, który początkowo został utworzony zgodnie z potrzebami Spotify. Zawiera interfejs wiersza polecenia, który ułatwia uruchamianie drzewa źródłowego, podobnie jak tworzenie aplikacji react-app dla React.js.

Jako zestaw narzędzi portalu wymaga to pracy w celu uzyskania wiedzy na temat języka TypeScript, Node.js i React. Jednak wielką rzeczą w tym jest to, że jako zestaw narzędzi można zmienić prawie wszystko. Ma również własny mechanizm katalogu oprogramowania i tworzenia szablonów, ale ich użycie nie jest wymagane i ma dobrze zdefiniowany sposób wprowadzenia nowego kodu 1^st i 3 rd party o nazwie wtyczki.

Powiązana zawartość

• Power Pages
• Backstage.io
• Stosowanie systemów inżynierii oprogramowania