Pipelineefterlevnad och säkerhetsvalidering – Sprint 141-uppdatering

I juni i år distribuerade vi den första iterationen av vår nya navigeringsmodell. Vi har ägnat sommaren åt att förbättra den upplevelsen baserat på den feedback som många av er har gett. Tack! Nästa steg är att gå från att den nya modellen är en förhandsversion till att bli navigering för produkten. Läs vårt blogginlägg som beskriver de senaste ändringarna tillsammans med vårt schema för att föra den nya modellen till alla organisationer.

Vi förstår vikten av sökning och tar tillbaka den expanderade sökrutan i produktrubriken. Dessutom kan du nu anropa sökrutan genom att bara klicka på "/" på valfri tjänstsida i Azure DevOps. Den här funktionen prioriterades baserat på ett förslag på användarröst.

Här är standardsökrutan:

Standardsökruta

När du skriver ett "/" visas den expanderade sökrutan:

Utökad sökruta

Azure-pipelines

Azure Policy efterlevnads- och säkerhetsvalidering i pipelines

Vi vill säkerställa stabilitet och säkerhet för programvara tidigt i utvecklingsprocessen samtidigt som utveckling, säkerhet och drift förs samman. För att göra det har vi lagt till stöd för Azure Policy.

Med Azure Policy kan du hantera och förebygga IT-problem med principdefinitioner som framtvingar regler och effekter för dina resurser. När du använder Azure Policy följer resurserna företagets standarder och serviceavtal.

För att uppfylla efterlevnads- och säkerhetsriktlinjerna som en del av lanseringsprocessen har vi förbättrat vår distributionsupplevelse för Azure-resursgrupper. Nu misslyckas vi med distributionsaktiviteten för Azure-resursgruppen med relevanta principrelaterade fel i händelse av överträdelser vid distribution av ARM-mallar.

Azure Policy

Dessutom har vi lagt till Azure Policy versionsdefinitionsmall. På så sätt kan användare skapa Azure-principer och tilldela dessa principer till resurser, prenumerationer eller hanteringsgrupper från själva versionsdefinitionen.

Azure Policy mall

Förenklad kontinuerlig leverans till virtuella Azure-datorer

I den här versionen har vi lagt till en ny guide för att förenkla processen med att konfigurera kontinuerlig leverans till Azure Virtual Machines. När du har angett en Azure DevOps-organisation och en distributionsgrupp för att registrera den virtuella datorn skapas en versionspipeline automatiskt med ett exempelskriptsteg. Om du behöver etablera ytterligare Azure-resurser, köra skript, uppgradera ditt program eller köra ytterligare valideringstester kan du enkelt anpassa den här versionspipelinen.

VIRTUELLA DATORER i CI till Azure

Xcode-aktiviteten stöder nyligen släppt Xcode 10

Med Apples version av Xcode 10 kan du nu ställa in dina projekt så att de kan byggas eller testas specifikt med Xcode 10. Din pipeline kan också köra jobb parallellt med en matris med Xcode-versioner. Du kan använda den Microsoft-värdbaserade macOS-agentpoolen för att köra dessa versioner. Se vägledningen för att använda Xcode i Azure Pipelines.

Xcode 10

Prestandaförbättringar när du köar en version

När du använder en värdbaserad agent får du en ny virtuell dator för varje jobb. Detta ger ett extra lager av säkerhet och kontroll. Du behöver aldrig bekymra dig om att en tidigare version lämnar utdata eller gör något skadligt för datorn. Första gången startaktiviteter tidigare innebar dock fördröjningar mellan när du klickar på Köa en version och när pipelinen faktiskt körs. Vi undersökte och åtgärdade många av dessa förseningar och ser nu en 5X-hastighet i kö-till-start-tid i de värdbaserade poolerna. Nu kan du komma igång snabbare med dina byggen, vilket innebär att du kan iterera snabbare.

Skapa Azure-tjänstanslutning med tjänstens huvudnamn som autentiserar med ett certifikat

Nu kan du definiera en Azure-tjänstanslutning i Azure Pipelines eller Team Foundation Server (TFS) med tjänstens huvudnamn och certifikat för autentisering. Nu när Azure-tjänstanslutningen stöder tjänstens huvudnamn som autentiserar med ett certifikat kan du nu distribuera till Azure Stack som konfigurerats med AD FS. Om du vill skapa ett huvudnamn för tjänsten med certifikatautentisering läser du artikeln om hur du skapar ett huvudnamn för tjänsten som autentiserar med ett certifikat.

Ansluta med tjänstens huvudnamn

Visa testanalys i pipelines

Att spåra testkvalitet över tid och förbättra testsäkerhetserna är nyckeln till att upprätthålla en felfri pipeline. Testanalysfunktionen ger nästan realtidssynlighet i dina testdata för byggen och versionspipelines. Det hjälper till att förbättra effektiviteten i din pipeline genom att identifiera repetitiva kvalitetsproblem med hög påverkan.

Du kan gruppera testresultat efter olika element, identifiera viktiga tester för din gren eller dina testfiler eller öka detaljnivån till ett specifikt test för att visa trender och förstå kvalitetsproblem som flakiness.

Visa testanalys för versioner och versioner, förhandsversion nedan:

Testanalys

Mer information finns i vår dokumentation.

Azure-lagringsplatser

Ändra målgrenen för en pull-begäran

För de flesta team är nästan alla pull-begäranden inriktade på samma gren, till exempel master eller develop. Men om du behöver rikta in dig på en annan gren är det lätt att glömma att ändra målgrenen från standardvärdet. Med den nya funktionen för att ändra målgrenen för en aktiv pull-begäran är detta nu en enkel åtgärd. Klicka bara på pennikonen nära målgrenens namn i pull-begärandehuvudet.

Ändra målgren

Utöver att bara korrigera misstag gör funktionen för att ändra målgrenar också det enkelt att "skicka om" en pull-begäran när målgrenen har sammanfogats eller tagits bort. Tänk dig ett scenario där du har en PR som är inriktad på en funktionsgren som innehåller vissa funktioner som dina ändringar är beroende av. Du vill granska dina beroende ändringar isolerat från andra ändringar i funktionsgrenen, så att du först riktar in dig på features/new-feature. Granskare kan sedan bara se dina ändringar och lämna lämpliga kommentarer.

Tänk nu på vad som skulle hända om funktionsgrenen också hade en AKTIV PR och sammanfogades till master innan dina ändringar? Tidigare skulle du behöva överge dina ändringar och skapa en ny PR i master, eller sammanfoga din PR till features/new-featureoch sedan skapa en annan PR från features/new-feature till master. Med den här nya åtgärden för att uppdatera målgrenen kan du helt enkelt ändra målgrenen för PR från features/new-feature till masteroch bevara alla kontexter och kommentarer. Om du ändrar målgrenen skapas till och med en ny uppdatering av PR som gör det enkelt att se tillbaka på tidigare diff innan målgrenen ändras.

Uppdatering av målgren

Skydda Git-lagringsplatser med kompatibilitetsinställningar för flera plattformar

Eftersom Git är en plattformsoberoende teknik är det möjligt för filer eller kataloger att hitta till ett filsystem där de kan vara inkompatibla på en specifik plattform. Du kan se information om dessa inkompatibiliteter i vår dokumentation.

För att hjälpa teamen att skydda sin lagringsplats och dess utvecklare har vi lagt till nya lagringsplatsinställningar för att blockera push-meddelanden som innehåller incheckningar med filer/kataloger som inte är kompatibla med en eller flera operativsystemplattformar. Läs mer om de här inställningarna.

Administration

Stöd för AAD-användare i MSA-konton

Azure DevOps stöder nu AzureAD-användare (AAD) som har åtkomst till organisationer som stöds av MSA. För administratörer innebär det att om din Azure DevOps-organisation använder MSA:er för företagsanvändare kan du nu ha nya anställda åtkomst med sina AAD-autentiseringsuppgifter i stället för att skapa en ny MSA-identitet enbart för användning med Azure DevOps.

Vi anser fortfarande att den bästa upplevelsen är att företagsanvändare ansluter Azure DevOps till AAD, men vi lärde oss tidigare i år att administratörer behövde mer tid för att göra den konverteringen. Genom att tillåta AAD-användare i MSA-stödda organisationer kommer nya användare att kunna komma åt Azure DevOps när Azure DevOps har förhindrat skapandet av nya MSA-användare med anpassade domännamn som backas upp av AzureAD i slutet av månaden.

För organisationer som redan använder AAD-identiteter med Azure DevOps gäller inte den här funktionen. För organisationer som för närvarande använder MSA-identiteter bör du observera att alla befintliga användare kan fortsätta att logga in med sina MSA-identiteter som de gör i dag. Detta gäller endast för användare som läggs till i framtiden (som potentiellt inte kan skapa en MSA med företagets e-postadress).

Här är ett exempelscenario där den här upplevelsen kan vara användbar: Dorothy är Azure DevOps-organisationsägare för sitt företag Fabrikam. Hon och hennes team med 10 teammedlemmar loggar alla in på Azure DevOps med MSA-identiteter som använder företagets e-postadress, t.ex. Dorothy@fabrikam.com. Sam är en ny teammedlem som gick med i företaget idag. Dorothy bjuder in honom till Azure DevOps med hjälp av hans e-post, sam@fabrikam.com. När han klickar på länken anslut nu i e-postmeddelandet kan han logga in på Azure DevOps med samma AAD-identitet som han fick för att få åtkomst till sin e-post med Microsoft 365. Detta gör att Sam kan samarbeta med sina 11 kollegor och ger Dorothy friheten att ansluta sin Azure DevOps-organisation till AAD när hon är redo.

Mer information finns i vårt blogginlägg .

Så här ger du feedback

Vi vill gärna höra vad du tycker om dessa funktioner. Använd feedbackmenyn för att rapportera ett problem eller ge ett förslag.

Ge ett förslag

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Gopinath Chigakkagari (Twitter)

Dela via