Azure DevOps Roadmap
| Wat is er nieuw | ontwikkelaarscommunity | DevOps-blogdocumentatie | |
Productroadmap
Deze lijst met functies is een kijkje in onze roadmap. Het identificeert enkele van de belangrijke functies waaraan we momenteel werken en een ruw tijdsbestek voor wanneer u ze kunt verwachten. Het is niet volledig, maar is bedoeld om inzicht te krijgen in belangrijke investeringen. Bovenaan vindt u een lijst met onze grote multikwartale initiatieven en de functies waar ze in opsplitsen. Verderop vindt u de volledige lijst met belangrijke functies die we hebben gepland.
Elke functie is gekoppeld aan een artikel waar u meer informatie over een bepaald item kunt vinden. Deze functies en datums zijn de huidige plannen en kunnen worden gewijzigd. De kolommen Tijdsbestek geven aan wanneer we verwachten dat de functie beschikbaar is.
Initiatieven
GitHub Advanced Security voor Azure DevOps
GitHub Advanced Security (GHAS) voor Azure DevOps is nu algemeen beschikbaar. Elke beheerder van een projectverzameling kan nu Advanced Security inschakelen voor hun organisatie, projecten en opslagplaatsen vanuit de projectinstellingen of organisatie-instellingen. Meer informatie over het configureren van GitHub Advanced Security voor Azure DevOps vindt u in onze documentatie.
Nieuwe mogelijkheden die we verwachten te leveren zijn onder andere:
| Functie | Gebied | Kwartaal |
|---|---|---|
| Contextuele opmerkingen weergeven voor pull-aanvragen met nieuw geïntroduceerde geavanceerde beveiligingsresultaten | GitHub Advanced Security voor Azure DevOps | 2024 Q4 |
| De geldigheid van gedetecteerde partnergeheimen bepalen | GitHub Advanced Security voor Azure DevOps | 2024 Q4 |
| Gedetecteerde beveiligingsproblemen met afhankelijkheidsscans automatisch oplossen met Dependabot-beveiligingsupdates | GitHub Advanced Security voor Azure DevOps | Toekomst |
Minimaliseren van de risico's die gepaard gaan met diefstal van referenties
Azure DevOps ondersteunt veel verschillende verificatiemechanismen, waaronder basisverificatie, persoonlijke toegangstokens (PAT's), SSH en Microsoft Entra ID -toegangstokens (voorheen Azure Active Directory). Deze mechanismen worden niet evenzeer gemaakt vanuit het oogpunt van beveiliging, vooral als het gaat om het potentieel voor diefstal van referenties. Onbedoeld lekken van referenties, zoals PAT's, kunnen kwaadwillende actoren bijvoorbeeld in Azure DevOps-organisaties toestaan, waar ze toegang kunnen krijgen tot kritieke assets, zoals broncode, pivot naar supply chain-aanvallen of zelfs draaien om de productie-infrastructuur in gevaar te brengen. Om de risico's van referentiediefstal te minimaliseren, richten we ons op de komende kwartalen op de volgende gebieden:
Beheerders in staat stellen om de verificatiebeveiliging te verbeteren via besturingsvlakbeleid.
Verminder de noodzaak van PAT's en andere stelbare geheimen door ondersteuning toe te voegen voor veiligere alternatieven.
De integratie van Azure DevOps met Microsoft Entra ID verdiepen om de verschillende beveiligingsfuncties beter te ondersteunen.
Vermijd de noodzaak om productiegeheimen op te slaan in Azure Pipelines-serviceverbindingen.
| Functie | Gebied | Kwartaal |
|---|---|---|
| PAT-levenscyclus-API's | Algemeen |  2022 Q4 |
| Besturingsvlak voor persoonlijke toegangstokens (PAT) | Algemeen | 2022 Q4 |
| Ondersteuning voor beheerde identiteit en service-principal (preview) | Algemeen | 2023 Q1 |
| Federatie van workloadidentiteit voor Azure-implementaties (preview) | Pipelines | 2023 Q3 |
| Gedetailleerde bereiken voor Azure Active Directory OAuth | Algemeen | 2023 Q3 |
| Ondersteuning voor beheerde identiteiten en service-principals (GA) | Algemeen | 2023 Q3 |
| Workloadidentiteitsfederatie voor Azure-serviceverbinding (GA) | Pipelines | 2024 Q1 |
| Federatie van workloadidentiteit voor Docker-serviceverbinding | Pipelines | 2024 H2 |
| Volledige webondersteuning voor beleid voor voorwaardelijke toegang | Algemeen | 2024 H2 |
| Beleid voor het uitschakelen van verificatiemethoden | Algemeen | Toekomst |
Verbeterde boards + GitHub-integratie
De bestaande Integratie van Azure Boards + GitHub is al enkele jaren aanwezig. De integratie is een goed uitgangspunt, maar biedt niet het niveau van tracering dat onze klanten gewend zijn geworden. Op basis van feedback van klanten hebben we een aantal investeringen samengesteld om deze integratie te verbeteren. Ons doel is om dit te verbeteren, zodat Azure Boards-klanten die ervoor kiezen om GitHub-opslagplaatsen te gebruiken, een equivalent niveau van traceerbaarheid kunnen behouden voor het hebben van opslagplaatsen in Azure DevOps.
Deze investeringen omvatten:
| Functie | Gebied | Kwartaal |
|---|---|---|
| Koppeling toevoegen aan GitHub-doorvoer- of pull-aanvraag van werkitem | Boards | 2024 Q1 |
| Meer informatie over een GitHub-pull-aanvraag weergeven | Boards | 2024 Q1 |
| Schaalbaarheid verbeteren bij het zoeken en koppelen van GitHub opslagplaatsen naar een Azure DevOps-project |
Boards | 2024 Q2 |
| AB#-koppelingen op GitHub-pull-aanvraag (preview) | Boards | 2024 Q2 |
| Vertakking maken in GitHub-opslagplaats vanuit werkitem | Boards | 2024 Q3 |
| ! vermeldt ondersteuning voor GitHub-pull-aanvragen | Boards | 2024 Q4 |
Pariteit van YAML- en release-pijplijnen
Al onze investeringen in pijplijnen zijn de afgelopen jaren op het gebied van YAML-pijplijnen. Bovendien zijn al onze beveiligingsverbeteringen voor YAML-pijplijnen. Met YAML-pijplijnen is bijvoorbeeld de controle over beveiligde resources (bijvoorbeeld opslagplaatsen, serviceverbindingen, enzovoort) in handen van de resource-eigenaren in plaats van pijplijnauteurs. De toegangstokens voor taken die worden gebruikt in YAML-pijplijnen, zijn gericht op specifieke opslagplaatsen die zijn opgegeven in het YAML-bestand. Dit zijn slechts twee voorbeelden van beveiligingsfuncties die beschikbaar zijn voor YAML-pijplijnen. Daarom raden we u aan YAML-pijplijnen te gebruiken in plaats van klassiek. De acceptatie van YAML ten opzichte van de klassieke versie is aanzienlijk geweest voor builds (CI). Veel klanten hebben echter nog steeds klassieke releasebeheerpijplijnen gebruikt via YAML voor releases (CD). De belangrijkste reden hiervoor is het gebrek aan pariteit in verschillende CD-functies tussen de twee oplossingen. Het afgelopen jaar hebben we een aantal hiaten op dit gebied aangepakt, met name in controles. Controles zijn het primaire mechanisme in YAML-pijplijnen om de promotie van een build van de ene fase naar de andere te gateen. In de loop van het volgende jaar zullen we nog steeds hiaten in andere gebieden aanpakken. Onze focus ligt op gebruikerservaringen, traceerbaarheid en omgevingen.
| Functie | Gebied | Kwartaal |
|---|---|---|
| Controle voor controles | Pipelines | 2022 Q4 |
| Aangepaste variabelen in controles | Pipelines | 2023 Q1 |
| Schaalbaarheid controleren | Pipelines | 2023 Q2 |
| Goedkeuringen en controles overslaan | Pipelines | 2023 Q4 |
| Goedkeuringen en andere controles sequentiëren | Pipelines | 2024 Q1 |
| Uitgestelde goedkeuringen | Pipelines | 2024 Q1 |
| Eén fase opnieuw uitvoeren | Pipelines | 2024 Q1 |
| Handmatige wachtrij van fasen | Pipelines | 2024 H2 |
| Gelijktijdigheid op faseniveau | Pipelines | 2024 Q3 |
| Traceerbaarheid op faseniveau | Pipelines | 2024 H2 |
| Serviceverbindingen in controles | Pipelines | Toekomst |
| Uitbreidbaarheid controleren | Pipelines | Toekomst |
Alle functies
Azure DevOps Services
Azure DevOps Server
Feedback geven
We horen graag wat u van deze functies vindt. Meld eventuele problemen of stel een functie voor via de ontwikkelaarscommunity.
U kunt ook advies krijgen en uw vragen beantwoorden door de community op Stack Overflow.