Dela via

Överväganden för plattformsautomatisering för Red Hat Enterprise Linux i Azure

  • Artikel

Den här artikeln beskriver hur du hanterar automatisering för Red Hat Enterprise Linux (RHEL) i Azure. Den beskriver designöverväganden, designrekommendationer och alternativ för olika verktyg i Azure-ekosystemet som du kan använda för att uppnå en konsekvent och stabil miljö. Den här artikeln innehåller vägledning som överensstämmer med olika kundscenarier, affärskrav, operativa metoder och teknisk mognad.

Översikt

När du automatiserar RHEL för Azure-landningszoner använder du Red Hat Infrastructure Standard (RH-IS) och den associerade Red Hat Infrastructure Standard Adoption Model (RH-ISAM) för att justera livscykelhanteringen i Azure-landningszonen. Standardisera system för att ge en tillförlitlig grund för lösningen. RH-IS definierar den standardoperativmiljö som utgör standarduppsättningen av programvarukomponenter och konfigurationer. Du kan tillämpa dessa komponenter och konfigurationer på system via RH-ISAM, en uppsättning DevOps- eller Git-åtgärdsprinciper, Azure Resource Manager-mallar (ARM-mallar), Terraform, Azure CLI och Azure PowerShell.

Du kan automatisera olika åtgärder. Du kan till exempel använda automatisering för att:

  • Etablera komponenter.
  • Hantera system.
  • Utföra plattformsutveckling.
  • Införliva infrastrukturåtgärder.
  • Konfigurera program- och arbetsbelastningslivscykler.

Du kan implementera dessa åtgärder via infrastruktur som kod (IaC) och konfiguration som kod. Definiera och testa konfigurationer för att minska fel och öka tillförlitligheten. Automatisera etableringen för att påskynda massmigrering. Automatiserade konfigurationer minskar konfigurationsavvikelserna och säkerställer att systemen fungerar korrekt.

Utformningsbeaktanden

Red Hat Identity Management (IdM) tillhandahåller en centraliserad och enhetlig plattform som du kan använda för att hantera identitetslager, autentiseringsprinciper och auktoriseringsprinciper för RHEL-system. I ett hybridscenario kan du utöka din befintliga Red Hat IdM-infrastruktur i ett virtuellt privat nätverk eller Azure ExpressRoute. Den här konfigurationen ansluter lokala miljöer till RHEL-landningszonen i Azure. För att stödja hybridmolnidentitetsscenarier utökar du din lokala miljö till Azure så att du kan integrera dina arbetsbelastningar med Microsoft Entra. Mer information finns i Microsoft Entra-autentisering.

Som en alternativ lösning för identitetshantering kan du ansluta till RHEL för att skapa ett externt förtroende med Windows Server Active Directory eller ansluta direkt till en befintlig Windows Server Active Directory-skog. Mer information finns i Integrera RHEL-system direkt med Windows Server Active Directory.

Red Hat Satellite är den enda innehållskällan som levereras till hanterade RHEL-system. Satellit innehåller Red Hat-paket och korrigeringar samt paket som inte kommer från Microsoft och anpassade paket som utvecklar programutvecklingsteam. Satellit fungerar som gateway till Red Hat Insights, som erbjuder förutsägande analys av konfigurationer för att identifiera säkerhets- eller prestandarisker. Om du distribuerar förkonfigurerade RHEL-betala per användning-avbildningar kan du dra nytta av Red Hat Update-infrastrukturen för Azure, som är ett uppdateringsverktyg som är inbyggt i avbildningarna betala per användning.

Designöverväganden för Red Hat Ansible Automation Platform

Red Hat Ansible Automation Platform (AAP) hjälper till att standardisera tekniska arbetsflöden och återkommande uppgifter. Du kan använda AAP för att samordna arbetsflöden, etablera processer för nya system och skapa återkommande operativa uppgifter. För att minska komplexiteten använder du en gemensam automatiseringsplattform och ett gemensamt språk. Helt automatiserade arbetsflöden påskyndar programinnovationen och förenklar massarbetsbelastningsmigreringar i lokala miljöer och molnmiljöer.

Fördelarna med RHEL som en strategi för plattformsautomatisering är:

  • Nya system har helt automatiserad etablering i stor skala, vilket förbättrar massmigreringshastigheten.

  • Ökad enhetlighet i de testade systemens konfigurations- och programinstallationer i fysiska system och virtuella system.

  • Kontinuerliga uppdateringar eftersom korrigeringshantering är omedelbart tillgänglig.

  • En standardiserad och förenklad plattform för att leverera nya program och arbetsbelastningar. Personalen har extra tid att leverera ökad innovation.

Du kan implementera:

  • En självhanterad AAP-instans via lokal infrastruktur, molninfrastruktur eller både och. Du kan använda en RHEL-distribution eller en Distribution av Red Hat OpenShift Container Platform.

  • En självhanterad AAP-instans i ett offentligt moln.

  • En hanterad AAP-instans i ett offentligt moln.

Självhanterad Red Hat AAP lokalt eller i molnet

Distribuera Red Hat AAP på Microsoft Azure i självhanterat läge i en lokal infrastruktur, molninfrastruktur eller hybridinfrastruktur för att få följande fördelar:

  • Arkitektur och skalning: Bestäm din idealiska arkitektur för att stödja automationsplattformen. Du kan basera arkitekturen på RHEL-infrastruktur eller en OpenShift-operatörsdistribution. Baserat på storleken och kraven för din vagnpark väljer du antalet och instansstorleken för kontrollanter, körningsnoder och privata automationshubbinstanser. Mer information om arkitektur, design, konfiguration och skalning finns i planeringsguiden för Red Hat AAP.

  • Azure-konfiguration: Optimera automatiseringsarkitekturen för din organisations Azure-design och -konfiguration.

  • Stöd för automationsnät: Använd funktionen AAP automation mesh för att distribuera automationsarbetsbelastningar mellan hybridmolnnoder som upprättar peer-to-peer-anslutningar med hjälp av befintliga nätverk. Placera hoppnoder på en plats baserat på dina kriterier för säkerhetsdesign och nätverkstopologi.

  • Automation Hub-arkitektur: Optimera en automationshubbsarkitektur för skalning och placering av privata automationshubbar. Optimera konfigurationer för att förbättra säker automatiseringsinnehållsleverans och åtkomst till körningsmiljökällor som ligger nära automationskörningsresurser. Du kan välja vilka Ansible-innehållssamlingar och versioner som automationskonsumenter kan komma åt.

Hanterad eller självhanterad Red Hat AAP i Azure

Red Hat AAP på Microsoft Azure är tillgängligt via ett hanterat program eller ett självhanterat program, vilket ger följande fördelar:

  • En snabb avkastning på investeringen (ROI) på grund av enkel användning: Du kan distribuera AAP på Azure direkt från Azure Marketplace. Den här hanterade lösningen är aktiv direkt efter distributionen och du kan börja automatisera hanteringen av dina Azure-resurser på några minuter. Red Hat hanterar infrastrukturen, så du kan tänka på andra system som är viktiga för ditt företag.

  • Effektiviserad integrering: AAP i Azure är integrerat med Azure-tjänster. Microsoft och Red Hat har utvecklat och säkerhetstestat Ansible-samlingen för Azure, så du behöver minimal konfiguration och får maximal support. Använd AAP i Azure som en del av din strategi för hybridmolnautomatisering för att förena hantering och automatisering i hybridmoln, Sakernas Internet och gränsdistributioner.

  • Befintliga incheckade Azure-utgifter: Du kan använda befintliga åtaganden med Microsoft för att köpa Red Hat AAP på Azure. Använd engagerade utgifter så att team i hela organisationen kan distribuera, konfigurera och automatisera komponenter sömlöst. Integrerad fakturering innebär att du får en faktura och fullständig insyn i kostnaden.

  • Automatisering utanför molnet: Med AAP i Azure kan du distribuera program i ditt Microsoft Azure-moln och sedan utöka dem i infrastrukturen. Distribuera, köra och skala program i Azure- och hybridmolnmiljöer.

  • Support: Red Hat och Microsoft samarbetar för att bygga AAP på Azure för att säkerställa konsekventa, säkerhetsfokuserade åtgärder. Red Hat hanterar, tjänster och stöder programmet så att IT-teamet kan fokusera på att leverera automatiseringsstrategier.

Andra överväganden för hanterat läge

Du kan installera AAP på Azure i hanterat läge så att det är ett hanterat program. Red Hat hanterar både de underliggande Azure-resurserna och den programvara som körs på den. Infrastrukturen körs i din Azure-klientorganisation.

Resursgruppen för hanterade program är separat från andra resursgrupper i din klientorganisation. Red Hat har endast åtkomst till resursgruppen för hanterade program, utan insyn i andra klientresurser.

Mer information finns i Översikt över azure-hanterade program.

AAP i Azure i hanterat läge använder följande resursgrupper:

  • En ny eller befintlig resursgrupp i din klientorganisation. Den här resursgruppen innehåller en enskild resurs som refererar till AAP i azure-hanterad programdistribution. Red Hat har åtkomst till den hanterade appen för att utföra support, underhåll och uppgraderingar. Men Red Hat hanterar inte resursgruppen.

  • En hanterad resursgrupp för flera klientorganisationer (MRG) som innehåller merparten av den infrastruktur som krävs för att köra AAP på Azure. Red Hat-klientorganisationen och din klientorganisation delar den här resursgruppen för flera klienter. Red Hat har fullständig administrativ kontroll. Du har skrivskyddad åtkomst till resursgruppen.

  • En resursgrupp för Azure Kubernetes Service (AKS)-nodpool (NPRG). Microsoft kräver en NPRG för AKS-distributioner. En NPRG innehåller resurser som AKS använder för att fungera. Den här resursgruppen skapas vid distributionen. Red Hat hanterar inte den här resursgruppen. Mer information finns i Microsoft AKS-dokumentationen.

För AAP i Azure i hanterat läge bör du även tänka på följande faktorer:

  • När du installerar AAP på Azure väljer du om distributionen är offentlig eller privat, vilket påverkar hur användare kan komma åt AAP-användargränssnitten.

  • Oavsett om du väljer en offentlig eller privat distribution måste du konfigurera nätverkspeering för utgående kommunikation från AAP till de privata nätverk som innehåller resurser som du vill automatisera mot. Du kan konfigurera nätverkspeering från AAP på Azure till ditt privata virtuella Azure-nätverk och till lokala nätverk eller nätverk med flera moln där överföringsroutning med Azure finns.

Andra överväganden för självhanterat läge

AAP på Azure i självhanterat läge ger många av samma fördelar med hanterad AAP. Men när hanterat läge körs i ett AKS-kluster är självhanterade automationsplattformsresurser virtuella datorer (VM)-baserade.

Tänk på följande faktorer för AAP på Azure i självhanterat läge:

  • Event-Driven Ansible ingår i det självhanterade erbjudandet i Azure. Händelsedriven automatisering hjälper dig att minska manuella uppgifter och leverera en effektiv IT-miljö som fokuserar på innovation. Händelsedriven Ansible bearbetar händelser, fastställer lämpliga svar och kör sedan automatiserade åtgärder för att åtgärda händelsen.

  • Prenumerationer är tillgängliga i steg om 100 aktiva hanterade noder. De är tillgängliga i offentliga erbjudanden eller privata erbjudanden.

  • Virtuella datorresurser som ligger till grund för AAP i Azure i självhanterat läge kan helt bestå av Azure Marketplace-avbildningar eller en blandning av Azure Marketplace-avbildningar och kundhanterade avbildningar.

Designrekommendationer

När du använder RHEL-plattformen för Azure-landningszoner använder du Red Hat-certifierat innehåll och verifierade innehållssamlingar från Red Hat Automation Hub. Följande samlingar har framträdande roller i automationsramverket:

  • redhat.rhel_idm

    • Konfigurera primära virtuella IdM-datorer.
    • Konfigurera IdM-repliker.
    • Integrera och konfigurera RHEL-klienter med IdM.

  • redhat.satellite, redhat.satellite_operations och redhat.rhel_system_roles

    • Distribuera satellit och kapsel.
    • Skapa och konfigurera satellitobjekt och inställningar.
    • Etablera och konfigurera RHEL-system.

  • ansible.*, ansible.controller och infra.controller_configuration

    • Konfigurera AAP.
    • Skapa och konfigurera AAP-jobbmallar och inställningar.

Ansible-samlingen för Azure innehåller över 250 moduler som du kan använda för att förhöra, hantera och automatisera Azure-resurstyper, till exempel:

  • AKS.
  • Programsäkerhetsgrupper.
  • Azure Container Registry.
  • Azure-databastjänster.
  • Azure Key Vault.
  • Azure SQL Database.
  • Azure Virtual Machines.
  • Microsoft Entra-ID.
  • Nätverk.
  • Lagring.

Distribution av kärnplattformsinfrastruktur

Etablera koncept och processer för att effektivt distribuera kärnplattformsinfrastruktur och stödja en RHEL-plattform i Azure-landningszoner.

Mer information finns i:

  • Designvägledning för Azure-landningszoner för överväganden kring plattformsautomatisering.

  • Utvecklingslivscykel. Utforska viktiga designöverväganden och rekommendationer om hur du använder automatisering för att skapa en landningszon. Den här vägledningen beskriver strategin för lagringsplats, gren, automatiserade versioner, distribution och återställning.

  • IaC. Utforska fördelarna med att implementera Azure-landningszoner via IaC. Lär dig mer om överväganden som rör kodstruktur, verktyg och teknik.

  • Miljöer. Lär dig hur du använder flera miljöer för att skapa, testa och släppa kod med högre hastighet och frekvens. Den här metoden gör distributionen så enkel som möjligt.

  • Testdriven utveckling. Lär dig hur du använder enhetstestning för att förbättra kvaliteten på nya funktioner och göra förbättringar i azure-landningszonens kodbas.

När du har de nödvändiga verktygen för källkodshantering på plats och de processer för källkodshantering som upprättats från föregående avsnitt kan du implementera automatisering. Utveckla Ansible Automation-kod med tillhörande IaC eller konfiguration som kod för att distribuera kärninfrastruktur och stödja RHEL-plattformen för Azure-landningszoner. För greenfield-distributioner kan du automatisera följande uppgifter för en fullständig miljöimplementering. För brownfield-distributioner kan du bara automatisera de uppgifter som ditt användningsfall kräver.

  • Skapa Azure-resursgrupper.
  • Skapa virtuella nätverk.
  • Skapa undernät.
  • Skapa nätverkssäkerhetsgrupper.
  • Skapa gyllene RHEL 8.x- och 9.x-avbildningar för Azure via automatiserad Red Hat Image Builder.
  • Skapa en primär virtuell IdM-dator (före satellitetablering). Konfigurera den primära IdM-datorn via konfiguration som kod.
  • Skapa en virtuell satellitdator (före satellitetablering). Konfigurera Satellit via konfiguration som kod.
  • Skapa virtuella Capsule-datorer (satellitetablering). Konfigurera Capsule via konfiguration som kod.
  • Skapa virtuella IdM-replikeringsdatorer (satellitetablering). Konfigurera IdM-repliker via konfiguration som kod.
  • Skapa AAP-infrastruktur (satellitetablering), inklusive:
    • Virtuella datorer för Automation-styrenhet.
    • Virtuella datorer med körningsnod.
    • Virtuella datorer med hoppnod (valfritt).
    • Virtuella Automation Hub-datorer.
    • Händelsedrivna ansible-virtuella datorer (om de är aktiverade).
    • Azure Database for PostgreSQL-servern och nödvändiga databaser för komponenterna controller, hub och Event-Driven Ansible. Azure Database for PostgreSQL-konfigurationer med hög tillgänglighet eller haveriberedskap kräver extra automatisering via replikeringsleverans, loggleverans eller Crunchy Postgres.
  • Skapa lastbalanserare (programgatewayer).
    • Klientdel för virtuella Capsule-datorer
    • Klientdel för virtuella DATORER med AAP-styrenhet
    • Klientdel för virtuella Automation Hub-datorer
  • Skapa programsäkerhetsgrupper.
    • IdM-infrastruktur
    • AAP-infrastruktur
    • Satellit- eller kapselinfrastruktur

RHEL-systemlivscykelhantering

När kärnplattformsinfrastrukturen är på plats kan du implementera automatisering för RHEL-program och arbetsbelastningslivscykler. Följande arbetsflöde beskriver ett exempel på automatiseringsimplementering för en pipeline för utvecklingslivscykel:

  1. Uppdatera slutdatumet för errata-filtret och publicera innehåll i Satellit.

  2. Flytta upp innehållsvyer (CV) och sammansatta innehållsvyer (CCV) till utveckling.

  3. Distribuera RHEL-utvecklingstestsystem från satellitvärdgrupper. GYLLENE RHEL 8.x- och 9.x-avbildningar för Azure via automatiserad Red Hat Image Builder definieras som Azure-beräkningsresurser i Satellit.

  4. Uppdatera eller skapa Azure-nätverkssäkerhetsgrupper baserat på sökvägar för programkommunikation.

  5. Uppdatera eller skapa Azure-programsäkerhetsgrupper för att ge extra nivåsäkerhet för programstackar på flera nivåer.

  6. Uppdatera RHEL-utvecklingssystem och distribuera och konfigurera önskade program från CV eller CCV för satellitutveckling.

    • Distribuera till en enda RHEL-instans för en enkel programstack.
    • Distribuera till flera RHEL-instanser för programstackar med flera nivåer.
    • Konfigurera en programstack.

  7. Kör ett ramverk för programtestning.

    • Om testet misslyckas meddelar du OnCall Automation-administrationen om hjälp med felsökning och analys. Avsluta automationsarbetsflödet. RHEL-testsystem förblir distribuerade för analys av obduktionsfel.
    • Fortsätt stegen om testet lyckas.

  8. Höj upp CV:er och CCV:er till kvalitetssäkring (QA).

  9. Förstör RHEL-utvecklingstestsystem.

Efterföljande steg i livscykelpipelinen skiljer sig något från utvecklingslivscykeln. Endast utvecklingssteget använder den inledande innehållspubliceringen och den inledande CV- och CCV-kampanjen för utveckling. I följande exempel beskrivs ett automationsarbetsflöde för livscykelpipelines för icke-utveckling, till exempel QA, förproduktion och produktionspipelines.

  1. Distribuera RHEL QA-testsystem från satellitvärdgrupper. GYLLENE RHEL 8.x- och 9.x-avbildningar för Azure via automatiserad Red Hat Image Builder definieras som Azure-beräkningsresurser i Satellit.

  2. Uppdatera eller skapa Azure-nätverkssäkerhetsgrupper baserat på sökvägar för programkommunikation.

  3. Uppdatera eller skapa Azure-programsäkerhetsgrupper för att ge extra nivåsäkerhet för programstackar på flera nivåer.

  4. Uppdatera RHEL QA-system och distribuera och konfigurera önskade program från CV eller CCV i Satellit-QA.

    • Distribuera till en enda RHEL-instans för en enkel programstack.
    • Distribuera till flera RHEL-instanser för programstackar med flera nivåer.
    • Konfigurera en programstack.

  5. Kör ett ramverk för programtestning.

    • Om testet misslyckas meddelar du OnCall Automation-administrationen om hjälp med felsökning och analys. Avsluta automationsarbetsflödet. RHEL-testsystem förblir distribuerade för analys av obduktionsfel.
    • Fortsätt stegen om testet lyckas.

  6. Flytta upp CV:er och CCV:er till produktion.

  7. Förstör RHEL QA-testsystem.

Andra designöverväganden för Azure-inbyggda verktyg

Azure Automation

Om du vill automatisera frekventa, tidskrävande och felbenägna hanteringsuppgifter kan du använda funktionen för processautomatisering i Azure Automation. Den här funktionen hjälper dig att fokusera på arbete som lägger till affärsvärde. Processautomatisering minskar felen och ökar effektiviteten, vilket bidrar till att sänka driftskostnaderna. Mer information finns i Översikt över Automation.

Processautomatisering stöder integrering av Azure-tjänster och andra partnersystem, till exempel Red Hat, som du behöver för att distribuera, konfigurera och hantera dina processer från slutpunkt till slutpunkt. Du kan också använda den här funktionen för att skapa grafiska PowerShell- och Python-runbooks.

Du kan använda runbooks för en mängd olika automatiseringsuppgifter, som att hantera resurser, starta och stoppa virtuella datorer och hantera underhållsaktiviteter både i Azure och utanför Azure. Mer information finns i Översikt över Azure Automation-kontoautentisering och Runbooks i Azure Automation.

I följande tabell beskrivs de runbook-typer som stöds.

Typ av runbook beskrivning
PowerShell En text runbook som baseras på Windows PowerShell-skript. De versioner som stöds är PowerShell 7.2 (GA) och PowerShell 5.1 (GA). Den överordnade PowerShell-produkten stöder inte längre PowerShell 7.1. Vi rekommenderar att du skapar runbooks i den långsiktiga versionen PowerShell 7.2 som stöds.
PowerShell-arbetsflöde En text runbook som baseras på Windows PowerShell-arbetsflödesskript.
Python En text runbook som baseras på Python-skript. De versioner som stöds är Python 3.8 (GA) och Python 3.10 (förhandsversion). Den överordnade Python-produkten stöder inte längre Python 2.7. Vi rekommenderar att du skapar runbooks i versioner som stöds på lång sikt.
Grafisk En grafisk runbook som baseras på Windows PowerShell och som skapats och redigerats helt i den grafiska redigeraren i Azure-portalen.
Grafiskt PowerShell-arbetsflöde En grafisk runbook som baseras på Windows PowerShell-arbetsflöde och som skapats och redigerats helt i den grafiska redigeraren i Azure-portalen.

Använd webhooks för att uppfylla begäranden och för att säkerställa kontinuerlig leverans och drift genom att utlösa automatisering via Azure Logic Apps, Azure Functions, PRODUKTER eller tjänster för IT-tjänsthantering, DevOps eller övervakningssystem.

Azure Arc representerar ett betydande framsteg inom molnbaserad databehandling och erbjuder en enhetlig hanteringsplattform som utökar Azure-funktionerna till lokala miljöer, miljöer med flera moln och gränsmiljöer. Azure Arc integreras med Azure Automation-tjänsten via VM-tilläggsramverket för att distribuera rollen som hybrid runbook worker och förenkla registreringen av uppdateringshantering, ändringsspårning och inventeringsfunktioner.

Diagram som visar Azure Arc-ekosystemet.

Mer information finns i Ansluta en befintlig Linux-server till Azure Arc.

ARM-mallar

IaC via ARM-mallar tillhandahåller en konsekvent deklarativ metod för att distribuera och hantera Azure-resurser. Använd ARM-mallar för att definiera den infrastruktur som krävs för dina program i JSON-format. ARM-mallar är idempotenter, vilket innebär att du kan distribuera samma mall många gånger och få samma resurstyper i samma tillstånd.

Mer information finns i dokumentationen om ARM-mallar.

JSON-exempel

{ 

  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", 
  "contentVersion": "1.0.0.0", 
  "parameters": { 
    "location": { 
      "type": "string", 
      "defaultValue": "[resourceGroup().location]" 
    }, 
    "storageAccountName": { 
      "type": "string", 
      "defaultValue": "[format('toylaunch{0}', uniqueString(resourceGroup().id))]" 
    } 
  }, 
  "resources": [ 
    { 
      "type": "Microsoft.Storage/storageAccounts", 
      "apiVersion": "2021-06-01", 
      "name": "[parameters('storageAccountName')]", 
      "location": "[parameters('location')]", 
      "sku": { 
        "name": "Standard_LRS" 
      }, 
      "kind": "StorageV2", 
      "properties": { 
        "accessTier": "Hot" 
      } 
    } 
  ] 
}

Du kan använda Bicep-domänspecifikt språk för att minska komplexiteten i JSON-syntaxen och minimera inlärningskurvan för personer som är nya i Azure. Bicep är en transparent abstraktion jämfört med en ARM-mall som använder JSON, och Bicep bevarar JSON-mallfunktionerna. Under distributionen konverterar kommandoradsgränssnittet Bicep en Bicep-fil till en ARM-mall som använder JSON.

Exemplen i det här avsnittet visar skillnaden mellan en Bicep-fil och motsvarande JSON-mall. Båda exemplen distribuerar ett lagringskonto.

Bicep-exempel

param location string = resourceGroup().location 
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}' 
 

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = { 
  name: storageAccountName 
  location: location 
  sku: { 
    name: 'Standard_LRS' 
  } 
  kind: 'StorageV2' 
  properties: { 
    accessTier: 'Hot' 
  } 
}

Azure DevOps

Azure DevOps är en omfattande uppsättning utvecklingsverktyg som tillhandahåller tjänster för projekthantering, kontinuerlig integrering och kontinuerlig leverans (CI/CD) och lagringsplatser för källkod för både molnmiljöer och lokala miljöer. Du kan kombinera dessa funktioner med Azure Test Plans, Azure Artifacts, Logic Apps och Azure Functions för att underlätta sömlöst samarbete, utveckling och leverans av moderna programvaruprojekt.

Azure-tavlor

Azure Boards har stöd för agila metoder för utveckling av molnprogramvara och projekthantering. Mer information finns i Dokumentation om Azure Boards och Konfigurera och anpassa Azure Boards.

För att få ut mesta möjliga av Azure Boards kan du förstå hur dina team använder sina verktyg och funktioner, till exempel Scrum, Kanban och Scrumban, och deras beroenden av konfigurationer och anpassningar.

I följande tabell sammanfattas de primära objekt som du bör tänka på när du strukturerar projektet.

Projektnivå Teamnivå
Antalet team som du vill definiera Så här använder du din produkts kvarvarande uppgifter för att planera och prioritera ditt arbete
Så här strukturerar du områdesvägar för att stödja portföljhanteringsvyer Oavsett om du spårar buggar som krav, spårar buggar som uppgifter eller inte använder buggar alls
Fältanpassning Om du använder uppgifter för att spåra tid och kapacitet
Anpassade typer av arbetsobjekt Så här använder du portfölj eftersläpningsnivåer
Anpassningar av portföljens kvarvarande uppgifter Så här använder du portfölj eftersläpningsnivåer
Anpassning av arbetsflöde Så här informerar du den övre hanteringen av förlopp, status och risker

Azure-pipelines

Azure Pipelines är ett snabbt, enkelt och säkert sätt att automatisera dina projektversioner med konsekvent och kvalitetskod som är lättillgänglig.

Azure Pipelines:

  • Fungerar med valfritt språk eller plattform.
  • Distribuerar till olika typer av mål samtidigt.
  • Integrerar med Azure-distributioner.
  • Bygger på Windows-, Linux- eller Mac-datorer.
  • Integrerar med GitHub.
  • Fungerar med projekt med öppen källkod.

Mer information finns i Dokumentation om Azure Pipelines.

Beroende på organisationens behov kan du välja en av de fyra kärnarkitekturerna för Azure Pipelines:

Azure-lagringsplatser

Azure Repos innehåller två typer av versionskontroll, Git-versionskontroll och centraliserad versionskontroll.

Anslut utvecklingsmiljön till Azure Repos för att få åtkomst till koden. Dela din kod via:

Mer information finns i Dokumentation om Git för Azure Repos och Dokumentation om Versionskontroll för Team Foundation.

Använda versionspipelines och Azure Artifacts-källor

Utvecklare kan använda Azure Artifacts för att publicera och använda olika typer av paket från feeds och offentliga register, till exempel PyPI, Maven Central och NuGet.org. Du kan använda Azure Artifacts med Azure Pipelines för att publicera bygg- och pipelineartefakter, distribuera paket eller integrera filer i olika steg i pipelinen för att skapa, testa eller distribuera ditt program.

Mer information finns i:

Integrera Azure Policy med Azure DevOps

Azure Policy gäller direkt för resurser i Azure-miljöer, men dess principer och styrning kan indirekt påverka Azure DevOps-metoder. Azure Policy kan till exempel påverka:

  • Efterlevnad i CI/CD-pipelines: Du kan integrera efterlevnadskontroller i dina pipelines. Kontrollera till exempel att all infrastruktur som du distribuerar via Azure DevOps uppfyller de principer som du definierar i Azure Policy.

  • Miljökonsekvens: Använd Azure Policy för att framtvinga specifika konfigurationer eller resurstyper för att säkerställa att de miljöer som du distribuerar till via Azure DevOps är konsekventa och kompatibla.

  • Säkerhet och styrning: Principer kan tillämpa säkerhetsstandarder och styrningsmetoder på de resurser som Azure DevOps Projects hanterar. Den här förordningen säkerställer att utvecklingslivscykeln omfattar efterlevnad av organisations- och regelstandarder.

För att effektivt integrera Azure Policy med Azure DevOps kan du använda Efterlevnadsdata och granskningsfunktioner för Azure Policy för att informera dina DevOps-metoder. Gör justeringar i dina pipelines eller IaC-definitioner så att de överensstämmer med de organisationsprinciper som du tillämpar via Azure Policy.

Den här integreringen säkerställer att resurser som du distribuerar och hanterar via Azure DevOps alltid är kompatibla med företagets styrningsstandarder. Använd den här metoden för att förbättra säkerhet, konsekvens och kostnadshantering i Azure-miljöer.

Nästa steg