Stosowanie systemów inżynierii oprogramowania

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 zastosowania najlepszych praktyk w szablonach, które pomagają poprawnie rozpocząć pracę i skutecznie na niej działać.

Ocena podstawowych rozwiązań DevOps i DevSecOps

Systemy inżynieryjne są krytycznym aspektem wewnętrznej platformy deweloperów. Wewnętrzne platformy deweloperów opierają się na głównych zasadach DevOps i DevSecOps w celu redukcji obciążenia poznawczego dla wszystkich zaangażowanych.

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 zafunkcjonalizowanymi rolami, takimi jak rozwój, 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 spajają tę pętlę z ciągłymi praktykami zabezpieczeń w całym procesie rozwoju aplikacji.

Poniższe sekcje koncentrują się na ulepszeniach bardziej bezpośrednio przypisywanych ruchowi inżynierii platform: utorowane ścieżki, automatyczne dostarczanie infrastruktury (oprócz wdrażania aplikacji), konfiguracja środowiska kodowania wraz z samoobsługowym dostarczaniem 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ą następnie 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, aby z czasem rozważyć możliwe włączenie do ustalonej ścieżki. Jak ujął to jeden z liderów inżynierów platformy:

Nadal możesz robić swoje, ale w kierunku, w którym idziemy... możesz zmienić wszystko, co chcesz, ale staje się to twoim obowiązkiem. Jesteś odpowiedzialny za zmiany — jesteś odpowiedzialny za ostre noże. - Mark, lider inżynierii platformy, duża międzynarodowa firma detaliczna w Europie

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 uszczegóławiania utorowanych ścieżek, pozostawienie pewnej elastyczności umożliwia zespołom wnoszenie wkładu i rozwiązywanie naprawdę unikalnych wymagań dla danej aplikacji bez wpływu na inne aplikacje 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 zadania robocze wykonywane przez zespoły powodują, że naturalnie chcą przejść do popieranej ścieżki w czasie.

Jeśli wolisz strategię konsolidacji, migrowanie istniejących aplikacji może wymagać więcej pracy niż oczekiwano, więc na początek prawdopodobnie zechcesz skupić się na odpowiednim rozpoczęciu w tym obszarze i skoncentrować się na nowych projektach. Zapewnia to pierwszą utorowaną ścieżkę, podczas gdy wszystko inne z natury pozostaje nieutwardzone. Zespoły programistyczne na nieutwardzonej ścieżce mogą następnie rozważyć przejście, kiedy nowa utwardzona ścieżka pokaże swoją wartość dla organizacji. W tym momencie możesz uruchomić kampanię dostosowawczą, aby doprowadzić wszystkich do pożądanego stanu poprzez dwukierunkową komunikację, ponieważ zespoły deweloperów postrzegają to jako korzyść, 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 utwardzonych ścieżek jest podkreślenie korzyści, jakie z nich zespoły mogą uzyskać, a nie poprzez wymuszonego przyjęcia. Ponieważ wewnętrzna platforma deweloperów koncentruje się na tym, aby usatysfakcjonować te same zespoły, budżet i nacisk na czas realizacji nakładany na poszczególnych liderów dba o resztę. Uzyskaj odpowiednie kampanie, a następnie stwórz możliwość do dwukierunkowych rozmów, aby w najlepszy sposób pomóc tym na nieutwardzonej ścieżce w przejściu.

Użyj narzędzi automatyzacji dla programistów, aby ulepszyć samoobsługę na utorowanych ścieżkach

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

Włącz automatyczne zapewnianie infrastruktury aplikacyjnej podczas ciągłego wdrażania

Jeśli jeszcze nie wdrożono, problemy zidentyfikowane podczas planowania prawdopodobnie wskazują na problemy, które ciągła integracja (CI) i ciągłe dostarczanie (CD) mogą pomóc rozwiązać. 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 już zaimplementowałeś 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 CD.

Rozważmy na przykład poniższe 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: jedno przy użyciu wdrożeń opartych na wypychaniu i jedno wdrożenia oparte na ściąganiu (GitOps).

Twój wybór zależy od posiadanych umiejętności w zakresie IaC oraz szczegółów docelowej platformy aplikacji. 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, zapoznanie się z praktykami IaC może pomóc w nauce wzorców, które mają zastosowanie do dalszych scenariuszy automatyzacji.

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

Aby efektywnie zarządzać IaC i skalować je w różnych aplikacjach, należy artefakty IaC publikować w sposób centralny, umożliwiając ich ponowne użycie. Można na przykład użyć modułów Terraform w rejestrze, Bicep modułów, przepisach Radius lub wykresów Helm, przechowywanych w natywnym dla chmury rejestrze artefaktów OCI, takich jak Azure Container Registry (ACR),DockerHub lub katalogu w Azure Deployment Environments (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 Operator usługi Platformy Azure , mogą zapewnić dodatkową obsługę innych rodzajów zasobów platformy Azure. Inne narzędzia, takie jak crossplane , obsługują zasoby w wielu chmurach. Umożliwiają one korzystanie ze scentralizowanych lub wspólnych chartów Helm w czymś takim jak ACR dla szerszego zakresu 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. Aby dowiedzieć się więcej o zaletach i wadach różnych modeli, zobacz Opis typów usług w chmurze. 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.

Zachowywanie wszelkich potrzebnych tożsamości aprowizacji lub wpisów tajnych w sposób, który uniemożliwia deweloperom bezpośredni dostęp do nich, stanowi podstawowy element ł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. Działy operacyjne 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 zarządzania zasobami.

** Deweloperzy lub pipeline CI/CD mogą następnie użyć Azure CLI lub Azure Developer CLI do aprowizacji wstępnie skonfigurowanej i kontrolowanej infrastruktury, nawet bez dostępu do wymaganej subskrypcji lub tożsamości. 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 pewnym aktualizowaniu infrastruktury poprzez oddzielenie tajnych informacji i pozyskiwanie zawartości IaC z lokalizacji, które są niedostępne dla deweloperów i których nie mogą samodzielnie modyfikować.

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 wewnętrzni użytkownicy chcą udostępniać, nie wiąże się bezpośrednio z konkretną 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 wersji i procesy pull requestów?
• 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 wdrożyć, ponieważ niosą mniejsze ryzyko przed przejściem do bardziej złożonych?

Identyfikowanie częstych, wysokowydajnych lub podatnych na błędy procesów jako potencjalnych celów do automatyzacji.

Używaj wzorca "wszystko jako kod"

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ą zatwierdzeń 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 oraz automatycznych testów, które muszą przejść pomyślnie przed scaleniem z gałęzią główną. W połączeniu z elastycznymi silnikami zadań, takimi jak te znajdujące się w systemach ciągłej integracji/ciągłego wdrażania, tworzysz 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ć, a nie tylko te powiązane z określoną aplikacją. Na przykład udostępnione klastry Kubernetes z zainstalowanym rozwiązaniem Flux, aprowizowanie elementów takich jak DataDog , które są używane przez wiele zespołów i aplikacji, a nawet konfigurowanie ulubionych narzędzi do współpracy.

W ten sposób działa oddzielne, zabezpieczone scentralizowane repozytorium zawierające serię plików reprezentujących, co należy aprowizować i skonfigurować (w tym przypadku wszystko, od Bicep lub Terraform, do wykresów Helm i innych formatów natywnych Kubernetes). Zespół operacyjny lub inny zestaw administratorów jest właścicielem repozytorium, a deweloperzy (lub systemy) mogą przesyłać żądania ściągnięcia (PRs). Po scaleniu tych pull requestów z gałęzią główną przez administratorów, te same narzędzia CI/CD używane podczas tworzenia aplikacji mogą rozpocząć przetwarzanie zmian. Rozważmy poniższą ilustrację przedstawiającą tożsamości usługi GitHub Actions, IaC i wdrożenia, 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, powtarzalne 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 tajemnice lub zarządzane tożsamości są przechowywane w silniku pipeline/przepływu pracy lub w natywnych funkcjonalnościach usługi zapewniania.

Ponieważ osoby tworzące żądania ściągnięcia nie mają bezpośredniego dostępu do tych tajnych danych, umożliwia to deweloperom bezpieczne inicjowanie działań, do których samodzielnego wykonywania nie mają bezpośredniego uprawnienia. Dzięki temu można stosować się do zasady najniższych uprawnień, jednocześnie zapewniając deweloperom opcję samoobsługi.

Śledzenie dostarczonej infrastruktury

Gdy zaczniesz skalować to podejście, zastanów się, jak chcesz śledzić aprowizowaną infrastrukturę. Repozytorium Git jest wiarygodnym źródłem dla konfiguracji, ale nie dostarcza informacji o określonych identyfikatorach URI oraz stanie tego, co zostało utworzone. Jednak przyjęcie podejścia 'everything as code' daje możliwość wykorzystania źródła informacji do stworzenia spisu aprowizowanej infrastruktury. Dostawca może być również dobrym źródłem tych informacji, do których możesz sięgnąć. 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ż udostępnianie infrastruktury jest przydatne, upewnienie się, że te środowiska są bezpieczne i ogólnie zgodne z zasadami organizacji, jest równie ważne. Doprowadziło to do powstania koncepcji polityki 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 doprecyzowania aplikacji i zarządzania, zobacz Doprecyzuj swoją platformę aplikacyjną.

Wykorzystaj wszystko jako kod we własnych scenariuszach

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.

Pull request staje się dobrą podstawową samoobsługową obsługą użytkownika dla różnych procesów, szczególnie gdy zaczynasz pracę. Procesy naturalnie zyskują na bezpieczeństwie, audytowalności i korzyściach z wycofywania zapewnianych przez Git jako taki, a zaangażowane systemy mogą również ulegać zmianom w czasie bez wpływu na doświadczenie użytkownika.

Zespoły jako kod

Przykładem zastosowania zasady 'wszystko jako kod' do własnych scenariuszy jest wzorzec 'zespoły jako kod'. 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 procesy biura obsługi związane z przyłączaniem i odłączaniem, wynikające z potrzeby twórców i operatorów systemów do uzyskania dostępu do własnych pojęć grupowania, użytkowników i dostępów. Procesy obsługi manualnej stanowią potencjalne zagrożenie bezpieczeństwa, ponieważ istnieje możliwość nadmiernego przydzielania dostępu. W przypadku korzystania z zespołów jako wzorca kodu kombinacja usług Git i żądania ściągnięcia mogą 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. GitHub także udostępnił jako open-source swoją zaawansowaną implementację uprawnień, aby to przetestować lub zaimplementować. Mimo że we wpisie na blogu opisano uprawnienia wszystkich pracowników, koncepcję zespołów jako kodu można zastosować 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.
• Używasz grup dostawców tożsamości (na przykład grup Entra) w systemach do zarządzania członkostwem według roli, aby zmniejszyć złożoność i utrzymać zunifikowany audyt.

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 odpowiedzialne za zatwierdzanie zmian w zespole mogą być również przechowywane w tym samym miejscu (na przykład za pośrednictwem CODEOWNERS). Odwołanie do użytkownika w tych plikach odnosi się do dostawcy tożsamości, jednak to repozytorium stanowi źródło prawdy dla tych zespołów (ale nie dla użytkowników).
• Wszystkie aktualizacje tych plików są wykonywane za pośrednictwem żądań pull. To wiąże konwersacje i powiązanych uczestników na żądanie zatwierdzenia usługi Git w celu przeprowadzenia inspekcji.
• Liderzy i indywidualni użytkownicy mogą tworzyć pull requesty, aby dodawać lub usuwać osoby, a liderzy deweloperów i inne role mogą przy użyciu pull requestów tworzyć nowe zespoły z nowego pliku zespołu skonstruowanego na podstawie 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/CD:

• 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 do powiązania koncepcji 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 przy użyciu wyników (w tym kojarzenia 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 Zarządzanie upoważnieniami Entra, 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 sekrety niezbędne do integracji z różnymi systemami podrzędnymi są przechowywane w systemie CI/CD (na przykład w systemie GitHub Actions lub Azure Pipelines) lub czymś takim jak 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 GitHub Actions i Azure Pipelines, ma możliwość skonfigurowania workflowu z parametrami wejściowymi, które można następnie ręcznie uruchamiać za pośrednictwem interfejsów użytkownika lub interfejsów wiersza poleceń. Biorąc pod uwagę, że deweloperzy i powiązane role operacyjne prawdopodobnie już znają te doświadczenia użytkownika, wyzwalacze ręczne mogą wzmocnić wzorzec 'wszystko jako kod', aby umożliwić automatyzację działań (lub zadań), które nie mają naturalnej reprezentacji plików lub powinny być w pełni zautomatyzowane bez wymagania procesu przeglądu żądań ściągnięcia (PR).

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 GitHub Actions kluczem do uruchomienia tej konfiguracji jest interfejs REST API Actions do wyzwolenia zdarzenia uruchomienia przepływu pracy umożliwiającego uruchomienie przebiegu przepływu pracy. Wyzwalacze Azure DevOps są podobne, a także można używać API Pipelines w ramach 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ń w systemie CI/CD bez wątpienia śledzi działania, zgłasza status oraz posiada szczegółowe logi, z których mogą korzystać 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ń, przeglądu i widoczności co wzorzec 'wszystko jako kod'. Należy jednak pamiętać, że wszystkie akcje wykonywane przez te przepływy pracy lub potoki wyglądają jak tożsamość systemu (na przykład zasada usługi lub tożsamość zarządzana w Microsoft Entra ID) w stosunku 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/CD prawie zawsze oferują kilka mechanizmów powiadomień, jak wykorzystanie kanału Microsoft Teams lub Slack, co umożliwia każdemu, kto przesyła żądanie, otrzymanie aktualizacji statusu. Kanał ten również zapewnia nieformalny zapis wydarzeń. Te same silniki przepływów pracy często są już zaprojektowane do integracji z narzędziami operacyjnymi, co pozwala dodatkowo zwiększyć 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 deweloperskie mogą wykorzystywać to podejście jako punkt wyjścia, nie rezygnując z bardziej zaawansowanych funkcji w czasie, zobacz Tworzenie fundamentu samoobsługowego 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 minąć kilka tygodni, zanim deweloper złoży swój pierwszy wniosek o zmianę. Jest to problematyczny obszar, gdy przenosisz deweloperów między zespołami funkcjonalnymi i projektami dość często (na przykład w organizacjach macierzowych), musisz przyspieszyć wdrażanie wykonawców lub pracujesz w zespole, który jest w fazie zatrudniania.
• Niespójność między deweloperami, zarówno między sobą, jak i z twoimi systemami CI, może prowadzić do częstych problemów typu "działa u mnie", 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.
• Dla liderów zespołów deweloperskich przeglądy kodu mogą spowalniać rozwój, ponieważ mogą wymagać zmiany konfiguracji w celu testowania oraz przywrócenia ustawień po zakończeniu przeglądu.
• Członkowie zespołu i operatorzy muszą również poświęcić czas na rozszerzenie ról związanych z działalnością poza programowaniem (operatorzy, QA, biznes, sponsorzy), aby pomóc przetestować, zobaczyć postęp, szkolić role biznesowe i promować pracę zespołu.

Część twoich utwardzanych ścieżek

Aby pomóc rozwiązać te problemy, pomyśl o konfigurowaniu określonych narzędzi i programów w ramach dobrze zdefiniowanych wytyczonych ścieżek. 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.

Zastąpienie stacji roboczej z ukierunkowaniem na 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.

Wirtualizacja obszaru roboczego i ukierunkowanie na system Linux

Jeśli używasz systemu Linux, rozważ opcję wirtualizacji obszaru roboczego. Te opcje mniej skupiają się na zastępowaniu pulpitu dewelopera, a bardziej na przestrzeniach roboczych specyficznych dla projektu lub aplikacji.

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

Wspaniałą rzeczą w wzorcu 'wszystko jako kod' jest to, że może utrzymać deweloperów na wyznaczonych ś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 szablonowe 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 czegoś takiego jak Azure Developer CLI (azd), które oprócz tworzenia szablonów i uproszczonej konfiguracji oprogramowania CI/CD zapewnia również wygodny zestaw poleceń dla programistó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, liderzy zespołów deweloperów mogą używać narzędzi wiersza poleceń lub innych zintegrowanych środowisk użytkowników do tworzenia szkieletów treści dla swoich 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 lub 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 poprawnym i uzyskiwanie właściwego rezultatu

Jednak w celu ułatwienia skalowania te szablony aplikacji powinny odwoływać się do scentralizowanych komponentów, tam gdzie to możliwe (na przykład szablonów IaC, a nawet przepływów pracy i potoków CI/CD). 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 utrzymać prawidłowe działanie zarówno nowych, jak i istniejących aplikacji, co pozwala rozwijać lub rozszerzać najlepsze praktyki w czasie.

Zawartość szablonu

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

Treści powiązane

• Centrum zasobów DevOps firmy Microsoft
• Ramowa Struktura Bezpiecznego Łańcucha Dostaw Kontenerów
• Podstawowa architektura CI/CD z użyciem Azure Pipelines
• Uściślij platformę aplikacji