Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Samoobsługa z poręczami jest zasadą umożliwiającą zespołom deweloperów podejmowanie własnych decyzji w ramach zestawu dobrze zdefiniowanych parametrów lub poręczy. Zabezpieczenia są ustanawiane i uzgadniane przez kluczowych uczestników projektu. Uczestnicy projektu mogą obejmować zespoły ds. zabezpieczeń, operacji, architektury w całej organizacji.
Korzystając z samoobsługi z barierami zabezpieczającymi, zespoły deweloperów zachowują autonomię, aby niezależnie podejmować decyzje programistyczne. Automatyzacja i zasady pomagają uczestnikom projektu zapewnić prawidłowe zarządzanie zabezpieczeniami, zgodnością, operacjami, standardami i kosztami. Włączenie tej automatyzacji wymaga współpracy między liniami zespołu, dzięki czemu deweloperzy, operatorzy i specjaliści mogą wykonywać więcej, bez poświęcania wymaganego ładu. Deweloperzy mogą wtedy jak najszybciej skoncentrować się na dostarczaniu wartości biznesowej.
[Mówimy deweloperom,] nie martwcie się o to, jak to wszystko działa, po prostu włączcie lub wyłączcie je, wypełnijcie, wstawcie ciąg tam, gdzie trzeba i jest to zasadniczo samoobsługa, w której mają plik readme, mają dane wejściowe, dane wyjściowe i mogą umieścić co tylko chcą. - Daniel, inżynier ds. chmury w firmie medialnej Fortune 500
Celem zapewnienia samodzielnej obsługi dla utwardzonych ścieżek jest zmniejszenie trudu dewelopera, a jednocześnie zapewnienie wglądu dla zespołów deweloperskich, operacji i zarządzania. Chodzi o to, aby utworzyć środowisko dla danego zadania, które ma minimalną krzywą uczenia się, częściowo dzięki jego podstawowej automatyzacji i możliwości agregacji danych. Poza działaniami, takimi jak zarządzanie zasobami infrastruktury, te rozwiązania mogą zapewnić dostęp do kluczowych możliwości, takich jak monitorowanie, polityki, zarządzanie incydentami i nie tylko. Pomysł obejmuje odnajdywanie i udostępnianie wewnętrznych interfejsów API, zestawów SDK wraz z udostępnionymi narzędziami i usługami. Te doświadczenia zmniejszają nakład pracy, dzięki czemu zespoły deweloperów mogą skupić się na realizacji zadań.
Wewnętrzne platformy deweloperskie umożliwiają deweloperom działanie jak klienci korzystający z cyfrowych witryn sklepowych.
Wewnętrzne platformy deweloperskie zapewniają możliwości podobne do firmowych witryn sklepów cyfrowych. Sklepy cyfrowe są z założenia zaprojektowane tak, aby pomóc swoim klientom w samodzielnej obsługi. Mogą obsługiwać większą przepustowość niż tradycyjne sklepy stacjonarne, ponieważ zapewniają sposoby odkrywania i realizacji interesujących produktów bez konieczności rozmowy z nikim. Korzystając z tej analogii, deweloperzy są klientem, a wewnętrzna platforma deweloperów zapewnia podobne środowiska samoobsługowe. Następnie operatorzy, inżynierowie platformy i inne role konfigurują katalog elementów, których deweloperzy mogą zażądać, aby uwzględnić zabezpieczenia organizacyjne.
Możesz na przykład pomyśleć o deweloperze żądającym dostępu do nowego narzędzia tak, jakby składali cyfrowe zamówienie sklepu. Podobnie jak w przypadku zamówienia, po przesłaniu żądania deweloper chce mieć możliwość śledzenia postępu i wiedzieć, kiedy zostanie ukończona. W tle żądanie powinno być automatycznie kierowane do odpowiedniego dostawcy realizacji w celu zaspokojenia potrzeb. Jeden z systemów ciągłej integracji i ciągłego dostarczania (CI/CD) można traktować jako jednego dostawcę realizacji, narzędzie GitOps lub platformę aplikacji preskrypcyjnej jako drugą, a także narzędzie automatyzacji przepływu pracy dla procesów ręcznych jako trzecie. We wszystkich przypadkach deweloper może samodzielnie obsługiwać elementy z dobrze zdefiniowanego wykazu w taki sam sposób.
Używaj wzorca "wszystko jako kod"
Używanie infrastruktury jako kodu (IaC) za pośrednictwem potoków ciągłego dostarczania (CD) i narzędzi GitOps jest ważną częścią umożliwiania samoobsługi. Usługa IaC z dyskiem CD umożliwia tworzenie i niszczenie zasobów w chmurze na żądanie przy użyciu pakietów Bicep, Terraform, helm i innych narzędzi. Ponieważ konfiguracja infrastruktury chmury jest zarządzana tak samo jak kod w repozytorium kodu źródłowego, możesz zastosować wszystkie zalety repozytorium Git, takie jak zabezpieczenia i inspekcja.
Aprowizowanie wspólnej infrastruktury i narzędzi nie jest jedyną zaletą podejścia IaC. Możesz dostosować wzorzec IaC dla innych scenariuszy, w tym zabezpieczeń jako kodu i zasad jako kodu (za pomocą narzędzi takich jak Azure Policy i Open Policy Agent). Zgodnie z tą techniką plik konfiguracji, zazwyczaj YAML lub JSON, jest wypychany do repozytorium, co wyzwala przepływ pracy, który przetwarza plik. Te pliki mogą być repozytorium aplikacji, takie jak dependabot.yml lub CODEOWNERS, lub mogą być przechowywane w osobnym centralnym repozytorium. Możesz nawet rozszerzyć to na własne scenariusze, aby naprawdę urzeczywistnić ideę Kod jako wszystko (EaC).
Deweloperzy mogą odwoływać się do każdego z tych szablonów EaC poprzez centralny katalog, który wspiera środowiska samoobsługowe i domyślnie promuje najlepsze praktyki.
Tworzenie odpowiednich szablonów startowych i ustanawianie odpowiedniego ładu
W tworzeniu oprogramowania dążymy do hermetyzacji, modułowości i komposowalności podczas projektowania aplikacji. Należy zastosować tę samą linię myślenia do inżynierii platformy poprzez tworzenie szablonów. Można na przykład utworzyć i użyć zestawu centralnie zabezpieczonych szablonów IaC wielokrotnego użytku jako bloków konstrukcyjnych dla infrastruktury.
Utworzymy moduły dla naszych [deweloperów]... dlatego zamiast pisać lub martwić się o zaplecze, wszystko, co muszą zrobić, to skupić się na kodzie aplikacji. - Daniel, inżynier ds. chmury w firmie medialnej Fortune 500
Połącz szablony IaC, EaC i aplikacji w dostosowane rozwiązanie typu wszystko jako kod (EaC), które obejmuje także inne działania, takie jak tworzenie repozytorium kodu źródłowego, udostępnianie przykładowego kodu lub dostarczanie konfiguracji i przykładowego kodu dla zalecanych narzędzi do obserwacji. Te szablony IaC, EaC i aplikacji można następnie przechowywać lub odwoływać się do nich z centralnej, zabezpieczonej lokalizacji, takiej jak repozytorium, wykaz w środowiskach wdrażania platformy Azure lub usługa Azure Container Registry dla natywnej chmury.
Po rozpoczęciu właściwym szablonów ze zautomatyzowanym zarządzaniem, skanowaniem i konfiguracją zasad, deweloperzy utrzymują właściwe działanie od pierwszego dnia pracy.
Szablony usprawniają programowanie za pomocą zautomatyzowanych, bezpiecznych rozwiązań
Użyj szablonów aplikacji, aby zainicjować zdefiniowane ścieżki kluczowych decyzji i działań, które deweloperzy podejmują w trakcie projektu. Odpowiednie szablony startowe ustanawiają bezpieczne, zarządzane praktyki programistyczne i umożliwiają deweloperom szybkie rozpoczęcie pracy poprzez włączenie automatyzacji, która zapewnia dostęp do potrzebnych narzędzi, konfiguruje potoki ciągłej integracji/ciągłego wdrażania, zapewnia stos infrastruktury i aplikacji oraz konfigurując repozytorium wraz z kodem źródłowym szablonu, który zawiera wymagane zestawy SDK lub odniesienia do interfejsów API.
Dzięki temu, że te szablony aplikacji odwołują się do innych scentralizowanych szablonów (na przykład szablonów IaC), każdy z tych pojedynczych bloków konstrukcyjnych staje się samodzielnym szablonem startowym. Szablony te mają kluczowe znaczenie dla umożliwienia samoobsługowych doświadczeń, ponieważ nie tylko definiują dane wyjściowe, ale także dostępne opcje, które wybierają deweloperzy.
Szablony zapewniają nadzór, zabezpieczenia i optymalizację kosztów
Jednak szablony powinny oferować więcej niż tylko inicjowanie projektu programistycznego. Powinny one również ustanowić kontrolę i zarządzanie poprzez zasady i skanowanie zabezpieczeń niezbędne do utrzymania właściwego kierunku w trakcie cyklu życia projektu. W innym przykładzie szablony mogą konfigurować reguły ochrony gałęzi uniemożliwiające nieautoryzowane scalanie z produkcją. Ponieważ szablony przechwytują najlepsze rozwiązania i typowe konfiguracje, są one jedną z kluczowych technik optymalizacji kosztów między narzędziami, dostawcami i zespołami.
Prowadź właściwe kampanie, aby zbudować dwukierunkową komunikację.
W miarę wzrostu zaufania do utartych ścieżek można użyć bazowych elementarnych bloków konstrukcyjnych składanych w szablony aplikacji, aby przenieść obecne aplikacje na utartą ścieżkę. Ponieważ twoi wewnętrzni klienci już doceniają wartość utwardzonych ścieżek pilotażowych, możesz uruchomić wewnętrzną kampanię korekcyjną, aby nawiązać dwukierunkowy dialog z innymi zespołami zajmującymi się aplikacjami. Deweloperzy mogą dowiedzieć się, jak migrować swoją aplikację, podczas gdy zespół inżynierów platformy jednocześnie dowie się więcej o tym, jak ulepszyć platformę.
Wyznacz własną podróż
Biorąc pod uwagę, jak wiele doświadczeń zdolności samoobsługowe mogłyby objąć zakresem, ważne jest skoncentrowanie wysiłków inwestycyjnych oraz planowanie i ustalanie priorytetów, aby wewnętrzna platforma deweloperów dostarczała wartość stopniowo. Podróż każdej organizacji w tworzeniu wewnętrznej platformy deweloperskiej jest inna, a przyjęcie podejścia opartego na produkcie pomaga najpierw skupić się na najbardziej krytycznych obszarach wymagających samoobsługi.