Stosowanie systemów inżynierii oprogramowania

Artykuł
07/25/2024

Ulepszanie samoobsługi deweloperów powinno być jednym z pierwszych problemów, które należy rozwiązać w podróży inżynieryjnej platformy.

Jednym z najprostszych sposobów rozpoczęcia włączania zautomatyzowanych środowisk samoobsługowych jest ponowne użycie istniejących systemów inżynieryjnych. Nie tylko te systemy są znane Tobie i Twoim klientom wewnętrznym, ale mogą one umożliwić szeroką gamę scenariuszy automatyzacji, nawet jeśli początkowe środowisko użytkownika nie jest ładne.

Ten artykuł zawiera wskazówki dotyczące stosowania systemów inżynieryjnych w celu rozwiązania szerszej gamy scenariuszy samoobsługowych oraz szczegółowe informacje na temat sposobu hermetyzacji najlepszych rozwiązań w szablonach, które ułatwiają rozpoczęcie pracy i pozostanie w porządku.

Ocena podstawowych rozwiązań DevOps i DevSecOps

Systemy inżynieryjne są krytycznym aspektem wewnętrznej platformy deweloperów. Wewnętrzne platformy deweloperów tworzą się z głównych dzierżaw devOps i DevSecOps w celu zmniejszenia obciążenia poznawczego dla wszystkich zaangażowanych osób.

Metodyka DevOps łączy programowanie i operacje w celu zjednoczenia ludzi, procesów i technologii w zakresie planowania aplikacji, programowania, dostarczania i operacji. Ma na celu poprawę współpracy między historycznie głupimi rolami, takimi jak programowanie, operacje IT, inżynieria jakości i bezpieczeństwo. Tworzysz ciągłą pętlę między programowaniem, wdrażaniem, monitorowaniem, obserwacją i opiniami. Warstwy DevSecOps w tej pętli z ciągłymi praktykami zabezpieczeń w całym procesie tworzenia aplikacji.

Obraz cyklu życia metodyki DevOps z planem, dostarczaniem, opracowywaniem i działaniem.

Poniższe sekcje koncentrują się na ulepszeniach bardziej bezpośrednio przypisywanych ruchowi inżynieryjnemu platformy: ścieżki utorowane, automatyczna aprowizacja infrastruktury (oprócz wdrażania aplikacji), konfiguracja środowiska kodowania wraz z samoobsługową aprowizowaniem i konfiguracją narzędzi, zasobów zespołu i usług, które nie są bezpośrednio częścią pętli tworzenia aplikacji.

Ustanów żądane ścieżki chodnikowe

Jeśli masz już wiele zestawów narzędzi, które tworzą systemy inżynieryjne, jedną z wczesnych decyzji jest to, czy chcesz je skonsolidować w ramach początkowych działań inżynieryjnych platformy, czy jeśli będziesz obsługiwać konstelację różnych narzędzi od samego początku. Definiowanie zestawu utorowanych ścieżek w ramach tej konstelacji narzędzi jest najbardziej skuteczne i zapewnia zwiększony poziom elastyczności.

Gdy zaczniesz przechodzić w kierunku myślenia o produkcie, pomyśl o systemach inżynieryjnych w ramach tych utorowanych ścieżek jako składających się z narzędzi zarządzanych centralnie jako usługi dla zespołów programistycznych. Poszczególne zespoły lub działy w organizacji mogą wówczas odbiegać, ale oczekuje się, że będą zarządzać, utrzymywać i płacić za swoje narzędzia oddzielnie, jednocześnie przestrzegając wszelkich wymagań dotyczących zgodności. Zapewnia to sposób wprowadzania nowych narzędzi do ekosystemu bez zakłóceń, ponieważ można ocenić wszystko, co odbiega od możliwego włączenia na torowaną ścieżkę w czasie. Jak ujął to jeden z liderów inżynierów platformy:

Nadal możesz zrobić własne rzeczy, ale zrobić to w kierunku, w którym idziemy ... możesz zmienić wszystko, co chcesz, ale staje się to twoim obowiązkiem. Posiadasz zmiany — posiadasz ostre noże. - Mark, lider inżynierii platformy, Duża międzynarodowa firma detaliczna

Biorąc pod uwagę, że kluczowym celem inżynierii platformy jest przejście na sposób myślenia o produkcie, w którym podajesz wartość klientom wewnętrznym, to podejście konstelacji zwykle działa lepiej niż mandat od góry. Podczas ustanawiania i uściślinia utorowanych ścieżek, pozostawienie pewnej elastyczności umożliwia zespołom dostarczanie danych wejściowych i rozwiązywanie wszelkich naprawdę unikatowych wymagań dla danej aplikacji bez wpływu na inne osoby w organizacji. Prowadzi to do zestawu w pełni utorowanych, złotych ścieżek, podczas gdy inne są tylko częściowo utorowane. W przypadkach, gdy nie ma unikatowych wymagań, dodatkowe zespoły programistyczne będą oczywiście powodować, że chcą przejść do obsługiwanej ścieżki w czasie.

Jeśli wolisz strategię konsolidacji, migrowanie istniejących aplikacji może być bardziej pracy niż oczekiwano, więc na początek prawdopodobnie zechcesz skupić się na właściwym aspekcie tego obszaru i skoncentrować się na nowych projektach. Daje to pierwszą utorowaną ścieżkę, podczas gdy wszystko istniejące jest z natury niepaved. Zespoły programistyczne na niepavowanej ścieżce będą następnie rozważać przeniesienie po tym, jak nowa ścieżka utorowana pokazuje jej wartość w organizacji. W tym momencie możesz uruchomić właściwą kampanię, aby wszyscy na żądanym stanie poprzez dwukierunkową komunikację, ponieważ zespoły deweloperów postrzegają to jako korzyści, a nie podatek. Podczas kampanii zespoły inżynierów platformy mogą skupić się na pomaganiu zespołom w migracji, podczas gdy zespoły deweloperskie przekazują opinię na temat tego, jak lepiej tworzyć utorowane ścieżki.

Niezależnie od tego, należy unikać nakazania korzystania z utorowanych ścieżek. Najskuteczniejszym sposobem wdrożenia utorowanych ścieżek jest podkreślenie tego, co zespoły wydostają się z nich, a nie poprzez wymuszone wdrożenie. Ponieważ wewnętrzna platforma deweloperów koncentruje się na tym, aby te same zespoły były szczęśliwe, budżet i presja czasowa na poszczególnych liderów dbają o resztę. Uzyskaj odpowiednie kampanie, a następnie zapewnij drogę do dwukierunkowych rozmów w najlepszy sposób dla tych na niepaved ścieżce, aby przełączyć się.

Używanie narzędzi automatyzacji deweloperów do ulepszania samoobsługi dla ścieżek utorowanych

Częścią tworzenia pierwszej ścieżki utorowanej powinno być ustanowienie podstawowych produktów automatyzacji deweloperów. Są one ważne, ponieważ zaczynasz myśleć o włączaniu możliwości samoobsługi deweloperów.

Włączanie automatycznej aprowizacji infrastruktury aplikacji podczas ciągłego dostarczania

Jeśli jeszcze nie zaimplementowano, problemy zidentyfikowane podczas planowania mogą wskazywać na problemy, które mogą pomóc w rozwiązaniu ciągłej integracji (CI) i ciągłego dostarczania (CD). W tym miejscu istnieją produkty takie jak GitHub Actions, Azure DevOps, Jenkins oraz rozwiązania GitOps oparte na ściąganiu, takie jak Flux lub Argo CD . Możesz rozpocząć pracę z tymi tematami w centrum zasobów usługi Microsoft DevOps.

Nawet jeśli zaimplementowano już sposób ciągłego wdrażania aplikacji w istniejącej infrastrukturze, należy rozważyć użycie infrastruktury jako kodu (IaC) w celu utworzenia lub zaktualizowania wymaganej infrastruktury aplikacji w ramach potoku ciągłego wdrażania.

Rozważmy na przykład te ilustracje przedstawiające dwa podejścia, które używają funkcji GitHub Actions do aktualizowania infrastruktury i wdrażania w usłudze Azure Kubernetes Service: jednego przy użyciu wdrożeń opartych na wypychaniach i wdrożeniach opartych na ściąganiu (GitOps).

Do wyboru służy istniejący zestaw umiejętności IaC oraz szczegóły platformy aplikacji docelowej. Podejście GitOps jest najnowsze i jest popularne wśród organizacji korzystających z platformy Kubernetes jako podstawy dla swoich aplikacji, podczas gdy model oparty na ściąganiu zapewnia obecnie największą elastyczność, biorąc pod uwagę liczbę dostępnych opcji. Oczekujemy, że większość organizacji korzysta z kombinacji tych dwóch. Niezależnie od tego, staje się dobrze zorientowany w praktykach IaC pomoże Ci nauczyć się wzorców, które mają zastosowanie do dalszych scenariuszy automatyzacji.

Scentralizowanie IaC w katalogu lub rejestrze w celu skalowania i zwiększania bezpieczeństwa

Aby zarządzać IaC i skalować je w aplikacjach, należy opublikować artefakty IaC centralnie w celu ponownego użycia. Można na przykład użyć modułów Terraform w rejestrze, modułach Bicep, przepisach usługi Radius lub wykresach Helm przechowywanych w natywnym rejestrze artefaktów OCI w chmurze, takich jak Usługa Azure Container Registry (ACR), DockerHub lub wykaz w środowiskach wdrażania platformy Azure (ADE). W przypadku usług GitOps i Kubernetes interfejs API klastra (i implementacje, takie jak CAPZ) umożliwia zarządzanie klastrami obciążeń Kubernetes, podczas gdy niestandardowe definicje zasobów, takie jak Azure Service Operator, mogą zapewnić dodatkową obsługę innych rodzajów zasobów platformy Azure, inne narzędzia, takie jak zasoby obsługiwane przez wiele chmur. Umożliwiają one korzystanie ze scentralizowanych lub typowych wykresów Helm w postaci usługi ACR dla szerszej gamy scenariuszy.

Scentralizowanie IaC zwiększa bezpieczeństwo, zapewniając lepszą kontrolę nad tym, kto może wprowadzać aktualizacje, ponieważ nie są już przechowywane przy użyciu kodu aplikacji. Istnieje mniejsze ryzyko przypadkowej przerwy spowodowanej nieumyślną zmianą podczas aktualizacji kodu, gdy eksperci, operacje lub inżynierowie platformy wprowadzają potrzebne zmiany. Deweloperzy korzystają również z tych bloków konstrukcyjnych, ponieważ nie muszą tworzyć kompletnych szablonów IaC i automatycznie korzystać z zakodowanych najlepszych rozwiązań.

Wybrany format IaC zależy od istniejącego zestawu umiejętności, wymaganego poziomu kontroli i używanego modelu aplikacji. Na przykład usługa Azure Container Apps (ACA) i ostatni eksperymentalny projekt inkubacji systemu operacyjnego Radius są bardziej opiniowane niż bezpośrednie korzystanie z platformy Kubernetes, ale także usprawnianie obsługi deweloperów. Moduł szkoleniowy Opis typów usług w chmurze może ułatwić zrozumienie zalet i wad różnych modeli. Niezależnie od tego, odwoływanie się do scentralizowanego i zarządzanego IaC zamiast posiadania pełnych definicji w drzewie źródłowym ma znaczne korzyści.

Utrwalanie wszelkich potrzebnych tożsamości aprowizacji lub wpisów tajnych w sposób, który deweloperzy nie mogą bezpośrednio uzyskiwać do nich dostępu w podstawowych blokach konstrukcyjnych w celu zapewnienia ładu. Rozważmy na przykład tę ilustrację na temat separacji ról, którą można osiągnąć przy użyciu środowisk wdrażania platformy Azure (ADE).

W tym miejscu inżynierowie platformy i inni specjaliści opracowują IaC i inne szablony i umieszczają je w katalogu. Operacje mogą następnie dodawać tożsamości zarządzane i subskrypcje według typu środowiska oraz przypisywać deweloperów i innych użytkowników, którzy mogą ich używać do aprowizacji.

Deweloperzy lub potok ciągłej integracji/ciągłego wdrażania mogą następnie użyć interfejsu wiersza polecenia platformy Azure lub interfejsu wiersza polecenia dla deweloperów platformy Azure do aprowizacji wstępnie skonfigurowanej i kontrolowanej infrastruktury, nawet bez dostępu do bazowej subskrypcji lub tożsamości wymaganych do tego celu. Niezależnie od tego, czy używasz czegoś takiego jak ADE, czy nie, wybrany system ciągłego dostarczania może pomóc w bezpiecznym i bezpiecznym aktualizowaniu infrastruktury przez oddzielenie wpisów tajnych i określanie źródła zawartości IaC od lokalizacji, do których deweloperzy nie mogą uzyskiwać dostępu ani modyfikować samodzielnie.

Włączanie samoobsługi w scenariuszach poza ciągłym dostarczaniem aplikacji

Chociaż koncepcje ciągłej integracji i ciągłego wdrażania są powiązane z tworzeniem aplikacji, wiele elementów, które klienci wewnętrzni chcą aprowizować, nie wiąże się bezpośrednio z określoną aplikacją. Może to być infrastruktura udostępniona, tworzenie repozytorium, narzędzia aprowizacji i nie tylko.

Aby zrozumieć, gdzie może to pomóc, zastanów się, gdzie obecnie masz procesy ręczne lub oparte na pomocy technicznej. Dla każdego z nich zastanów się nad następującymi pytaniami:

Jak często dzieje się ten proces?
Czy proces jest powolny, podatny na błędy, czy wymaga znacznej pracy do osiągnięcia?
Czy te procesy są wykonywane ręcznie z powodu wymaganego kroku zatwierdzania, czy po prostu braku automatyzacji?
Czy osoby zatwierdzające znają systemy kontroli źródła i procesy żądań ściągnięcia?
Jakie są wymagania dotyczące inspekcji procesów? Czy różnią się one od wymagań inspekcji systemu kontroli źródła?
Czy istnieją procesy, które można rozpocząć od tego, że są niższe ryzyko przed przejściem do bardziej złożonych?

Zidentyfikuj częste, wysokie nakłady pracy lub podatne na błędy procesy jako potencjalne cele do zautomatyzowania.

Użyj wszystkiego jako wzorca kodu

Jedną z miłych rzeczy na temat usługi Git oprócz jej wszechobecności jest to, że ma być bezpiecznym, podlegającym inspekcji źródłem informacji. Poza historią zatwierdzania i kontrolą dostępu koncepcje, takie jak żądania ściągnięcia i ochrona gałęzi, zapewniają możliwość ustanowienia określonych recenzentów, historii konwersacji i automatycznych testów, które muszą zostać przekazane przed scaleniem z gałęzią główną. W połączeniu z elastycznymi aparatami zadań, takimi jak te znajdujące się w systemach ciągłej integracji/ciągłego wdrażania, masz bezpieczną platformę automatyzacji.

Ideą wszystkiego, co jest kod, jest to, że możesz przekształcić prawie wszystko w plik w bezpiecznym repozytorium Git. Różne narzędzia lub agenci połączeni z repozytorium mogą następnie odczytywać zawartość. Traktowanie wszystkich elementów jako kodu ułatwia powtarzalność poprzez tworzenie szablonów i upraszcza samoobsługę deweloperów. Zapoznajmy się z kilkoma przykładami tego, jak to może działać.

Stosowanie wzorców IaC do dowolnej infrastruktury

Chociaż infrastruktura IaC zyskała popularność na potrzeby automatyzowania dostarczania aplikacji, wzorzec rozszerza się na dowolną infrastrukturę, narzędzia lub usługi, które warto aprowizować i konfigurować — nie tylko te powiązane z określoną aplikacją. Na przykład udostępnione K8s klastrom z zainstalowanym rozwiązaniem Flux, aprowizowanie czegoś takiego jak DataDog , które jest używane przez wiele zespołów i aplikacji, a nawet konfigurowanie ulubionych narzędzi do współpracy.

W ten sposób można korzystać z oddzielnego, zabezpieczonego scentralizowanego repozytorium zawierającego serię plików reprezentujących to, co należy aprowizować i skonfigurować (w tym przypadku wszystkie elementy, od Bicep, Terraform, do wykresów Helm i innych formatów natywnych platformy Kubernetes). Zespół operacyjny lub inny zestaw administratorów jest właścicielem repozytorium, a deweloperzy (lub systemy) mogą przesyłać żądania ściągnięcia. Po scaleniu tych żądań ściągnięcia z gałęzią główną przez tych administratorów te same narzędzia ciągłej integracji/ciągłego wdrażania używane podczas tworzenia aplikacji mogą rozpocząć proces zmian. Rozważmy tę ilustrację, która korzysta z funkcji GitHub Actions i tożsamości IaC i wdrożeń, które znajdują się w środowiskach wdrażania platformy Azure:

Jeśli już używasz podejścia GitOps do wdrażania aplikacji, możesz również użyć tych narzędzi. Łączenie narzędzi, takich jak Flux i Azure Service Operator , umożliwia rozszerzenie poza platformę Kubernetes:

W obu przypadkach masz w pełni zarządzane, odtwarzalne i możliwe do inspekcji źródło informacji — nawet jeśli to, co zostało wygenerowane, nie jest przeznaczone dla aplikacji. Podobnie jak w przypadku tworzenia aplikacji, wszystkie potrzebne wpisy tajne lub tożsamości zarządzane są przechowywane w aplikacji potoku/przepływu pracy lub w natywnych możliwościach usługi aprowizacji.

Ponieważ osoby wykonujące żądania ściągnięcia nie będą miały bezpośredniego dostępu do tych wpisów tajnych, zapewnia deweloperom możliwość bezpiecznego inicjowania akcji, które nie mają bezpośredniego uprawnienia do samodzielnego wykonywania. Dzięki temu można stosować się do zasady najniższych uprawnień, jednocześnie zapewniając deweloperom opcję samoobsługi.

Śledzenie aprowizowanej infrastruktury

Gdy zaczniesz skalować to podejście, zastanów się, jak chcesz śledzić aprowizowaną infrastrukturę. Repozytorium git jest źródłem prawdy dla konfiguracji, ale nie informuje o określonych identyfikatorach URI i informacjach o stanie na temat tego, co zostało utworzone. Jednak po wykonaniu wszystkich czynności związanych z podejściem kodu można uzyskać źródło informacji w celu zsyntetyzowania spisu aprowizowanej infrastruktury. Aprowizacja może być również dobrym źródłem tych informacji, które można wykorzystać. Na przykład środowiska wdrażania platformy Azure obejmują funkcje śledzenia środowiska, do których deweloperzy mają wgląd.

Aby dowiedzieć się więcej na temat śledzenia różnych źródeł danych, zobacz Projektowanie podstaw samoobsługi dla deweloperów.

Stosowanie zabezpieczeń jako kodu i zasad jako wzorców kodu

Chociaż infrastruktura aprowizacji jest przydatna, upewnij się, że te środowiska są bezpieczne i ogólnie zgodne z zasadami organizacji są równie ważne. Doprowadziło to do powstania koncepcji "zasady jako kodu". W tym miejscu pliki konfiguracji w repozytorium kontroli źródła mogą służyć do wykonywania takich czynności, jak skanowanie zabezpieczeń dysków lub stosowanie zasad infrastruktury.

W wielu różnych produktach i projektach typu open source przyjęto takie podejście, takie jak Azure Policy, Open Policy Agent, GitHub Advanced Security i GitHub CODEOWNERS, między innymi. Podczas wybierania infrastruktury aplikacji, usług lub narzędzi należy ocenić, jak dobrze obsługują te wzorce. Aby uzyskać więcej informacji na temat uściślenia aplikacji i ładu, zobacz Uściślij platformę aplikacji.

Używanie wszystkiego jako kodu dla własnych scenariuszy

Wszystko, jak kod rozszerza te wzorce na szeroką gamę zadań automatyzacji i konfiguracji poza IaC. Może obsługiwać nie tylko tworzenie i konfigurowanie dowolnego typu infrastruktury, ale także aktualizowanie danych lub wyzwalanie przepływów pracy w dowolnym systemie podrzędnym.

Żądanie ściągnięcia staje się dobrym podstawowym środowiskiem użytkownika samoobsługi dla różnych procesów — szczególnie podczas rozpoczynania pracy. Procesy naturalnie uzyskują korzyści związane z zabezpieczeniami, inspekcją i wycofywaniem w usłudze Git, a zaangażowane systemy mogą również ulec zmianie w czasie bez wpływu na środowisko użytkownika.

Zespoły jako kod

Przykładem zastosowania wszystkiego jako kodu do własnych scenariuszy jest zespoły jako wzorzec kodu. Organizacje stosują ten wzorzec do standaryzacji członkostwa w zespole i, w niektórych przypadkach, uprawnień narzędzi deweloperskich/usług w wielu różnych systemach. Ten wzorzec eliminuje ręczne dołączanie i odłączanie procesów pomocy technicznej opartych na potrzebie deweloperów systemów i operatorów w celu uzyskania dostępu do własnych pojęć dotyczących grupowania, użytkowników i dostępu. Procesy obsługi ręcznej stanowią potencjalne zagrożenie bezpieczeństwa, ponieważ istnieje możliwość nadmiernego aprowizacji dostępu. W przypadku korzystania z zespołów jako wzorca kodu kombinacja żądań ściągnięcia i git może umożliwić samoobsługę ze źródła danych z możliwością inspekcji.

Aby zapoznać się z przykładem dojrzałej, obszernej odmiany tego wzorca, zapoznaj się z wpisem w blogu usługi GitHub dotyczącym zarządzania upoważnieniami. W usłudze GitHub zaimplementowano również zaawansowaną implementację uprawnień typu open source, aby wypróbować lub wdrożyć. Mimo że w wpisie w blogu opisano uprawnienia wszystkich pracowników, zespoły można zastosować jako koncepcję kodu do bardziej ściśle określonych scenariuszy zespołu deweloperów. Te zespoły programistyczne mogą nie być reprezentowane w schemacie organizacyjnym pracowników i obejmować zastrzeżone narzędzia lub usługi, które mogą komplikować dołączanie lub odłączanie członków zespołu.

Poniżej przedstawiono podsumowanie uproszczonej odmiany tego pomysłu, która używa systemu ciągłej integracji/ciągłego wdrażania i grup dostawców tożsamości do koordynowania aktualizacji:

W tym przykładzie:

Każdy zaangażowany system został skonfigurowany do korzystania z dostawcy tożsamości (na przykład Microsoft Entra ID) na potrzeby logowania jednokrotnego (SSO).
Użyjesz grup dostawców tożsamości (na przykład grup Entra) w różnych systemach, aby zarządzać członkostwem według roli, aby zmniejszyć złożoność i zachować scentralizowaną inspekcję.

Na wysokim poziomie poniżej przedstawiono sposób działania tego wzorca:

Centralne, zablokowane repozytorium git ma w nim zestaw plików (zazwyczaj YAML), które reprezentują każdy abstrakcyjny zespół, powiązane członkostwo użytkowników i role użytkowników. Właściciele lub osoby zatwierdzające dotyczące zmian zespołu mogą być również przechowywane w tym samym miejscu (na przykład za pośrednictwem WŁAŚCICIELI KODU). Odwołanie do użytkownika w tych plikach jest dostawcą tożsamości, ale to repozytorium działa jako źródło prawdy dla tych zespołów (ale nie użytkowników).
Wszystkie aktualizacje tych plików są wykonywane za pośrednictwem żądań ściągnięcia. Te konwersacje łączą się z powiązanymi uczestnikami żądania zatwierdzenia git w celu przeprowadzenia inspekcji.
Potencjalni klienci i indywidualni użytkownicy mogą tworzyć żądania ściągnięcia, aby dodawać/usuwać osoby, a potencjalni potencjalni klienci deweloperzy i inne role mogą tworzyć nowe zespoły przy użyciu żądania ściągnięcia, które mają nowy plik zespołu z szablonu.
Za każdym razem, gdy żądanie ściągnięcia zostanie scalone z głównym, system ciągłej integracji/ciągłego wdrażania powiązany z repozytorium aktualizuje system dostawcy tożsamości i wszystkie systemy podrzędne odpowiednio.

W szczególności system ciągłej integracji/ciągłego wdrażania:

Używa odpowiedniego interfejsu API systemu dostawcy tożsamości, aby utworzyć lub zaktualizować grupę dostawców tożsamości dla każdej roli z dokładnie osobami w pliku (nie więcej, nie mniej).
Używa interfejsów API dla każdego systemu podrzędnego, aby powiązać te koncepcje grupowania systemów do identyfikowania grup dostawców dla każdej roli (na przykład: GitHub i Azure DevOps). Może to spowodować relację jeden do wielu między zespołem a systemem podrzędnym reprezentującym rolę.
(Opcjonalnie) Używa interfejsów API dla każdego systemu podrzędnego do implementowania logiki uprawnień powiązanej z mechanizmem grupowania systemu.
Używa interfejsu API do aktualizowania zablokowanego magazynu danych z wynikami (w tym kojarzenie identyfikatorów zespołu systemu podrzędnego), które mogą być następnie używane dla dowolnego z wewnętrznie utworzonych systemów. W razie potrzeby można również przechowywać skojarzenia dla różnych reprezentacji systemowych identyfikatorów użytkowników dla tego samego użytkownika/konta dostawcy tożsamości.

Jeśli Twoja organizacja używa już czegoś takiego jak Entra Entitlement Management, możesz pominąć zarządzanie członkostwem w grupie z tego wzorca.

Twoje potrzeby i zasady mogą zmienić specyfikę, ale ogólny wzorzec można dostosować do dowolnej liczby odmian. Wszelkie wpisy tajne wymagane do integracji z dowolnymi systemami podrzędnymi są przechowywane w systemie ciągłej integracji/ciągłego wdrażania (na przykład w funkcji GitHub Actions, Azure Pipelines) lub w usłudze Azure Key Vault.

Używanie ręcznie lub zewnętrznie wyzwalanych, sparametryzowanych przepływów pracy

Niektóre problemy związane z samoobsługą, które można zidentyfikować, mogą nie sprzyjać używaniu plików w usłudze Git. Możesz też mieć interfejs użytkownika, którego chcesz użyć do obsługi samoobsługi.

Na szczęście większość systemów ciągłej integracji, w tym funkcji GitHub Actions i usługi Azure Pipelines, ma możliwość skonfigurowania przepływu pracy z danymi wejściowymi, które można następnie ręcznie wyzwalać za pośrednictwem interfejsów użytkownika lub interfejsów wiersza polecenia. Biorąc pod uwagę, że deweloperzy i powiązane role operacji prawdopodobnie znają te środowiska użytkownika, wyzwalacze ręczne mogą rozszerzyć wszystko jako wzorzec kodu, aby umożliwić automatyzację działań (lub zadań), które nie mają naturalnej reprezentacji pliku lub powinny być w pełni zautomatyzowane bez konieczności ściągnięcia procesu ściągnięcia.

System ciągłej integracji może zezwolić na wyzwalanie tych przepływów pracy lub potoków z własnych środowisk użytkownika za pośrednictwem interfejsu API. W przypadku funkcji GitHub Actions kluczem do wykonania tej pracy jest interfejs API REST Actions w celu wyzwolenia zdarzenia wysyłania przepływu pracy w celu wyzwolenia przebiegu 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. Niezależnie od tego, czy jest wyzwalany ręcznie, czy za pośrednictwem interfejsu API, każdy przepływ pracy może obsługiwać zestaw danych wejściowych, dodając konfigurację workflow_dispatch do pliku YAML przepływu pracy. Na przykład w ten sposób zestawy narzędzi portalu, takie jak Backstage.io współdziałają z funkcją GitHub Actions.

Przepływ pracy lub system zadań systemu ciągłej integracji/ciągłego wdrażania bez wątpienia śledzi działania, zgłasza stan kopii zapasowej i zawiera szczegółowe dzienniki, których mogą używać zarówno deweloperzy, jak i zespoły operacyjne, aby zobaczyć, co poszło nie tak. W ten sposób ma niektóre z tych samych zalet zabezpieczeń, inspekcji i widoczności co wszystko jako wzorzec kodu. Należy jednak pamiętać, że wszystkie akcje wykonywane przez te przepływy pracy lub potoki wyglądają jak tożsamość systemowa (na przykład jednostka usługi lub tożsamość zarządzana w identyfikatorze Entra firmy Microsoft) do systemów podrzędnych.

Będziesz mieć wgląd w to, kto inicjuje żądania w systemie ciągłej integracji/ciągłego wdrażania, ale należy ocenić, czy jest to wystarczająca ilość informacji i upewnij się, że ustawienia przechowywania ciągłej integracji/ciągłego wdrażania są zgodne z wymaganiami inspekcji w przypadkach, gdy te informacje są krytyczne.

W innych przypadkach zintegrowane narzędzia mogą mieć własne mechanizmy śledzenia, na których można polegać. Na przykład te narzędzia ciągłej integracji/ciągłego wdrażania prawie zawsze mają kilka dostępnych mechanizmów powiadomień, takich jak korzystanie z usługi Microsoft Teams lub kanału Slack , co pozwala zachować każdy, kto przesyła żądanie pobrania aktualizacji stanu, a kanał udostępnia nieformalny zapis tego, co się stało. Te same aparaty przepływów pracy są często zaprojektowane tak, aby integrować się z narzędziami operacyjnymi, aby dodatkowo rozszerzyć użyteczność tych wzorców.

Podsumowując, można zaimplementować automatyzację przy użyciu plików przechowywanych w repozytorium kontroli źródła dzięki elastyczności narzędzi ciągłej integracji/ciągłego wdrażania i wbudowanych środowisk użytkownika. Aby zobaczyć, jak wewnętrzne platformy deweloperów mogą używać tego podejścia jako punktu wyjścia bez naruszania bardziej zaawansowanych możliwości w czasie, zobacz Projektowanie podstaw samoobsługi dla deweloperów.

Automatyzowanie konfigurowania środowisk kodowania dla deweloperów

Innym typowym problemem w systemach inżynieryjnych jest uruchamianie i normalizacja środowiska kodowania deweloperów. Poniżej przedstawiono niektóre typowe problemy, o których można usłyszeć w tym obszarze:

W niektórych przypadkach może upłynąć kilka tygodni, aby deweloper mógł przejść do pierwszego żądania ściągnięcia. Jest to problematyczny obszar, gdy przenosisz deweloperów między załogami funkcji i projektami dość często (na przykład w organizacjach macierzowych), musisz zwiększyć wykonawców lub być w zespole, który znajduje się w fazie zatrudniania.
Niespójność między deweloperami i systemami ciągłej integracji może prowadzić do częstych problemów "działa na mojej maszynie", nawet w przypadku doświadczonych członków zespołu.
Eksperymentowanie i uaktualnianie platform, czasy uruchamiania i inne oprogramowanie może również przerwać istniejące środowiska deweloperskie i prowadzić do utraty czasu próby określenia dokładnie tego, co poszło nie tak.
W przypadku potencjalnych klientów deweloperów przeglądy kodu mogą spowalniać programowanie, ponieważ mogą wymagać zmiany konfiguracji w celu przetestowania i cofnięcia ich po zakończeniu przeglądu.
Członkowie zespołu i operatorzy muszą również poświęcić czas na zwiększenie powiązanych ról poza programowaniem (operatorzy, qa, business, sponsors), aby pomóc przetestować, zobaczyć postęp, szkolić role biznesowe i ewangelizować pracę, która wykonuje zespół.

Część utorowanych ścieżek

Aby pomóc rozwiązać te problemy, pomyśl o konfigurowaniu określonych narzędzi i narzędzi w ramach dobrze zdefiniowanych ścieżek utorowanych. Konfiguracja maszyny dewelopera skryptów może pomóc i można ponownie użyć tych samych skryptów w środowisku ciągłej integracji. Należy jednak rozważyć obsługę konteneryzowanych lub zwirtualizowanych środowisk deweloperskich ze względu na korzyści, jakie mogą zapewnić. Te środowiska kodowania można skonfigurować z wyprzedzeniem do specyfikacji organizacji lub projektu.

Wymiana i określanie wartości docelowej stacji roboczej w systemie Windows

Jeśli używasz systemu Windows lub chcesz wykonać pełną wirtualizację stacji roboczej (narzędzia klienckie i ustawienia systemu operacyjnego hosta oprócz ustawień specyficznych dla projektu), maszyny wirtualne zwykle zapewniają najlepszą funkcjonalność. Te środowiska mogą być przydatne w przypadku dowolnych elementów od tworzenia aplikacji klienckich systemu Windows do usługi systemu Windows lub zarządzania i obsługi pełnych aplikacji internetowych platformy .NET.

Metoda	Przykłady
Korzystanie z maszyn wirtualnych hostowanych w chmurze	Microsoft Dev Box to pełna opcja wirtualizacji stacji roboczej z systemem Windows z wbudowaną integracją z oprogramowaniem do zarządzania komputerami.
Korzystanie z lokalnych maszyn wirtualnych	Hashicorp Vagrant jest dobrą opcją i można użyć programu HashiCorp Packer do kompilowania obrazów maszyn wirtualnych zarówno dla niego, jak i usługi Dev Box.

Wirtualizacja obszaru roboczego i ukierunkowanie na system Linux

Jeśli używasz systemu Linux, rozważ opcję wirtualizacji obszaru roboczego. Te opcje koncentrują się mniej na zastępowaniu pulpitu dewelopera i nie tylko na obszarach roboczych specyficznych dla projektu lub aplikacji.

Metoda	Przykłady
Korzystanie z kontenerów hostowanych w chmurze	GitHub Codespaces to oparte na chmurze środowisko dla usługi Dev Containers, które obsługuje integrację z programem VS Code, narzędziami IntelliJ firmy JetBrains i narzędziami opartymi na terminalach. Jeśli ta lub podobna usługa nie spełnia Twoich potrzeb, możesz użyć obsługi protokołu SSH lub zdalnych tuneli programu VS Code z użyciem usługi Dev Containers na zdalnych maszynach wirtualnych z systemem Linux. Opcja oparta na tunelu, która nie tylko współpracuje z klientem, ale vscode.dev sieci Web.
Korzystanie z kontenerów lokalnych	Jeśli wolisz zamiast tego lokalną opcję Dev Containers lub oprócz hostowanej w chmurze, kontenery deweloperskie mają solidną obsługę w programie VS Code, obsługę funkcji IntelliJ i innych narzędzi i usług.
Korzystanie z maszyn wirtualnych hostowanych w chmurze	Jeśli okaże się, że kontenery są zbyt ograniczone, obsługa protokołu SSH w narzędziach, takich jak PROGRAM VS Code lub JetBrains, takich jak IntelliJ, umożliwia bezpośrednie łączenie się z maszynami wirtualnymi z systemem Linux, którymi zarządzasz samodzielnie. Program VS Code ma również opcję opartą na tunelu.
Korzystanie z Podsystem Windows dla systemu Linux	Jeśli deweloperzy są wyłącznie w systemie Windows, Podsystem Windows dla systemu Linux (WSL) to doskonały sposób, aby deweloperzy mogli korzystać z systemu Linux lokalnie. Możesz wyeksportować dystrybucję WSL dla zespołu i udostępnić ją wszystkim skonfigurowanym elementom. W przypadku opcji chmury usługi stacji roboczej w chmurze, takie jak Microsoft Dev Box, mogą również korzystać z usługi WSL w celu programowania w systemie Linux.

Tworzenie odpowiednich szablonów aplikacji, które zawierają odpowiednią konfigurację

Wielką rzeczą w tym wszystkim, jak wzorzec kodu, jest to, że może ona zachować deweloperów na utorowanych ścieżkach, które zostały ustanowione od początku. Jeśli jest to wyzwanie dla organizacji, szablony aplikacji mogą szybko stać się krytycznym sposobem ponownego użycia bloków konstrukcyjnych w celu zapewnienia spójności, promowania standaryzacji i skodyfikowania najlepszych rozwiązań organizacji.

Aby rozpocząć, możesz użyć czegoś tak prostego , jak repozytorium szablonów Usługi GitHub, ale jeśli twoja organizacja jest zgodna ze wzorcem monorepo , może to być mniej skuteczne. Możesz również utworzyć szablony, które ułatwiają skonfigurowanie czegoś, co nie jest bezpośrednio związane z drzewem źródłowym aplikacji. Zamiast tego można użyć aparatu tworzenia szablonów, takiego jak cookiecutter, Yeoman lub coś takiego jak interfejs wiersza polecenia dla deweloperów platformy Azure (azd), który oprócz tworzenia szablonów i uproszczonej konfiguracji ciągłej integracji/ciągłego wdrażania zapewnia również wygodny zestaw poleceń deweloperów. Ponieważ interfejs wiersza polecenia dla deweloperów platformy Azure może służyć do obsługi konfiguracji środowiska we wszystkich scenariuszach, integruje się ze środowiskami wdrażania platformy Azure, aby zapewnić lepsze zabezpieczenia, zintegrowaną IaC, śledzenie środowiska, separację problemów i uproszczoną konfigurację ciągłego wdrażania.

Po utworzeniu zestawu szablonów potencjalni klienci deweloperzy mogą używać tych narzędzi wiersza polecenia lub innych zintegrowanych środowisk użytkownika do tworzenia szkieletu zawartości aplikacji. Jednak ze względu na to, że deweloperzy mogą nie mieć uprawnień do tworzenia repozytoriów lub innej zawartości z szablonów, jest to również kolejna okazja do korzystania z wyzwalanych ręcznie, sparametryzowanych przepływów pracy/potoków. Możesz skonfigurować dane wejściowe, aby system ciągłej integracji/ciągłego wdrażania utworzył dowolne elementy z repozytorium do infrastruktury w ich imieniu.

Pozostawanie w prawo i uzyskiwanie właściwego

Jednak w celu ułatwienia skalowania te szablony aplikacji powinny odwoływać się do scentralizowanych bloków konstrukcyjnych tam, gdzie to możliwe (na przykład szablonów IaC, a nawet przepływów pracy ciągłej integracji/ciągłego wdrażania/potoków). W rzeczywistości traktowanie tych scentralizowanych bloków konstrukcyjnych jako własnej formy szablonów początkowych może być skuteczną strategią rozwiązywania niektórych zidentyfikowanych problemów.

Każdy z tych szablonów można zastosować nie tylko do nowych aplikacji, ale także istniejących, które zamierzasz zaktualizować w ramach kampanii get right, aby wdrożyć zaktualizowane lub ulepszone wytyczne. Jeszcze lepiej, ta centralizacja pomaga zachować prawo zarówno nowych, jak i istniejących aplikacji, co pozwala rozwijać lub rozszerzać najlepsze rozwiązania w czasie.

Zawartość szablonu

Zalecamy rozważenie następujących obszarów podczas tworzenia szablonów.

Obszar	Szczegóły
Wystarczająca ilość przykładowego kodu źródłowego do obsługi wzorców aplikacji, zestawów SDK i narzędzia	Uwzględnij kod i konfigurację, aby kierować deweloperów do zalecanych języków, modeli aplikacji i usług, interfejsów API, zestawów SDK i wzorców architektury. Pamiętaj, aby dołączyć kod do śledzenia rozproszonego, rejestrowania i możliwości obserwowania przy użyciu wybranego narzędzia.
Skrypty kompilacji i wdrażania	Zapewnij deweloperom wspólny sposób wyzwalania kompilacji i lokalnego/wdrożenia piaskownicy. Uwzględnij konfigurację debugowania w środowisku IDE/edytorze, aby można było z nich korzystać. Jest to ważny sposób, aby uniknąć bólów głowy konserwacji i zapobiec braku synchronizacji ciągłej integracji/ciągłego wdrażania. Jeśli aparat tworzenia szablonów jest opiniowany jak interfejs wiersza polecenia dla deweloperów platformy Azure, mogą już być polecenia, których można po prostu użyć.
Konfiguracja ciągłej integracji/ciągłego wdrażania	Podaj przepływy pracy/potoki do kompilowania i wdrażania aplikacji na podstawie zaleceń. Korzystaj ze scentralizowanych, wielokrotnego użytku lub szablonowych przepływów pracy/potoków, aby ułatwić aktualizowanie tych przepływów pracy. W rzeczywistości te przepływy pracy wielokrotnego użytku / potoki mogą być uruchamiane we własnych szablonach. Pamiętaj, aby rozważyć opcję ręcznego wyzwalania tych przepływów pracy.
Infrastruktura jako zasoby kodu	Podaj zalecane konfiguracje IaC, w tym odwołania do centralnie zarządzanych modułów lub elementów wykazu, aby upewnić się, że każda konfiguracja infrastruktury jest zgodna z najlepszymi rozwiązaniami z programu get-go. Te odwołania mogą również pomóc zespołom zachować rację w miarę upływu czasu. W połączeniu z przepływami pracy/potokami można również uwzględnić IaC lub EaC, aby aprowizować niemal wszystko.
Zabezpieczenia i zasady jako zasoby kodu	Ruch DevSecOps przeniósł konfigurację zabezpieczeń do kodu, który doskonale nadaje się do szablonów. Niektóre zasady jako artefakty kodu można również stosować na poziomie aplikacji. Dołącz jako wszystko, od plików, takich jak CODEOWNERS do skanowania konfiguracji, takiej jak dependabot.yaml w usłudze GitHub Advanced Security. Udostępnianie zaplanowanych przepływów pracy/przebiegów potoków na potrzeby skanowania przy użyciu czegoś takiego jak Defender dla Chmury wraz z przebiegami testów środowiska. Jest to ważne dla bezpieczeństwa łańcucha dostaw i pamiętaj, aby uwzględnić obrazy kontenerów oprócz pakietów aplikacji i kodu. Te kroki pomagają zespołom deweloperów zachować rację.
Możliwość obserwowania, monitorowanie i rejestrowanie	Częścią włączania samoobsługi jest zapewnienie łatwego wglądu w aplikacje po wdrożeniu. Poza infrastrukturą środowiska uruchomieniowego należy uwzględnić konfigurację w celu obserwowania i monitorowania. W większości przypadków istnieje aspekt IaC do skonfigurowania (na przykład wdrożenie agenta, instrumentacja), podczas gdy w innych przypadkach może to być inny typ artefaktu kodu konfiguracji (na przykład monitorowanie pulpitów nawigacyjnych dla usługi aplikacja systemu Azure Insights). Na koniec pamiętaj, aby dołączyć przykładowy kod do śledzenia rozproszonego, rejestrowania i możliwości obserwowania przy użyciu wybranego narzędzia.
Konfiguracja środowiska kodowania	Dołącz pliki konfiguracyjne do kodowania linters, formaterów, edytorów i środowisk IDE. Uwzględnij skrypty konfiguracji wraz z plikami wirtualizacji obszaru roboczego lub stacji roboczej, takimi jak devcontainer.json, devbox.yaml, pliki Docker Compose skoncentrowane na deweloperach, pliki Docker Compose lub pliki Vagrantfile.
konfiguracja testowa	Udostępnianie plików konfiguracji zarówno do testowania jednostkowego, jak i bardziej szczegółowego przy użyciu preferowanych usług, takich jak Microsoft Playwright Testing for UI lub Azure Load Testing.
Konfiguracja narzędzia do współpracy	Jeśli twój problem z zarządzaniem i systemem zarządzania kontrolą źródła obsługuje zadania/ problem / szablony żądania ściągnięcia jako kod, uwzględnij je również. W przypadkach, gdy wymagana jest większa konfiguracja, możesz opcjonalnie udostępnić przepływ pracy/potok, który aktualizuje systemy przy użyciu dostępnego interfejsu wiersza polecenia lub interfejsu API. Umożliwia to również skonfigurowanie innych narzędzi do współpracy, takich jak Microsoft Teams lub Slack.