Zwiększanie możliwości deweloperów za pomocą samoobsługi za pomocą barier zabezpieczających
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.
Dzięki samoobsługi z poręczami 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 martw się o to, jak to wszystko działa, po prostu przełączać je na lub wyłączać, wypełniać go, umieszczać ciąg w cokolwiek musisz zrobić i jest to w zasadzie samoobsługa w tym zakresie, gdzie mają plik readme i mają dane wejściowe, dane wyjściowe i mogą umieścić w dowolny sposób. - Daniel, Inżynier chmury, Fortune 500 Media Company
Celem zapewnienia samoobsługowego środowiska dla utorowanych ścieżek jest zmniejszenie trudu dewelopera, a jednocześnie zapewnienie wglądu w zespoły deweloperskie, operacje i zarządzanie. 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 aprowizowanie infrastruktury, może zapewnić dostęp do krytycznych funkcji umożliwiających obserwowanie, zasady, zarządzanie zdarzeniami 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 środowiska zmniejszają nakład pracy, dzięki czemu zespoły deweloperów mogą skupić się na uzyskaniu pracy.
Wewnętrzne platformy deweloperów umożliwiają deweloperom działanie jak klienci z witryną sklepów cyfrowych
Wewnętrzne platformy deweloperów zapewniają podobne możliwości 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ą przepływność niż tradycyjne fronty sklepów, ponieważ zapewniają sposoby odnajdywania i wypełniania interesujących elementó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. Podobnie jak w przypadku sprzedawcy detalicznego, operatorów, inżynierów platformy i innych ról, a następnie skonfigurowanie katalogu elementów, które deweloperzy mogą zażądać, aby były przeznaczone do obsługi barier organizacyjnych.
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żyj wszystkiego jako wzorca kodu
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ą włączania 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żna dostosować jako wzorzec kodu 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, w którym momencie jest wyzwalany 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ę uczynić wszystko jako kodem (EaC) rzeczywistością.
Deweloperzy mogą odwoływać się do każdego z tych szablonów eaC z centralnym wykazem, który obsługuje środowiska samoobsługowe i zachęca domyślnie najlepsze rozwiązania.
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 każdy z zaplecza, wszystko, co muszą zrobić, to martwić się o kod aplikacji. - Daniel, Inżynier chmury, Fortune 500 Media Company
Połącz szablony IaC, EaC i aplikacji w dostosowane rozwiązanie jako kod (EaC), które rozszerza inne działania, takie jak tworzenie repozytorium kodu źródłowego, rozmieszczanie 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, katalogu w środowiskach wdrażania platformy Azure (ADE) lub usługi Azure Container Registry (ACR) dla natywnej chmury.
Po połączeniu odpowiednich szablonów z automatycznym ładem, skanowaniem i konfiguracją zasad deweloperzy pozostają od pierwszego dnia.
Szablony usprawniają programowanie za pomocą zautomatyzowanych, bezpiecznych rozwiązań
Użyj szablonów aplikacji, aby uruchomić zdefiniowane ścieżki w celu podjęcia kilku kluczowych decyzji i akcji, które deweloperzy przejmują w trakcie projektu. Zacznij od właściwych szablonów ustanawiać bezpieczne, zarządzane praktyki programistyczne i umożliwić deweloperom szybkie rozpoczęcie pracy dzięki włączeniu automatyzacji zapewniającej dostęp do potrzebnych narzędzi, konfigurowania potoków ciągłej integracji/ciągłego wdrażania, aprowizowania stosu infrastruktury i aplikacji oraz konfigurowania repozytorium wraz z kodem źródłowym płyty kotłowej, która zawiera wymagane zestawy SDK lub odwołania do interfejsów API.
Dzięki zastosowaniu tych szablonów 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ę własnymi szablonami. Te szablony mają kluczowe znaczenie dla umożliwienia samoobsługowego środowiska, ponieważ nie tylko definiują dane wyjściowe, ale także dostępne opcje, z których korzystają deweloperzy.
Szablony zapewniają nadzór, zabezpieczenia i optymalizację kosztów
Jednak szablony powinny wykonywać więcej niż tylko uruchamianie nakładu pracy programistycznej. Powinny one również ustanowić kontrolę i ład poprzez zasady i skanowanie zabezpieczeń niezbędne do stałego utrzymania się 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.
Uruchamianie właściwych kampanii w celu utworzenia dwukierunkowej komunikacji
W miarę wzrostu zaufania do ścieżek chodnikowych można użyć bazowych pojedynczych bloków konstrukcyjnych złożonych w szablonach aplikacji, aby przenieść istniejące aplikacje na ścieżkę utorowaną. Ponieważ twoi wewnętrzni klienci będą już widzieć wartość ścieżek pilotażowych, możesz uruchomić wewnętrzną kampanię get right, aby utworzyć dwukierunkowe okno dialogowe z innymi zespołami aplikacji. 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ę.
Wykres własnej podróży
Biorąc pod uwagę zakres doświadczeń, które mogą obejmować możliwości samoobsługi, ważne jest, aby wysiłki inwestycyjne i planować i ustalać priorytety, aby wewnętrzna platforma deweloperów dostarczała wartość przyrostowo. Podróż każdej organizacji w zakresie tworzenia wewnętrznej platformy deweloperów jest inna, a po tym, jak wygląda sposób myślenia o produkcie, pomaga najpierw kierować się do najbardziej krytycznych miejsc wymagających samoobsługi.