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ługi dla deweloperów może składać się z kombinacji produktów wewnętrznie rozwijanych, gotowych do użycia 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 tutaj, ale model nadal może pomóc w zorientowaniu.

Automatyzuj przepływy pracy, agreguj dane, uruchom w prosty sposób i rozwijaj się stopniowo

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, na które warto zwrócić największą uwagę, to te, które są żmudne lub takie, których deweloper nie może wykonać ze względu na złożoność lub brak uprawnień. 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, aby zaspokoić te potrzeby, 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ż mogą wymagać zmian. Podstawowym problemem jest to, że standardy są ruchomym celem. Jak stwierdził jeden z praktyków inżynierii platformowej:

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 zezwolić na kontrolowane eksperymentowanie, w którym 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 danych jest drugorzędna. – Peter, lider inżynierii platformy, międzynarodowa firma technologiczna

Podczas swojej podróży w inżynierii platformy zidentyfikowałeś problemy, które mogą być potencjalnie 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 zgłębiać szczegóły. Agregacja i widoczność danych jest również ważna dla inspekcji, ładu i zmniejszenia strat (na przykład nieużywanych środowisk).

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óry z czasem przełączysz na w pełni zautomatyzowany przepływ. Dlatego projektowanie automatyzacji od samego początku.

Zacznij od ponownego wykorzystania istniejących inwestycji, takich jak systemy inżynieryjne lub portal wewnętrzny, a następnie przejdź do tworzenia interfejsów wiersza poleceń (CLI), podstawowych stron internetowych, a nawet Power Pages, pulpitów nawigacyjnych w Power BI lub Microsoft Fabric i rozbudowuj w miarę potrzeb. 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:

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

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

Nie. Po pierwsze, jest to model koncepcyjny, który pomoże Ci zastanowić się, jakie funkcje taki fundament powinien móc pełnić po jego ukończeniu. Po drugie, specyfika implementacji jest mniej ważna, ponieważ interfejs API platformy deweloperów staje się twoim kluczowym interfejsem. Twoja początkowa implementacja może rozpocząć się od użycia interfejsów i klas w kodzie dla opisanych różnych warstw lub może mieszać z innymi produktami. Możesz również pominąć aspekty, ponieważ rozwój klienta sugeruje, że jest to po prostu niższy priorytet. Zacznij od tego, co masz i rozwijaj się.

API platformy deweloperskiej

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 swojej reprezentacji profilu użytkownika, nadrzędnej roli użytkownika w ramach platformy (członka zespołu, administratora itp.) i identyfikatorów systemu głównego 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, należy utworzyć lub zidentyfikować 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 integrację z komponentami wtykowymi z dobrze zdefiniowanymi interfejsami. To luźne sprzężenie umożliwia stopniowe wprowadzanie potrzebnych elementów i zwiększa łatwość utrzymania, ponieważ można testować funkcje niezależnie od reszty systemu.

Jest to również ważny sposób, aby umożliwić skalowalną mentalność wewnętrznego źródła 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 dla deweloperów łagodzi to napięcie, umożliwiając niezależnemu kodowi podłączenie się do podstawowej funkcjonalności w ramach platformy samoobsługowej dla deweloperów. 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

Entities

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 programistów mogą następnie generować jednostki, aby umożliwić dostęp do podstawowych funkcji, w tym:

• Udostępnianie zewnętrznie przydzielonych zasobów lub środowisk oraz dostępnych interfejsów API do odnajdywania i używania
• Uwidacznianie relacji na potrzeby analizy zależności, analizy wpływu, odnajdywania itp.
• Udostępnianie informacji o opiekunach i właścicielach w celu ułatwienia 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 początkowo nie wybierzesz tej ścieżki, warto o tym pomyśleć w dłuższej perspektywie.

Wspólne właściwości

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

• Unikatowy identyfikator
• Name
• Dostawca początkowy
• Opcjonalne powiązania do:
  • Właściciel użytkownika
  • 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). Włączenie kontroli dostępu opartej na rolach od początku ma kluczowe znaczenie dla bezpieczeństwa i rozwoju wewnętrznej platformy deweloperów na przestrzeni czasu. Biorąc pod uwagę, że rozwijanie oprogramowania to sport zespołowy, odkrycie, z kim rozmawiać na temat jednostki, szybko stanie się kluczowe dla ponownego użycia, wsparcia i wewnętrznego pozyskiwania.

Wspólne i specyficzne dla dostawcy jednostki

Powinieneś być w stanie również ustanowić zestaw typowych, znormalizowanych jednostek wysokiego poziomu, które mogą generować różni dostawcy. Przykład:

• Środowiska
• Zasoby
• API-e
• Repozytoria
• Components
• Tools

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 wewnętrznej infrastruktury; wystarczy mieć wystarczającą ilość informacji, aby wymienić i powiązać różne środowiska koncepcyjne od wielu dostawców w tym samym interfejsie 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 są 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 encji, które mają na celu inicjowanie działań. Przykładowe scenariusze obejmują aprowizowanie infrastruktury, tworzenie repozytorium i inne długotrwałe procesy. Szablony te powinny być również dostępne za pośrednictwem rozszerzalnych platform deweloperskich i powinny obsługiwać te same wspólne właściwości jak encje, w tym skojarzenia encji.

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 Power Automate (na przykład przepływ w chmurze wyzwalany przez żądanie HTTP)
• 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 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. Pozostałe szablony IaC mogą być przechowywane w rejestrze artefaktów OCI, takich jak Helm charts. 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. Szablony mogą być umieszczone w najbardziej naturalnej lokalizacji dla 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 pośrednictwem systemu umożliwia deweloperom samoobsługę i tworzy bariery ochronne, które pomagają wymuszać zgodność ze standardami organizacyjnymi lub zasadami. Więcej na ten temat, gdy za chwilę omówimy orkiestrator platformy deweloperskiej.

Wykres platformy deweloperów

Wykres platformy deweloperskiej można traktować jako coś, co umożliwia łączenie jednostek i szablonów z wielu dostawców w przeszukiwalny graf. Jednak rzeczywiste dane jednostek nie muszą być utrwalane bezpośrednio w bazie danych specyficznej dla grafu. Zamiast tego interakcje z dostawcami mogą być buforowane wraz z wymaganymi metadanymi, aby wszystko pasowało do siebie.

Wykres jest potężny, gdy jest używany z wspólnymi elementami, do których współtworzenia może przyczynić się wielu dostawców. Na przykład lista interfejsów API może pochodzić z produktu, takiego jak Centrum API platformy Azure, ale możesz również chcieć automatycznie uwzględniać wdrożenia i środowiska 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 do wdrażania ma dostawcę platformy programistycznej, powinno być możliwe dokonanie skojarzenia.

Każde środowisko użytkownika, które budowane jest na podstawie tego grafu, może następnie korzystać ze wspólnego interfejsu API do odnajdywania, wyszukiwania, zarządzania i nie tylko. Orkiestrator platformy deweloperskiej może następnie skorzystać z tego samego grafu, dzięki czemu działania podejmowane przez dostawcę tej platformy automatycznie współtworzą jednostki dostępne przez to samo API.

Orkiestrator platformy deweloperskiej

Orkiestrator platformy deweloperów umożliwia deweloperom lub systemom tworzenie żądań wykonania akcji przy użyciu szablonu. Nie wykonuje tych akcji samodzielnie, lecz koordynuje to z silnikiem zadań, silnikiem przepływu pracy lub innym orkiestratorem, aby to osiągnąć. Jest to jeden z kluczowych elementów, które powinny stać się częścią twojej samoobsługowej infrastruktury. Umożliwia deweloperom tworzenie żądań za pomocą szablonu lub wykonywanie akcji bez bezpośredniego uprawnienia. Ponadto, w przeciwieństwie do koncepcji CI (ciągłej integracji) lub CD (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. To rozsądny punkt wyjścia, ale warto mieć trochę abstrakcji, aby umożliwić różnym typom szablonów korzystanie z różnych silników bazowych. Może to być przydatne z kilku powodów:

• Po pierwsze, prawdopodobnie będziesz chciał móc wybrać różne silniki przepływu pracy i realizacji zadań w czasie bez konieczności natychmiastowego przerywania. Zezwalając na więcej niż jeden silnik, można przeprowadzić migrację w czasie lub po prostu użyć nowego silnika do nowych działań bez wpływu na starsze działania.
• 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 do rozliczeń z dostawcami lub administrator licencji. Platformy niskokodowe, takie jak Power Automate, często działają dobrze do tych zadań.
• 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 programistycznej na obejmowanie wyzwalania i śledzenia kroków automatyzacji może zapewnić potrzebną 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 zwią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 wykonuje odpowiednie kroki 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, aby dodać lub zaktualizować wykres platformy dewelopera. Mogą to być jednostki specyficzne dla dostawcy lub wspólne.

Opcjonalnie, aby obsługiwać bardziej zaawansowane interakcje, dostawcy platform dla programistów mogą bezpośrednio wywoływać interfejs API, aby uzyskać więcej jednostek jako dane wejściowe lub nawet zażądać wykonania kolejnej powiązanej akcji.

Wybierz dostawcę platformy dla programistów, który używa ogólnego silnika zadań lub przepływu pracy. Bardziej szczegółowo, chcesz znaleźć coś, co połączy elementy, które ułożyłeś w ramach stosowania systemów inżynierii oprogramowania. Jednym z ogólnych aparatów przepływu pracy lub mechanizmów wykonywania zadań wartych rozważenia jest system CI/CD.

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 GitHub Actions kluczem do działania jest to, że dostawca platformy deweloperskiej może nawiązać połączenie z określonym wystąpieniem GitHub i użyć interfejsu REST API Actions do wyzwolenia zdarzenia wywołania przepływu pracy w celu uruchomienia procesu 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 potoków usługi Azure DevOps do uruchamiania przebiegów. Prawdopodobnie zobaczysz te same możliwości w innych produktach.

Te przepływy zadań lub potoki nie muszą być umieszczone 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ą zarządzać przepływami pracy/potokami w jednym lub więcej centralnych repozytoriach, do których deweloperzy nie mają dostępu, ale dostawca platformy deweloperów jest skonfigurowany do ich użycia. To samo repozytorium może zawierać skrypty i fragmenty kodu IaC używane przez przepływy pracy oraz linie przetwarzania.
• Aby umożliwić tym przepływom pracy/potom na interakcję z odpowiednim systemem podrzędnym, operatorzy lub inni członkowie zespołu inżynierii platformy mogą dodać potrzebne tajne dane w centralnym repozytorium. Zobacz dokumentację usługi 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 tajemnic używając usługi 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 deweloperskiej może obserwować stan przepływu pracy/rurki i aktualizować stan cyklu życia w orkiestratorze, aż do jego ukończenia. Możesz na przykład użyć webhooków z GitHub Actions i hooków usług z Azure Pipelines, aby śledzić aktualizacje.
• Po zakończeniu dostawca może następnie wykorzystywać opublikowany artefakt do dołączenia do grafu platformy deweloperów zgodnie z wymaganiami.

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.

Główną korzyścią z korzystania z systemu ciągłej integracji/ciągłego wdrażania jest to, że często są one skonfigurowane do obsługi dowolnych interfejsów wiersza poleceń (CLI), więc nie potrzebujesz wysokiej jakości, unikalnej integracji dla wszystkiego, co robisz. Można je dodawać w miarę potrzeb.

Większość tego, co opisano w tym przykładzie, dotyczy sposobu 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.

Chociaż nie potrzebujesz wszystkich tych dostawców, aby rozpocząć, możesz zobaczyć, jak rozszerzalność za pomocą czegoś w rodzaju dostawcy platformy dla deweloperów może pomóc w rozwijaniu możliwości automatyzacji z czasem.

Użytkownicy i zespoły

Inżynieria platformy z natury dotyczy wielu systemów, dlatego ważne jest zaplanowanie sposobu obsługi przez platformę samoobsługową trudniejszych problemów z integrowaniem tych systemów. Oto strategia rozwiązywania typowych wyzwań związanych z tożsamościami, użytkownikami i zespołami.

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 na potrzeby kontroli dostępu opartej na rolach 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 odkrywania i zbierania informacji w miejscach, takich jak panele 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 profilu użytkownika i magazynie metadanych zespołu. Możesz też zintegrować się bezpośrednio z projektem Azure Dev Center, który ma już dostępne podstawowe konstrukcje kontroli dostępu opartej na rolach (RBAC).

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

Podczas gdy niektóre narzędzia deweloperskie i operacyjne/usługi natywnie integrują i bezpośrednio wykorzystują koncepcje dostawcy tożsamości, wiele z nich abstrahuje to do własnej reprezentacji grupy lub użytkownika (nawet z logowaniem jednokrotnym). Poza umożliwianiem dostępu pomiędzy narzędziami, ta rzeczywistość może również powodować 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.

Zajmij się różnicami na poziomie zespołów i grup.

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, audytowalne repozytorium Git staje się głównym repozytorium zespołu, a pull requesty zapewniają kontrolowany interfejs użytkownika do 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 deweloperskiej dla źródła danych zespołowych może wywołać zdarzenie aktualizacji zespołu, które wszyscy inni dostawcy otrzymują i odpowiednio na nie reagują.

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-to-system do przeprowadzania zapytań o dane użytkownika, nie można założyć, że natywny identyfikator dostawcy tożsamości (na przykład identyfikator obiektu dla identyfikatora Entra) obsługuje dany interfejs API. Ponowne przechowywanie mapowania identyfikatora użytkownika, który uzyskuje dostęp do danych za pośrednictwem interfejsu API platformy deweloperskiej, może być pomocne. Rozważmy na przykład usługę GitHub:

W przypadku każdego systemu, jeśli możesz wyszukać identyfikator użytkownika w innym systemie 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.

Polegać na używaniu 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. 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ą inicjowane przez API zawierałyby się w tokenie użytkownika dostawcy, jeśli będzie 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 deweloperskiej przekaże URI uwierzytelniania dla przepływu OAuth z URI przekierowania, który został przekazany do dostawcy. Przekazany identyfikator URI będzie zawierać kod nieobsługiwalny/jednorazowy.
• Następnie API zwraca nieuwierzytelniony odpowiedź z identyfikatorem URI.
• Każdy interfejs użytkownika może następnie używać tego identyfikatora URI do uruchomienia odpowiedniego przepływu uwierzytelniania w przeglądarce.
• Po przekierowaniu platforma programistyczna otrzyma niezbędny token użytkownika i zapisze go do pamięci podręcznej wraz z identyfikatorem użytkownika w celu późniejszego wykorzystania.
• 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 złożonym uwierzytelnianiem, ponieważ można ponownie używać identyfikatorów tam, gdzie to możliwe, i nie trzeba utrzymywać oddzielnych identyfikatorów URI przekierowania dla każdego systemu podrzędnego.

Używanie kontekstowo świadomych linków głębokich do narzędzi i systemów raportowania

Do tego momentu mówiliśmy o aspekcie automatyzacji przestrzeni problemu. To samo działanie może znacząco wpłynąć, ponieważ Twój interfejs użytkownika może wykorzystywać wartości w zwracanych encjach 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ć dowolny rodzaj potrzebnej jednostki. Jednak zazwyczaj nie chcesz wprowadzać wszystkich szczegółowych danych na całej wewnętrznej platformie deweloperów do wykresu platformy deweloperów. Pulpity w rozwiązaniach do obserwacji, takich jak Grafana, Prometheus, DataDog, lub analiza kodu w produktach takich jak SonarQube, oraz funkcje natywne w pakietach DevOps jak GitHub i Azure DevOps, są w pełni funkcjonalne. 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 raportowe Power BI lub Microsoft Fabric mogą być następnym krokiem. Aby scalić dane zespołu, możesz nawiązać połączenie z bazą danych twojej 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 tworzeniu każdego dodatkowego doświadczenia, które budujesz.

Chociaż może być kuszące, aby odtworzyć istniejące funkcje w czymś na wzór wspólnego portalu, pamiętaj, że musisz je także utrzymywać. Jest to obszar, w którym ważne jest przyjęcie mentalności skoncentrowanej na produkcie. Interfejsy w stylu pulpitu nawigacyjnego są łatwe do zrozumienia, ale deweloperzy mogą znaleźć więcej wartości w innym miejscu.

To oznacza, że model tutaj umożliwia używanie zagregowanych danych w grafie platformy dla 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 chcesz wyświetlić dzienniki w Twoim UX, które ma już dobrze zdefiniowane i zarządzane miejsce. 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 doświadczeń, które należy wziąć pod uwagę:

Środowiska użytkownika

Różne role w organizacji mają narzędzia lub usługi, które reprezentują środek ciężkości ich codziennej pracy. Przyciąganie tych systemów może utrudnić nowe doświadczenia użytkownika zyskiwać popularność poza tymi centrami grawitacji. 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 od prostych rozwiązań, udowodnienia swojej wartości i rozwoju w kierunku bardziej złożonych interfejsów, w miarę jak pojawi się potrzeba.

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, programy lub aplikacje webowe, które chcesz nadal używać, są niestandardowe i stanowią 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ć. Zyskasz wiele korzyści z rozpoczęcia tam. 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
• Twój pakiet DevOps
• Interfejsy linii komend (CLI) są coraz bardziej rozszerzalne również
• Ś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 deweloperskiej jako punktu odniesienia pozwala na wymianę elementów, eksperymentowanie i wprowadzanie zmian w miarę upływu czasu.

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, następnie przekłada się na lokalne korzyści, zapewniając podwójny zysk.

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 używają 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. Biorąc pod uwagę, że większość platform ciągłej integracji/ciągłego wdrażania ma wbudowaną obsługę systemów, takich jak Microsoft Teams, Slack lub Discord, może to być naturalny sposób integracji z interfejsami użytkowanymi każdego dnia przez deweloperów interfejsu użytkownika i powiązane role operacyjne. 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 współpracującego z Tobą, to jest odpowiedni czas, aby go stworzyć. Każda organizacja jest inna, więc nie ma żadnej uniwersalnej odpowiedzi na to, co powinno być w tym rodzaju doświadczenia. W rezultacie nie ma domyślnej odpowiedzi ani wstępnie zapakowanego produktu, który można szybko uruchomić i użyć w stanie gotowym do użycia dla czegoś takiego w obecnych czasach.

W przypadku niestandardowych, samodzielnie hostowanych opcji ogólne struktury portali internetowych nie są nowością, a zespoły programistyczne mogą już korzystać z takiej, którą można wykorzystać. Jeśli próbujesz zaprezentować coś użytkownikom w celu uzyskania wczesnej opinii, możesz nawet zacząć od czegoś tak prostego jak Power Pages o niskim kodzie, aby połączyć się z typowym interfejsem API popularnej platformy deweloperskiej.

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 (CLI), który ułatwia inicjowanie drzewa źródłowego, podobnie jak create-react-app dla React.js.

Jako zestaw narzędzi portalu, wymaga pracy, a dostosowanie wymaga znajomości 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 katalogów oprogramowania i tworzenia szablonów, ale ich użycie nie jest wymagane i jest dobrze zdefiniowanym sposobem wprowadzenia nowego kodu nazywanego wtyczkami.

Treści powiązane

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