Översikt över Azure DevOps
| Dokumentation om nya | utvecklarcommunityn | DevOps | |
Produktöversikt
Den här funktionslistan är en titt på vår översikt. Den identifierar några av de viktiga funktioner som vi arbetar med för närvarande och en ungefärlig tidsram för när du kan förvänta dig att se dem. Det är inte heltäckande men är avsett att ge viss insyn i viktiga investeringar. Överst hittar du en lista över våra stora flerkvartalsinitiativ och de funktioner som de delar upp sig i. Längre ned hittar du den fullständiga listan över viktiga funktioner som vi har planerat.
Varje funktion är länkad till en artikel där du kan lära dig mer om ett visst objekt. Dessa funktioner och datum är de aktuella planerna och kan komma att ändras. Tidsramskolumnerna återspeglar när vi förväntar oss att funktionen ska vara tillgänglig.
Initiativ
GitHub Advanced Security för Azure DevOps
GitHub Advanced Security (GHAS) för Azure DevOps är nu allmänt tillgängligt. Alla projektsamlingsadministratörer kan nu aktivera Avancerad säkerhet för organisationen, projekt och lagringsplatser från projektinställningar eller organisationsinställningar. Du kan lära dig mer om hur du konfigurerar GitHub Advanced Security för Azure DevOps i vår dokumentation.
Nya funktioner som vi förväntar oss att leverera är:
| Funktion | Ytdiagram | Kvartal |
|---|---|---|
| Visa kontextuella kommentarer till pull-begäranden som innehåller nyligen introducerade Advanced Security-resultat | GitHub Advanced Security för Azure DevOps | 2024 Q4 |
| Fastställa giltigheten för identifierade partnerhemligheter | GitHub Advanced Security för Azure DevOps | 2024 Q4 |
| Åtgärda identifierade sårbarheter för beroendegenomsökning automatiskt med Dependabot-säkerhetsuppdateringar | GitHub Advanced Security för Azure DevOps | Framtid |
Minimera riskerna med stöld av autentiseringsuppgifter
Azure DevOps stöder många olika autentiseringsmekanismer, inklusive grundläggande autentisering, personliga åtkomsttoken (PAT), SSH och Microsoft Entra-ID (tidigare Azure Active Directory) åtkomsttoken. Dessa mekanismer skapas inte lika ur ett säkerhetsperspektiv, särskilt inte när det gäller risken för stöld av autentiseringsuppgifter. Till exempel kan oavsiktligt läckage av autentiseringsuppgifter som PAT låta skadliga aktörer komma in i Azure DevOps-organisationer där de kan få åtkomst till kritiska tillgångar som källkod, pivotera mot leveranskedjeattacker eller till och med pivotera mot komprometterande produktionsinfrastruktur. För att minimera riskerna för stöld av autentiseringsuppgifter kommer vi att fokusera våra ansträngningar under de kommande kvartalen inom följande områden:
Gör det möjligt för administratörer att förbättra autentiseringssäkerheten via kontrollplansprinciper.
Minska behovet av PAT och andra stöldbara hemligheter genom att lägga till stöd för säkrare alternativ.
Fördjupa Azure DevOps integrering med Microsoft Entra-ID för att bättre stödja dess olika säkerhetsfunktioner.
Undvik behovet av att lagra produktionshemligheter i Azure Pipelines-tjänstanslutningar.
| Funktion | Ytdiagram | Kvartal |
|---|---|---|
| API:er för PAT-livscykel | Allmänt |
2022 Q4 |
| Kontrollplan för personliga åtkomsttoken (PAT) | Allmänt |
2022 Q4 |
| Stöd för hanterad identitet och tjänstens huvudnamn (förhandsversion) | Allmänt |
2023 Q1 |
| Arbetsbelastningsidentitetsfederation för Azure-distributioner (förhandsversion) | Pipelines |
2023 Q3 |
| Detaljerade omfång för Azure Active Directory OAuth | Allmänt |
2023 Q3 |
| Stöd för hanterad identitet och tjänstens huvudnamn (GA) | Allmänt |
2023 Q3 |
| Arbetsbelastningsidentitetsfederation för Azure-tjänstanslutning (GA) | Pipelines |
2024 Q1 |
| Arbetsbelastningsidentitetsfederation för Docker-tjänstanslutning | Pipelines | 2024 H2 |
| Fullständigt webbstöd för principer för villkorsstyrd åtkomst | Allmänt | 2024 H2 |
| Principer för att inaktivera autentiseringsmetoder | Allmänt | Framtid |
Förbättrade tavlor + GitHub-integrering
Den befintliga Azure Boards + GitHub-integreringen har funnits i flera år nu. Integreringen är en bra utgångspunkt, men den erbjuder inte den spårbarhetsnivå som våra kunder har vant sig vid. Baserat på kundfeedback har vi sammanställt en uppsättning investeringar för att förbättra den här integrationen. Vårt mål är att förbättra det så att Azure Boards-kunder som väljer att använda GitHub-lagringsplatser kan upprätthålla en motsvarande nivå av spårbarhet till att ha lagringsplatser i Azure DevOps.
Dessa investeringar omfattar:
| Funktion | Ytdiagram | Kvartal |
|---|---|---|
| Lägg till länk till GitHub-incheckning eller pull-begäran från arbetsobjekt | Boards |
2024 Q1 |
| Visa mer information om en GitHub-pull-begäran | Boards |
2024 Q1 |
|
Förbättra skalbarheten vid sökning och länkning av GitHub lagringsplatser till ett Azure DevOps-projekt |
Boards |
2024 Q2 |
| AB#-länkar på GitHub-pullbegäran (förhandsversion) | Boards |
2024 Q2 |
| Skapa gren på GitHub-lagringsplats från arbetsobjekt | Boards |
2024 Q3 |
| Stöd för GitHub Enterprise Cloud med datahemvist | Boards | 2025 Q1 |
| ! nämner stöd för GitHub-pull-begäranden | Boards | 2025 Q1 |
| Visa byggstatus när du använder en YAML-byggpipeline med GitHub-lagringsplatsen | Boards | 2025 Q1 |
| Stöd för tillståndsövergångar vid sammanslagning av en GitHub-pullbegäran | Boards | 2025 Q1 |
| Länka pull-begäranden automatiskt när de länkas till en GitHub-gren | Boards | 2025 Q1 |
| Rapportera status för steg till arbetsobjekt när du använder en YAML-versionspipeline med GitHub-lagringsplatsen | Boards | Framtid |
YAML- och versionspipelines har paritet
Under de senaste åren har alla våra pipelines-investeringar varit inom YAML-pipelines. Dessutom har alla våra säkerhetsförbättringar varit för YAML-pipelines. Med YAML-pipelines ligger till exempel kontrollen över skyddade resurser (t.ex. lagringsplatser, tjänstanslutningar osv.) i händerna på resursägarna i stället för pipelineförfattare. Jobbåtkomsttoken som används i YAML-pipelines är begränsade till specifika lagringsplatser som anges i YAML-filen. Det här är bara två exempel på säkerhetsfunktioner som är tillgängliga för YAML-pipelines. Därför rekommenderar vi att du använder YAML-pipelines via klassiska. Införandet av YAML över klassisk har varit viktigt för versioner (CI). Många kunder har dock fortsatt att använda klassiska versionshanteringspipelines via YAML för versioner (CD). Den främsta orsaken till detta är bristen på paritet i olika CD-funktioner mellan de två lösningarna. Under det senaste året har vi åtgärdat flera luckor på detta område, särskilt i kontrollerna. Kontroller är den primära mekanismen i YAML-pipelines för att gatebefordra en version från en fas till en annan. Vi kommer att fortsätta att ta itu med luckor på andra områden under det kommande året. Vårt fokus kommer att ligga på användarupplevelser, spårbarhet och miljöer.
| Funktion | Ytdiagram | Kvartal |
|---|---|---|
| Granskning för kontroller | Pipelines |
2022 Q4 |
| Anpassade variabler i kontroller | Pipelines |
2023 Q1 |
| Kontrollerar skalbarhet | Pipelines |
2023 Q2 |
| Kringgå godkännanden och kontroller | Pipelines |
2023 Q4 |
| Sekvensering av godkännanden och andra kontroller | Pipelines |
2024 Q1 |
| Uppskjutna godkännanden | Pipelines |
2024 Q1 |
| Kör om en enskild fas | Pipelines |
2024 Q1 |
| Manuell kö av faser | Pipelines |
2024 H2 |
| Samtidighet på stegnivå | Pipelines |
2024 Q3 |
| Spårbarhet på stegnivå | Pipelines | 2024 H2 |
| Tjänstanslutningar i kontroller | Pipelines | Framtid |
| Kontrollerar utökningsbarhet | Pipelines | Framtid |
Alla funktioner
Azure DevOps Services
Azure DevOps Server
Så här ger du feedback
Vi vill gärna höra vad du tycker om de här funktionerna. Rapportera eventuella problem eller föreslå en funktion via Utvecklarcommunityn.
Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.