Definiowanie przestrzeni problemu
Podczas definiowania wewnętrznej platformy deweloperów musisz najpierw zdefiniować najcieńszą platformę do użytku (TVP). TVP jest odmianą idei minimalnego opłacalnego produktu (MVP) w klasycznym zarządzaniu produktami.
Ten diagram może ułatwić zorientowanie się na to, jak platforma deweloperów może ewoluować wraz z upływem czasu. Należy pamiętać, że głównym problemem organizacji może być odbieganie od tego, co zostało opisane w tym miejscu z powodu istniejących inwestycji lub potrzeb organizacji. Nie musisz przechodzić do następnego etapu, chyba że twoja organizacja tego potrzebuje.
Jeśli zaczynasz od podstaw, reprezentuje to typowy postęp. Na wczesnych etapach skoncentruj się na odnajdowaniu potrzebnych możliwości, analizie luk w zmniejszaniach opakowanych produktach i tworzeniu minimalnych narzędzi lub możliwości platformy. Następnie, w miarę skalowania, prawdopodobnie zaczniesz skupiać się na możliwości ponownego użycia i kierowaniu osób wstępnie zdefiniowanych ścieżek z zasobami wielokrotnego użytku. Na koniec przechodzisz do modelu "sklepu cyfrowego" przypominającego konsumentów, aby ułatwić tworzenie i konserwowanie aplikacji. Należy postępować zgodnie z nastawieniem produktu, dlatego nie zalecamy przechodzenia do końca i konkretnej podróży różnią się. Te ostatnie etapy najbardziej przypominają "produkt" opakowany w tradycyjny sposób, ale jest to miejsce docelowe, a nie punkt wyjścia.
Obszary tematów inżynierii platformy
Biorąc pod uwagę większy rozmiar tego tematu, zalecamy podzielenie sposobu wewnętrznie omawiania inżynierii platformy w czterech obszarach tematów:
Systemy inżynieryjne: wyselekcjonowane kombinacje pakietów DevOps, takich jak GitHub i Azure DevOps oraz inne narzędzia i usługi deweloperskie. Poza krytycznymi narzędziami i usługami DevOps, takimi jak ciągła integracja/ciągłe wdrażanie lub zarządzanie pakietami, ten obszar obejmuje również możliwości używane bezpośrednio podczas procesu kodowania, takie jak środowiska kodowania oparte na chmurze, skanery kodu i litry oraz asystenty sztucznej inteligencji, takie jak GitHub Copilot.
Platforma aplikacji: wyselekcjonowane opcje usług (takich jak IaaS, PaaS i możliwość obserwacji), które są przeznaczone dla każdego "stosu aplikacji" (klasy aplikacji, modelu aplikacji, języków), których organizacja chce użyć do dostarczania wartości biznesowej. Obejmuje to kombinację usług specyficznych dla stosu aplikacji wraz z typowymi usługami używanymi w całym. Przykładem platformy aplikacji może być usługa Azure Container Apps, Cosmos DB dla magazynu, usługa Azure Key Vault dla wpisów tajnych, kontrola dostępu oparta na tożsamościach i rolach, usługa Azure Policy w celu zapewnienia zgodności i inspekcji, obserwowanie za pośrednictwem narzędzia Grafana i powiązanej topologii sieci.
Szablony aplikacji: zestaw dobrze zdefiniowanych, utworzonych przez organizację szablonów szybkiego startu, które hermetyzują właściwy początek i pozostają właściwymi wskazówkami dla danej platformy aplikacji, języka i zestawu systemów inżynieryjnych. Mogą odwoływać się do innych scentralizowanych szablonów i udostępniać kod początkowy, odwołania do interfejsu API i zestawu SDK, potoki ciągłej integracji/ciągłego wdrażania, konfigurację narzędzi i nie tylko.
Możliwości samoobsługowe dla deweloperów: jest to klej do nakładu pracy inżynieryjnej platformy. Jest to kombinacja interfejsów API, orkiestratorów, katalogu, szablonów i środowisk użytkownika zaprojektowanych w celu zmniejszenia trudu deweloperów i umożliwienia zespołom deweloperów samodzielnej obsługi i bycia bardziej autonomicznym, a jednocześnie przestrzegając wyborów i wskazówek/ładu z poprzednich trzech obszarów.
Integrowanie systemów inżynieryjnych, platform aplikacji, szablonów aplikacji i możliwości samoobsługowych deweloperów stanowi podstawę strategii inżynierii platformy. Łącząc narzędzia DevOps, usługi w chmurze i funkcje samoobsługowe, organizacje mogą znacznie zmniejszyć trud deweloperów, zwiększyć produktywność i zapewnić zgodność ze standardami ładu.