Megosztás a következőn keresztül:

A számítási feladatok identitás-összevonásának általános elérhetősége az Azure Resource Manager szolgáltatáskapcsolataihoz

  • Cikk

Örömmel jelentjük be, hogy a számítási feladatok identitásának összevonása általánosan elérhető az Azure Pipelinesban! Az azure-szolgáltatási kapcsolatok titkos kulcsainak és tanúsítványainak kezelése nélkül is élvezheti az egyszerűbb élményt.

Ezzel a frissítéssel egy új funkciót is megtekintünk az Azure Boards továbbfejlesztett GitHub-integrációjának részeként. Mostantól közvetlenül hivatkozhat a GitHub lekéréses kérelmeire vagy véglegesítésére. Nincs több váltás az ablakok vagy a másolás/beillesztés között. Egyszerűen válassza ki a kívánt adattárat, keresse meg a szükséges lekéréses kérelmet vagy véglegesítést, és kapcsolja össze!

Ezekről a funkciókról a kibocsátási megjegyzésekben olvashat bővebben.

Általános

GitHub Advanced Security for Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

Általános

Másodlagos hitelesítő adatok elavulásának végleges értesítése

A másodlagos hitelesítő adatokat 2020 márciusában formálisan elavulták, de néhány meglévő felhasználót a meglévő másodlagos hitelesítő adataik folyamatos használatával használtak. 2024 januárjától teljesen elavult az összes másodlagos hitelesítő adat. A lehetséges fennakadások elkerülése érdekében váltson a rendelkezésre álló hitelesítési mechanizmusok egyikére, például a személyes hozzáférési jogkivonatokra vagy a felügyelt identitásokra.

Azure Devops OAuth önkiszolgáló titkos kódok rotálása

Az Azure DevOps OAuth-alkalmazás ügyfélkódjának ötévente történő frissítése elengedhetetlen ahhoz, hogy az Azure DevOps API-k használatához szükséges hozzáférési és frissítési jogkivonatok folyamatosan generáljanak. Ahogy közeledik az Ügyféltitkos lejárata, mostantól önállóan is létrehozhat egy újat, amely lehetővé teszi a csapat számára a kezelés szabadságát anélkül, hogy az ügyfélszolgálatra támaszkodik. Ez a rugalmasság a titkos kódok rotálásának ütemezésében minimálisra csökkenti a lejárt titkos kód miatt cserére váró ügyfelek lehetséges kimaradási idejét.

Képernyőkép a földrajzi hely kiválasztásáról.

Keresse meg ezt az új funkciót minden Azure DevOps-alkalmazásoldalon, amely itt érhető el a profilján keresztül. További információ erről az új lépésről az Azure DevOps OAuth útmutatójában.

GitHub Advanced Security for Azure DevOps

A kódrészletek mostantól elérhetők a riasztás részleteinek nézetben

A kódvizsgálati és titkos kulcskeresési riasztások riasztási részleteinek lapján mostantól kódrészletek láthatók, amelyek a riasztást tartalmazó kód egy vagy több sorát jelölik meg. Ha az Azure DevOps-adattár eredeti fájljára szeretne lépni, kattintson a kódrészlet feletti fájlnévre.

Képernyőkép a kis- és nagybetűk közötti elérési útról.

Csonkolt titkos kódok jelennek meg a riasztások áttekintésében

Az észlelt titkos kódok csonkolt, utolsó hat karaktere megjelenik a titkos kódok riasztásának áttekintési képernyőjén. Ez a funkció akkor hasznos, ha több, azonos titkos típusú titkos adattal rendelkezik, így gyorsan azonosíthatja az adott titkos kulcsok helyét.

Képernyőkép a titkos riasztások listájáról.

További riasztási súlyosságok hozzáadva a kódkeresési riasztásokhoz

Új riasztási súlyosságok léteznek a CodeQL-lekérdezések quality riasztási eredményeihez, mint Error, Warningés Note súlyosságok. Minden minőségi riasztás súlyossága saját jelvényt és színt tartalmaz a skálázási súlyosságok megjelöléséhez. Ezekre a súlyosságokra is szűrhet, hasonlóan a low biztonsági riasztások súlyossági skálázásához critical .

Képernyőkép a kódkeresési riasztások listájáról és a súlyosság szűrőről.

A GitHub Advanced Securityhez szükséges társított Azure-előfizetés az Azure DevOps engedélyezéséhez

Ha korábban engedélyezte az Advanced Security használatát egy Azure DevOps-szervezet adattáraihoz társított Azure-előfizetés nélkül, akkor előfordulhat, hogy az Advanced Security automatikusan letiltotta magát ezeken az adattárakon. Az Advanced Security újbóli engedélyezéséhez adjon hozzá egy társított Azure-előfizetést a szervezethez. Az előfizetés hozzáadásáról és módosításáról további információt az Azure-előfizetés módosítása című témakörben talál.

Speciális Biztonsági API-frissítések

A nemrég szállított Speciális Biztonsági API különböző frissítései:

  • A GET Alerts API mostantól egy új paramétert támogat, ModifiedSinceamely a riasztások növekményes listáját adja vissza, és csak az e dátum óta módosított riasztásokat adja vissza. További információ: Riasztások – Lista.
  • Egy szervezet vagy projekt Speciális biztonsági engedélyezési állapotának lekéréséhez vagy frissítéséhez két új végpont érhető el. Mindkét végpont az Advanced Security engedélyezésével rendelkező adattárak listáját adja vissza. További információ: Szervezet – Engedélyezés vagy Projekt – Engedélyezés.
  • Két új végponttal lehet lekérni egy szervezet vagy projekt aktív véglegesítési számának becslését, hogy az tükrözze a becsült Advanced Security-mérőhasználat költségeit. További információ: Szervezeti fogyasztásmérők használati becslése vagy projekthasználat-becslés.

A speciális biztonsági engedélyek mostantól véglegesen megjelennek

Korábban a három Speciális biztonsági engedélybit csak tárházonként hozzárendelhető engedélyként jelenik meg, ha az Advanced Security engedélyezve van. Ezek az engedélyek alapértelmezés szerint elérhetők az Adattárak > biztonsági engedélyek paneljén, és az Advanced Security engedélyezése nélkül is hozzárendelhetők.

A Speciális biztonsági engedélyek képernyőképe.

Azure Boards

Két lehetősége van arra, hogy összekapcsolja a munkaelemet egy GitHub-lekéréses kérelemmel vagy véglegesítéssel. Használhatja az AB# szintaxist a lekéréses kérelemben, vagy közvetlenül a munkaelemből is csatolhatja. A folyamat jelenleg magában foglalja a GitHub lekéréses kérelem URL-címének másolását és beillesztését egy hivatkozás hozzáadásakor. Ehhez több ablak megnyitására és a GitHub és az Azure DevOps közötti váltásra van szükség.

Ebben a futamban izgatottan jelentjük be a továbbfejlesztett élményt azáltal, hogy lehetővé tesszük a keresési funkciókat a GitHub lekéréses kéréséhez vagy véglegesítéséhez való csatoláskor. Keresse meg és válassza ki a kívánt adattárat, majd részletezze le az adott lekéréses kérelem vagy véglegesítés megkereséséhez és csatolásához. Nincs szükség több ablakmódosításra és másolásra/beillesztésre (bár ez a lehetőség továbbra is fennáll).

Gif to demo add link.

Feljegyzés

Ez a funkció csak a New Boards Hub előzetes verziójában érhető el.

Ha szeretne hozzáférni ehhez a funkcióhoz, küldjön nekünk egy e-mailt közvetlenül a szervezet nevével együtt (dev.azure.com/{szervezet neve}).

Új Boards Hub-fejlesztések

Ezzel a kiadással számos fejlesztést vezettünk be a New Boards Hub előzetes verziójában, amelyek az akadálymentességre és az oldal újrarendelésére összpontosítanak.

Íme egy példa a 400%-os nagyításig adaptív oldalátrend-módosításokra.

Gif az új boards hub fejlesztéseinek bemutatóihoz.

Emellett teljesítménybeli fejlesztéseket is bevezettünk a munkaelem űrlapján, a táblákon és a hátralékoldalakon. Ezekkel a változásokkal várhatóan az új táblák megfelelnek a régi táblákhoz beállított teljesítményszabványoknak.

Fejlesztési és üzembehelyezési vezérlők

Most eltávolítjuk a fejlesztési és/vagy üzembehelyezési vezérlőket a munkaelemből a projekt konfigurálásának módjától függően. Konfigurálhatja például a projektbeállításokat az adattárak és/vagy folyamatok kikapcsolásához.

Képernyőképek a DevOps-szolgáltatásokról.

Amikor a munkaelemre lép, a megfelelő fejlesztési és üzembehelyezési vezérlők el lesznek rejtve az űrlapon.

Képernyőkép a kapcsolódó munkáról.

Ha úgy dönt, hogy egy GitHub-adattárat csatlakoztat az Azure Boardshoz, megjelenik a GitHub-adattárak fejlesztési vezérlője.

Képernyőképek a fejlesztésvezérlésről.

Azure Pipelines

Általánosan elérhető a számítási feladatok identitásának összevonása az Azure Resource Manager-szolgáltatáskapcsolatokhoz

Szeptemberben bejelentettük, hogy titkos kód használata nélkül konfigurálhatók az Azure-szolgáltatáskapcsolatok. Azóta sok ügyfél elfogadta ezt a funkciót, és örömmel jelentjük be, hogy ez a funkció általánosan elérhető.

Ha még nem használja a számítási feladatok identitásának összevonását, az alábbi módokon használhatja ki a problémamentes Azure-szolgáltatáskapcsolatokat, amelyek nem rendelkeznek lejáró titkos kódokkal:

Ha új Azure-szolgáltatáskapcsolatot szeretne létrehozni a számítási feladatok identitásának összevonásával, válassza a Számítási feladatok identitásának összevonása (automatikus) lehetőséget az Azure szolgáltatáskapcsolat-létrehozási felületen:

Képernyőkép a számítási feladatok identitásának összevonásáról (automatikus).

Egy korábban létrehozott Azure-szolgáltatáskapcsolat konvertálásához válassza a "Konvertálás" műveletet a kapcsolat kiválasztása után:

Képernyőkép a Konvertálás műveletről.

Több szolgáltatáskapcsolat konvertálásához használhatja az automatizálást, például ezt a PowerShell-szkriptet:

#!/usr/bin/env pwsh
<# 
.SYNOPSIS 
    Convert multiple Azure Resource Manager service connection(s) to use Workload identity federation

.LINK
    https://aka.ms/azdo-rm-workload-identity-conversion

.EXAMPLE
    ./convert_azurerm_service_connection_to_oidc_simple.ps1 -Project <project> -OrganizationUrl https://dev.azure.com/<organization>
#> 
#Requires -Version 7.3

param ( 
    [parameter(Mandatory=$true,HelpMessage="Name of the Azure DevOps Project")]
    [string]
    [ValidateNotNullOrEmpty()]
    $Project,

    [parameter(Mandatory=$true,HelpMessage="Url of the Azure DevOps Organization")]
    [uri]
    [ValidateNotNullOrEmpty()]
    $OrganizationUrl
) 
$apiVersion = "7.1"
$PSNativeCommandArgumentPassing = "Standard" 

#-----------------------------------------------------------
# Log in to Azure
$azdoResource = "499b84ac-1321-427f-aa17-267ca6975798"
az login --allow-no-subscriptions --scope ${azdoResource}/.default
$OrganizationUrl = $OrganizationUrl.ToString().Trim('/')

#-----------------------------------------------------------
# Retrieve the service connection
$getApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints?authSchemes=ServicePrincipal&type=azurerm&includeFailed=false&includeDetails=true&api-version=${apiVersion}"
az rest --resource $azdoResource -u "${getApiUrl} " -m GET --query "sort_by(value[?authorization.scheme=='ServicePrincipal' && data.creationMode=='Automatic' && !(isShared && serviceEndpointProjectReferences[0].projectReference.name!='${Project}')],&name)" -o json `
        | Tee-Object -Variable rawResponse | ConvertFrom-Json | Tee-Object -Variable serviceEndpoints | Format-List | Out-String | Write-Debug
if (!$serviceEndpoints -or ($serviceEndpoints.count-eq 0)) {
    Write-Warning "No convertible service connections found"
    exit 1
}

foreach ($serviceEndpoint in $serviceEndpoints) {
    # Prompt user to confirm conversion
    $choices = @(
        [System.Management.Automation.Host.ChoiceDescription]::new("&Convert", "Converting service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Skip", "Skipping service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Exit", "Exit script")
    )
    $prompt = $serviceEndpoint.isShared ? "Convert shared service connection '$($serviceEndpoint.name)'?" : "Convert service connection '$($serviceEndpoint.name)'?"
    $decision = $Host.UI.PromptForChoice([string]::Empty, $prompt, $choices, $serviceEndpoint.isShared ? 1 : 0)

    if ($decision -eq 0) {

        Write-Host "$($choices[$decision].HelpMessage)"
    } elseif ($decision -eq 1) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        continue 
    } elseif ($decision -ge 2) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        exit 
    }

    # Prepare request body
    $serviceEndpoint.authorization.scheme = "WorkloadIdentityFederation"
    $serviceEndpoint.data.PSObject.Properties.Remove('revertSchemeDeadline')
    $serviceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    $serviceEndpoint | ConvertTo-Json -Depth 4 -Compress | Set-Variable serviceEndpointRequest
    $putApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints/$($serviceEndpoint.id)?operation=ConvertAuthenticationScheme&api-version=${apiVersion}"
    # Convert service connection
    az rest -u "${putApiUrl} " -m PUT -b $serviceEndpointRequest --headers content-type=application/json --resource $azdoResource -o json `
            | ConvertFrom-Json | Set-Variable updatedServiceEndpoint
    
    $updatedServiceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    if (!$updatedServiceEndpoint) {
        Write-Debug "Empty response"
        Write-Error "Failed to convert service connection '$($serviceEndpoint.name)'"
        exit 1
    }
    Write-Host "Successfully converted service connection '$($serviceEndpoint.name)'"
}

További információkért tekintse meg dokumentációnkat.

A Pipelines-ügynök az erőforrás-kihasználtsággal kapcsolatos problémákat jeleníti meg jobban

Tavaly októberben hozzáadtuk a Pipelines-ügynök memória- és lemezterület-használatának nyomon követését.

Annak érdekében, hogy az ügyfelek tisztában legyenek azzal, hogy erőforráskorlátokkal, például memória- vagy lemezterület-korlátozásokkal rendelkeznek az ügynökükön, láthatóbbá tettük az erőforrás-korlátozásokat:

Képernyőkép a korlátozott memória- és lemezterület-figyelmeztetésről.

Ha a fenti üzenetek bármelyikét látja, ezt okozhatja egy olyan tevékenység, amely több erőforrást használ, mint amennyit az ügynök méretez, ami azt eredményezheti, hogy az ügynök nem válaszol, és nem tud folyamatfeladatot végrehajtani:

"Leállítottuk az ügynök meghallgatását"

Ilyen esetekben engedélyezze a részletes naplókat , hogy részletesebb erőforrás-kihasználtsági üzeneteket kapjon, és nyomon kövesse, hogy az ügynök kifogyott-e az erőforrásokból. Ha saját üzemeltetésű ügynököt használ, győződjön meg arról, hogy az ügynök rendelkezik megfelelő erőforrásokkal.

A Node 6 feladatfuttató sávon kívüli telepítése

Az Azure Pipelines az ügynökcsomagok két verzióját biztosítja:

  • A vsts-agent-* csomagok támogatják a Node 6-ot futtató feladatokat.
  • A pipelines-agent-* csomagok nem támogatják a 6. csomópont futtatását igénylő feladatokat.

A saját üzemeltetésű ügynököket létrehozó ügyfelek letölthetik ezeket a Folyamatügynök kiadási oldaláról. Az ügynökhöz tartozó csomópontverziók a feladatok végrehajtására szolgálnak. Lásd a Node futóverzióit.

Az ügynökregisztrációt követően a pipelines-agent-* csomagokból telepített ügynökök mostantól letöltik az ügynökhöz nem tartozó csomópontverziókat, és nem tiltják le a "Tevékenységkorlátozások" alatt a szervezeti beállításokban. Ez lehetővé teszi, hogy az ügyfelek pipelines-agent-* ügynökcsomagokat használjanak, és a 6. csomópont telepítését "Tevékenységkorlátozásokkal" vezérelhetik a szervezeti beállításokban.

Halasztott jóváhagyás

A jóváhagyásokkal kijelentkezhet egy üzembe helyezésről. Vannak azonban olyan helyzetek, amikor a jóváhagyás megadásának időpontja és az üzembe helyezés kezdési ideje nem egyezik meg. Például az ön által áttekintett üzemelő példány esetében tudja, hogy ez egy határtalan. Képzelje el, hogy nem tud azonnal haladni, inkább az éjszaka folyamán.

Az ilyen forgatókönyvek lefedéséhez hozzáadtuk a YAML-folyamatok jóváhagyásának elhalasztására szolgáló lehetőséget. Most jóváhagyhat egy folyamatfuttatást, és megadhatja, hogy mikor legyen érvényes a jóváhagyás.

Folyamatfuttatás jóváhagyásának képernyőképe.

Ha a halasztási jóváhagyást választja, konfigurálhatja a jóváhagyás hatályba lépésének időpontját.

Képernyőkép a halasztás jóváhagyásáról.

Képernyőkép a after_approval_deferred.

A jóváhagyás halasztva jelenik meg az ellenőrző panelen. A halasztott idő elteltével a jóváhagyás érvényes.

A jóváhagyás érvényes képernyőképe.

Jóváhagyások és ellenőrzések sorrendbe állítása

Ezzel a futammal megadhatja a jóváhagyások és ellenőrzések futtatásának sorrendjét.

A jóváhagyások és ellenőrzések lehetővé teszik az éles környezetek vezérlését. Megadhatja például, hogy csak az main adattár ágán futó folyamatok használhatnak éles ARM-szolgáltatáskapcsolatot. Emellett emberi jóváhagyást is igényelhet, és hogy a rendszer teljesítménnyel ellenőrizze a teljesítményt.

A mai napig az összes jóváhagyás és ellenőrzés párhuzamosan futott, kivéve a kizárólagos zárolást. Ez azt jelentette, hogy ha az üzembehelyezési folyamatnak teljesítményellenőrzést kellett végrehajtania a manuális jóváhagyás megadása előtt, ezt nem tudta kikényszeríteni az Azure Pipelinesban. A jóváhagyási utasításokra és a belső folyamat dokumentációjára kellett támaszkodnia.

Ezzel a sprinttel a jóváhagyások és ellenőrzések sorrendbe állítását vezetjük be. A jóváhagyások és ellenőrzések öt kategóriát különböztetnek meg:

  1. Statikus ellenőrzések: Ágvezérlő, Szükséges sablon és Összetevő kiértékelése
  2. Előzetes dinamikus ellenőrzés jóváhagyás
  3. Dinamikus ellenőrzések: Jóváhagyás, Azure-függvény meghívása, REST API meghívása, munkaidő, Azure Monitor-riasztások lekérdezése
  4. A dinamikus ellenőrzés utáni ellenőrzés jóváhagyása
  5. Exkluzív zárolás

Képernyőkép az ellenőrzés hozzáadásáról.

A sorrend a Jóváhagyások és ellenőrzések lapon is megjelenik.

Képernyőkép a jóváhagyások és ellenőrzések lapról.

Az egyes kategóriákon belül az ellenőrzések párhuzamosan futnak. Vagyis ha az Azure-függvények meghívása ellenőrzéssel és munkaidő-ellenőrzéssel rendelkezik, azok egyszerre futnak.

Képernyőkép az üzembe helyezési ellenőrzésekről.

Az ellenőrzési kategóriák egyenként futnak, és ha az egyik sikertelen, a többi ellenőrzés nem lesz végrehajtva. Ez azt jelenti, hogy ha rendelkezik fiókvezérlő ellenőrzéssel és jóváhagyással, ha a fiókvezérlő meghibásodik, a jóváhagyás is sikertelen lesz. Ezért a rendszer nem küld felesleges e-maileket.

Képernyőkép a sikertelen üzembe helyezés ellenőrzéséről.

Az üzembe helyezésre az összes dinamikus ellenőrzés futtatása után, a dinamikus ellenőrzés utáni jóváhagyással, vagy manuális ellenőrzéssel jelentkezhet be, mielőtt dinamikus ellenőrzésekkel folytatná a műveletet, a jóváhagyást megelőző dinamikus ellenőrzésekkel.

YaML-folyamatok szerkesztésekor alapértelmezés szerint érvényesíteni és menteni kell

A helytelen YAML-folyamat időt és energiát pazarolhat. A folyamatszerkesztési hatékonyság javítása érdekében a szerkesztő Mentés gombját is módosítjuk YAML-ellenőrzésre.

Képernyőkép az új gombról.

Képernyőkép az ellenőrzésről és a mentésről.

Ha a folyamat hibái vannak, akkor is mentheti.

A folyamat képernyőképe érvényes.

Képernyőkép az észlelt hibákról.

Javítottuk az Ellenőrzés felületet is, hogy könnyebben megérthető listában láthassa a hibákat.

Képernyőkép a hibák listájáról.

Azure Repos

Annak megakadályozása, hogy jogosulatlan felhasználók buildszabályzatként konfigurálják a folyamatot

Annak megakadályozása, hogy jogosulatlan felhasználók buildszabályzatként konfigurálják a folyamatot

Korábban, amikor új buildelési szabályzatot adott hozzá, konfigurálhat bármilyen folyamatot a legördülő listából (beleértve azokat a folyamatokat is, amelyeket nem kapott várólista-összeállítási engedéllyel). Hasonlóképpen szerkesztheti a meglévő buildelési szabályzatot akkor is, ha az a folyamat futtatására lett konfigurálva, és nem rendelkezik queue buildelési engedéllyel.

Most megakadályozzuk, hogy a felhasználók ezt megtehassák. Ha egy felhasználó megtagadja a Queue buildelési engedélyét az adott folyamathoz, akkor a folyamat letiltottként (szürkítve) jelenik meg a legördülő menüben, amikor új buildelési szabályzatot ad hozzá.

Tekintse meg az alábbi ábrát, amelyen a "Tesztkörnyezet" nevű folyamat látható, amely megtagadja a Queue buildelési engedélyét .

Képernyőkép a tesztkörnyezet engedélyéről.

Az alábbi képen a "Tesztkörnyezet" nevű folyamat le van tiltva (szürkítve) a legördülő listában, amikor a megtagadott üzenetsor-összeállítási engedéllyel rendelkező felhasználó új buildelési szabályzatot próbál hozzáadni.

Képernyőkép a buildelési szabályzat hozzáadásáról.

Ha a "Tesztkörnyezet" nevű folyamat futtatására konfigurált buildszabályzat már létezik, akkor a Queue buildelési engedéllyel nem rendelkező felhasználó nem fogja tudni szerkeszteni vagy megtekinteni a buildelési szabályzatot. Ez az eset az alábbi képen látható.

Képernyőkép a buildérvényesítésről.

Amikor megpróbálja törölni ezt a szabályzatot, megjelenik a törlés megerősítését kérő előugró párbeszédpanel.

Képernyőkép a törlés megerősítéséről.

Ezek a módosítások a buildelési szabályzat létrehozását vagy szerkesztését eredményező API-hívásokra is érvényesek. Ha ezen műveletek bármelyike olyan felhasználói identitással fut, amely nem rendelkezik Queue buildelési engedéllyel, akkor a hívás nem adja vissza a megfelelő hibakódot, és a hibaüzenet azt jelzi, hogy “TFS.WebApi.Exception: TF401027: a művelet végrehajtásához szüksége van a QueueBuild engedélyre ezen a folyamaton."

A queue buildelési engedély nélküli API-n user identity keresztül végzett buildelési szabályzat törlése sikeres lesz, és nem történik figyelmeztetés vagy megelőzés (az API-n keresztüli törlés működése nem változik).

Azure Artifacts

Általánosan elérhető a Rust Crates támogatása

2024. február 16-tól a Rust Crates támogatása általánosan elérhető funkcióvá válik az Azure Artifacts számára. A számlázási mérők aktiválása ugyanazzal a díjszabási modellel történik, amely a többi támogatott protokollra is vonatkozik.

Az Azure Artifacts támogatása az npm-naplózáshoz

Az Azure Artifacts mostantól támogatja és npm audit fix parancsokat is támogatnpm audit. Ez a funkció lehetővé teszi a felhasználók számára, hogy a nem biztonságos csomagverziók automatikus frissítésével elemezzék és kijavítsák a projekt biztonsági réseit. További látogatásért használja az npm-naplózást a csomagok biztonsági réseinek észlelésére és elhárítására.

Következő lépések

Feljegyzés

Ezek a funkciók a következő két-három hétben jelennek meg.

Lépjen az Azure DevOpsba, és nézze meg.

Ugrás az Azure DevOpsra

Visszajelzés küldése

Szeretnénk hallani, mit gondol ezekről a funkciókról. A súgómenüvel jelentheti a problémát, vagy javaslatot adhat.

Javaslat készítése

Tanácsokat és kérdéseket is kaphat a közösség által a Stack Overflow-on.

Köszönettel:

Dan Hellem