Az Azure DevOps Server 2019 kibocsátási megjegyzései

fejlesztői közösség | rendszerkövetelményei | Licencfeltételek | DevOps Blog | SHA-1 kivonatok

Ebben a cikkben az Azure DevOps Server legújabb kiadásával kapcsolatos információkat talál.

Az Azure DevOps Server telepítésének telepítésével vagy frissítésével kapcsolatos további információkért tekintse meg Azure DevOps Server-követelmények. Az Azure DevOps-termékek letöltéséhez látogasson el az Azure DevOps Server Letöltések oldalára.

Az Azure DevOps Serverre való közvetlen frissítést az Azure DevOps Server 2020, az Azure DevOps Server 2019 vagy a Team Foundation Server (TFS) 2015 vagy újabb verzió támogatja. Ha a TFS üzembe helyezése a TFS 2010-ben vagy korábbi verzióban történik, az Azure DevOps Server 2019-re való frissítés előtt végre kell hajtania néhány időközi lépést. További információ: Helyszíni Azure DevOps telepítése és konfigurálása.

---

Biztonságos frissítés az Azure DevOps Server 2019-ről az Azure DevOps Server 2020-ra

Az Azure DevOps Server 2020 egy új folyamatfuttatási (buildelési) adatmegőrzési modellt vezet be, amely projektszintű-beállítások alapján működik.

Az Azure DevOps Server 2020 eltérő módon kezeli a buildmegőrzést a folyamatszintű adatmegőrzési szabályzatok alapján. Bizonyos szabályzatkonfigurációk a frissítés után a folyamatfuttatások törléséhez vezetnek. A manuálisan megtartott vagy a kiadás által megtartott folyamatfuttatások a frissítés után nem törlődnek.

A blogbejegyzésben további információt talál arról, hogyan frissíthet biztonságosan az Azure DevOps Server 2019-ről az Azure DevOps Server 2020-ra.

Azure DevOps Server 2019.0.1 Patch 16 Kiadás dátuma: 2023. november 14.

Közzétettünk egy javítást az Azure DevOps Server 2019 1.2-s frissítéséhez, amely az alábbi javításokat tartalmazza.

• Bővítettük a PowerShell feladatok által engedélyezett karakterek listáját az „Shell feladatok argumentum paraméterellenőrzésének engedélyezése” beállításnál.

Jegyzet

A javítások megvalósításához több lépést kell követnie a feladatok manuális frissítéséhez.

Javítások telepítése

Fontos

Az Azure Pipelines-ügynök frissítéseit 2023. szeptember 12-én adtuk ki a Patch 15 kiadásával. Ha nem telepítette az ügynökfrissítéseket a 15-ös javítás kibocsátási megjegyzéseiben leírtak szerint, javasoljuk, hogy a 16. javítás telepítése előtt telepítse ezeket a frissítéseket. Az ügynök új verziója a Patch 15 telepítése után 3.225.0 lesz.

TFX konfigurálása

1. Kövesse a tevékenységek projektgyűjteményi dokumentációba való feltöltésének lépéseit, tfx-cli használatával történő telepítéshez és bejelentkezéshez.

Feladatok frissítése A TFX használatával

Fájl	SHA-256 kivonat
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Töltse le és bontsa ki Tasks20231103.zip.
2. Módosítsa a könyvtárat a kinyert fájlokra.
3. Hajtsa végre a következő parancsokat a feladatok feltöltéséhez:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Folyamatkövetelmények

Az új viselkedés használatához egy változót AZP_75787_ENABLE_NEW_LOGIC = true kell beállítani az érintett tevékenységeket használó folyamatokban.

• A klasszikusról:

  Definiálja a változót a pipeline változó lapján.

• YAML-példa:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019.0.1 Patch 15 Kiadás dátuma: 2023. szeptember 12.

Kiadottunk egy javítást az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki.

• CVE-2023-33136: Az Azure DevOps Server távoli kódvégrehajtási biztonsági rése.
• CVE-2023-38155: Az Azure DevOps Server és a Team Foundation kiszolgáló jogosultsági biztonsági résének emelése.

Fontos

Telepítse a javítást egy tesztkörnyezetben, és győződjön meg arról, hogy a környezet folyamatai a várt módon működnek, mielőtt a javítást éles környezetben alkalmazták volna.

Jegyzet

A javítások végrehajtásához több lépést kell követnie, hogy manuálisan frissítse az ügynököt és a feladatokat.

Javítások telepítése

1. Az Azure DevOps Server 2019.0.1 Patch 15letöltése és telepítése.

Az Azure Pipelines-ügynök frissítése

1. Töltse le az ügynököt a következő forrásból: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Az ügynök üzembe helyezéséhez használja az saját üzemeltetésű Windows-ügynökök dokumentációjában ismertetett lépéseket.  

Jegyzet

Az AZP_AGENT_DOWNGRADE_DISABLED-et "true" értékre kell állítani ahhoz, hogy megakadályozzuk az ügynök leminősítését. Windows rendszeren a következő parancs használható egy felügyeleti parancssorban, amelyet újraindítás követ. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

TFX konfigurálása

1. Kövesse a tevékenységek projektgyűjteményi dokumentációba való feltöltésének lépéseit, tfx-cli használatával történő telepítéshez és bejelentkezéshez.

Feladatok frissítése A TFX használatával

1. Töltse le és bontsa ki Tasks_20230825.zip.
2. Módosítsa a könyvtárat a kinyert fájlokra.
3. Hajtsa végre a következő parancsokat a feladatok feltöltéséhez:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Folyamatkövetelmények

Az új viselkedés használatához egy változót AZP_75787_ENABLE_NEW_LOGIC = true kell beállítani az érintett tevékenységeket használó folyamatokban.

• A klasszikusról:

  Definiálja a változót a pipeline változó lapján.

• YAML-példa:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019.0.1 Patch 14 Kiadás dátuma: 2022. augusztus 8.

Kiadottunk egy javítás az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki.

• CVE-2023-36869: Azure DevOps Server hamisítási biztonsági rés.

Azure DevOps Server 2019.0.1 Patch 13 Kiadás dátuma: 2022. május 17.

Kiadottunk egy javítás az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki.

• A felhasználói Active Directory-fiók letiltása után vonja vissza az összes személyes hozzáférési jogkivonatot.

Azure DevOps Server 2019.0.1 Patch 12 Kiadás dátuma: 2022. január 26.

Kiadottunk egy javítás az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki.

• Az Elasticsearch biztonsági rését úgy hárította el, hogy eltávolította a jndilookup osztályt a log4j bináris fájlokból.

Telepítési lépések

1. Frissítse a kiszolgálót a Patch 12alkalmazással.
2. Ellenőrizze a beállításjegyzék értékét a HKLM:\Software\Elasticsearch\Version. Ha a beállításjegyzék értéke nincs megadva, adjon hozzá egy sztringértéket, és állítsa a Verzió 5.4.1 értékre (Név = Verzió, Érték = 5.4.1).
3. Futtassa a PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update frissítési parancsot a readme fájlban megadott módon. A következőhöz hasonló figyelmeztetés jelenhet meg: Nem lehet csatlakozni a távoli kiszolgálóhoz. Ne zárja be az ablakot, mert a frissítés újrapróbálkozásokat végez, amíg be nem fejeződik.

Jegyzet

Ha az Azure DevOps Server és az Elasticsearch különböző gépekre van telepítve, kövesse az alábbi lépéseket.

1. Frissítse a kiszolgálót a Patch 12alkalmazással.
2. Ellenőrizze a beállításjegyzék értékét a HKLM:\Software\Elasticsearch\Version. Ha a beállításjegyzék értéke nincs megadva, adjon hozzá egy sztringértéket, és állítsa a Verzió 5.4.1 értékre (Név = Verzió, Érték = 5.4.1).
3. Másolja a zip nevű mappa tartalmát a C:\Program Files\{TFS Version Folder}\Search\zip meghajtóról az Elasticsearch távoli fájlok mappájába.
4. Futtassa a(z) Configure-TFSSearch.ps1 -Operation update programot az Elasticsearch kiszolgálói gépen.

SHA-256 kivonat: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Azure DevOps Server 2019.0.1 Patch 11 Kiadás dátuma: 2021. augusztus 10.

Kiadottunk egy javítás az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki.

• Javítsa ki a builddefiníció felhasználói felületének hibáját.

Azure DevOps Server 2019.0.1 Patch 10 kiadás dátuma: 2021. április 13.

Kiadottunk egy javítást az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki.

• CVE-2021-27067: Információfeltárás

A 10. javítás alkalmazásához telepítenie kell a AzureResourceGroupDeploymentV2 feladatot.

AzureResourceGroupDeploymentV2 feladattelepítés

Jegyzet

Az alábbiakban említett összes lépést Windows rendszerű gépen kell végrehajtani

Felszerel

1. Bontsa ki a AzureResourceGroupDeploymentV2.zip csomagot egy új mappába a számítógépen. Például: AzureResourceGroupDeploymentV2.

2. Töltse le és telepítse Node.js 14.15.1 és npm (a Node.js letöltésével együtt) a gépének megfelelően.

3. Nyisson meg egy parancssort rendszergazda módban, és futtassa a következő parancsot a tfx-cli telepítéséhez.

npm install -g tfx-cli

4. Hozzon létre egy személyes hozzáférési jogkivonatot teljes hozzáférésű jogosultságokkal, és másolja ki. Ez a személyes hozzáférési jogkivonat a tfx bejelentkezési parancs futtatásakor lesz használva.

5. Futtassa a következőt a parancssorból. Amikor a rendszer kéri, adja meg a szolgáltatás URL-címét és a személyes hozzáférési jogkivonatot.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Futtassa a következő parancsot a feladat kiszolgálóra való feltöltéséhez. Használja az 1. lépésből kinyert .zip fájl elérési útját.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 Patch 9 Kiadás dátuma: 2020. december 8.

Kiadottunk egy javítás az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki. További információért tekintse meg a blogbejegyzést.

• CVE-2020-1325: Azure DevOps Server hamisítási biztonsági rés
• CVE-2020-17135: Azure DevOps Server hamisítási biztonsági rés
• CVE-2020-17145: Azure DevOps Server és Team Foundation Server spoofing sebezhetőség
• Kijavítottuk azt a hibát, amely miatt a TFVC nem dolgozza fel az összes eredményt

Fontos

A javítás telepítése előtt olvassa el az alábbi teljes utasításokat.

Általános javítástelepítés

Ha az Azure DevOps Server 2019.0.1 verzióval rendelkezik, telepítse Azure DevOps Server 2019.0.1 Patch 9.

A telepítés ellenőrzése

• 1. lehetőség: Futtassa a devops2019.0.1patch9.exe CheckInstall-t, a devops2019.0.1patch9.exe az a fájl, amelyet a fenti linkről letöltött. A parancs kimenete vagy azt fogja mondani, hogy a javítás telepítve van, vagy nincs telepítve.

• 2. lehetőség: Ellenőrizze a következő fájl verzióját: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Az Azure DevOps Server 2019 alapértelmezés szerint a c:\Program Files\Azure DevOps Server 2019-ra települ. Az Azure DevOps Server 2019.0.1 Patch 9 telepítése után a verzió 17.143.30723.4 lesz.

AzurePowerShellV4 feladat telepítése

Jegyzet

Az alábbiakban említett összes lépést Windows rendszerű gépen kell végrehajtani

Előfeltételek

1. Telepítse az Azure PowerShell Az modult a magánügynök gépére az Azure PowerShell segítségével.

2. Hozzon létre egy folyamatot az AzurePowerShellV4 feladattal. A feladatban csak egy hiba a standard hibaértéken lesz látható.

Felszerel

1. Bontsa ki a AzurePowerShellV4.zip csomagot egy AzurePowerShellV4nevű mappába.

2. Töltse le és telepítse Node.js 14.15.1 és npm (a Node.js letöltésével együtt) a gépének megfelelően.

3. Nyisson meg egy parancssort rendszergazda módban, és futtassa a következő parancsot a tfx-cli telepítéséhez.

npm install -g tfx-cli

4. Hozzon létre egy személyes hozzáférési jogkivonatot teljes hozzáférésű jogosultságokkal, és másolja ki. Ez a személyes hozzáférési jogkivonat a tfx bejelentkezési parancs futtatásakor lesz használva.

5. Futtassa a következőt a parancssorból. Amikor a rendszer kéri, adja meg a szolgáltatás URL-címét és a személyes hozzáférési jogkivonatot.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Futtassa a következő parancsot a feladat kiszolgálóra való feltöltéséhez. A kinyert csomag elérési útja D:\tasks (1)\AzurePowerShellv4lesz.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 Patch 8 Kiadás dátuma: 2020. szeptember 8.

Kiadottunk egy biztonsági javítást az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki. További információért tekintse meg a blogbejegyzést.

• DTS 1713492 – Váratlan viselkedés, amikor AD-csoportokat ad hozzá a biztonsági engedélyekhez.

Az Azure DevOps Server 2019.0.1 7-es frissítésének kiadási dátuma: 2020. július 14.

Kiadottunk egy biztonsági javítást az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki. További információért tekintse meg a blogbejegyzést.

• CVE-2020-1326: Helyek közötti szkriptelési biztonsági rés
• A buildelési folyamat helytelen kapcsolatot mutat a jogosulatlan felhasználók számára az Egyéb Git-forrás kiválasztásakor.
• Javításra került a hiba, amikor az XAML build definícióban az öröklődést bekapcsoltra vagy kikapcsoltra változtatja.

Az Azure DevOps Server 2019.0.1 6-os patch kiadási dátuma: 2020. június 10.

Kiadottunk egy biztonsági javítást az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki. További információért tekintse meg a blogbejegyzést.

• CVE-2020-1327: Győződjön meg arról, hogy az Azure DevOps Server megtisztítja a felhasználói bemeneteket
• Sha2 támogatása az SSH-ban az Azure DevOpsban

Azure DevOps Server 2019.0.1 Patch 5 Kiadás dátuma: 2020. március 10.

Kiadottunk egy biztonsági javítást az Azure DevOps Server 2019.0.1-hez, amely az alábbiakat javítja ki. További információért tekintse meg a blogbejegyzést.

• CVE-2020-0700: Helyek közötti szkriptelési biztonsági rés
• CVE-2020-0758: Jogosultsági biztonsági rés emelése
• CVE 2020-0815: Jogosultsági biztonsági rés emelése

Azure DevOps Server 2019.0.1 Patch 3 kiadás dátuma: 2019. szeptember 10.

Kiadottunk egy biztonsági javítás az Azure DevOps Server 2019.0.1-hez, amely az alábbi hibákat javítja ki. További információért tekintse meg a blogbejegyzést.

• CVE-2019-1305: Helyek közötti szkriptelés (XSS) biztonsági rés a tárakban
• CVE-2019-1306: Távoli kódvégrehajtás biztonsági rése a Wikiben

---

Azure DevOps Server 2019.0.1 2. javítás kiadási dátuma: 2019. augusztus 13.

Kiadottunk egy biztonsági javítást az Azure DevOps Server 2019.0.1-hez, amely az alábbi hibát javítja ki. További információért tekintse meg a blogbejegyzést.

• A szolgáltatáskapcsolatok adataival egyértelművé tettük, hogy alapértelmezés szerint minden csővezetékhez engedélyezve vannak.

---

Azure DevOps Server 2019.0.1 Patch 1 Kiadás dátuma: 2019. július 9.

Kiadottunk egy biztonsági javítás az Azure DevOps Server 2019.0.1-hez, amely az alábbi hibákat javítja ki. További információért tekintse meg a blogbejegyzést.

• CVE-2019-1072: Távoli kódvégrehajtási biztonsági rés a munkaelemek nyomon követésében
• CVE-2019-1076: Helyek közötti szkriptelés (XSS) biztonsági rése a lekéréses kérelmekben

---

Azure DevOps Server 2019.0.1 kiadás dátuma: 2019. május 21.

Azure DevOps Server 2019.0.1 hibajavítások összesítője. Tartalmazza a korábban kiadott Azure DevOps Server 2019-javítások összes javítását. Közvetlenül telepítheti az Azure DevOps Server 2019.0.1-et, vagy frissíthet az Azure DevOps Server 2019-ről vagy a Team Foundation Server 2012-ről vagy újabbról.

Jegyzet

Az adatmigrálási eszköz körülbelül három héttel a kiadás után elérhető lesz az Azure DevOps Server 2019.0.1-hez. Az importálási jelenleg támogatott verzióinak listáját itt találja.

Ez a kiadás a következő hibák javítását tartalmazza:

Azure Boards

• "A terv mezőfeltételeinek hibája van." a terv konfigurálásakor. A Fejlesztői közösségáltal jelentett.
• Az apiwitcontroller.executequery kivételt eredményez, ha egy lekérdezésnek több oszlopa is van.
• A vso.work_full oauth hatókört használó ügyfélobjektum-modellben a WorkItemServer.DownloadFile() sikertelen.
• Ha beágyazott képet másol egy munkaelem-mezőből egy másik projekt másik munkaelem-mezőjébe, az hibás képet eredményezhet.

Azure-adattárak

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

• A Test Analytics tab egy csillagot (*) tartalmaz, amely az előnézetet jelzi, annak ellenére, hogy ez a funkció nincs előzetes verzióban.
• A Kiadások lapon a biztonság kezelésére szolgáló művelet mostantól minden felhasználó számára megjelenik, függetlenül attól, hogy módosíthatják-e az engedélyeket.
• A Kiadási kezdőoldalakon a kiadási tervezet indítása művelet új kiadást hozott létre, de most elindítja a kiadástervezetet.

Azure-tesztcsomagok

• A TestRuns és a TestResults CompletedDate 1 órás szűrője túl részletes.
• A Test Case munkaelemtípusban a "Test Case" típus nem honosítandó.
• A tesztelési esetek nem jelennek meg az MTM-ben vagy a böngészőben.
• "Érvényesítési szakasz: Nem rendelkezik engedéllyel a kiadások aktiválására a társított kiadási folyamaton" hibaüzenet jelenik meg, amikor automatizált teszteket futtat egy teszttervből. A Fejlesztői közösségáltal jelentett.
• A törlési APIsegítségével tesztesetek törölhetők más projektekből. A Fejlesztői közösségáltal jelentett.
• A Tesztfuttatóban a munkaelem hivatkozására kattintva megnyílik a munkaelem URL-címe a Tesztfuttatóban az alapértelmezett böngésző helyett.
• A teszteset állapota nem frissül azon felhasználók esetében, amelyek kijelentkeznek a Tesztfuttatóból.
• A felhasználónév és az e-mail-cím nem jelenik meg a Tesztfuttató felhasználói legördülő listájában.

Azure Artifacts

• Feljebb és Feljebb nem honosított a felsőbb rétegben.

Adatelemzés

• Az elemzési jelentések hiányos adatokat jeleníthetnek meg, mert a modell "készként" van megjelölve a tényleges befejezés előtt.
• A sebesség-, felfutási- és leégési widgetek különböző tervezett munkát mutatnak a felhasználók számára, akik különböző időzónákban vannak.
• A karbantartás során az Analytics-adatok betöltése visszatartható, ami elavult jelentéseket okozhat.

Általános

• A bal oldali navigációs elemek összeszorulnak az IE-n, ha nincs elég hely.

Adminisztráció

• További naplózás hozzáadva a Gyűjtemény frissítéséhez a hibák hibakereséséhez.
• Ha a TfsConfig offlineDetach sikertelen, a hibaüzenet nem használható.
• A TfsJobAgent szolgáltatás összeomlik.
• A keresési bővítmény telepítése a konfiguráció befejezése után nem történik meg.
• A felügyeleti konzol nem válaszol, ha a konfigurációs adatbázis sérült.
• Előfordulhat, hogy a Service Hooks nem megfelelően dolgozza fel az értesítéseket.
• A Kódkeresés indexelése nem indul el a Keresés konfigurálása után.
• A keresési oldalak találatai között vannak nem lokalizált sztringek.

Ez a kiadás a következő frissítést tartalmazza:

Visual Studio 2019 (VS2019) támogatása a Visual Studio Tesztfeladatban

Hozzáadtuk a Visual Studio 2019 támogatását a pipeline-okban lévő Visual Studio Teszt feladathoz. Ha a Visual Studio 2019 tesztplatformjának használatával szeretne teszteket futtatni, válassza a Legújabb vagy Visual Studio 2019 lehetőségeket a Tesztplatform verzió legördülő listájából.

---

Azure DevOps Server 2019 Patch 2 kiadás dátuma: 2019. május 14.

Kiadottunk egy biztonsági javítást az Azure DevOps Server 2019-hez, amely az alábbi hibákat javítja ki. További információért tekintse meg a blogbejegyzést.

• CVE-2019-0872: Helyek közötti szkriptelés (XSS) biztonsági rés a tesztcsomagokban
• CVE-2019-0971: Információfeltárás biztonsági rése a Repos API-ban
• CVE-2019-0979: Helyek közötti szkriptelés (XSS) biztonsági rés a Felhasználói központban

---

Az Azure DevOps Server 2019 1. patch kiadási dátuma: 2019. április 9.

Kiadottunk egy biztonsági javítást az Azure DevOps Server 2019-hez, amely az alábbi hibákat javítja ki. További információért tekintse meg a blogbejegyzést.

• CVE-2019-0857: A wiki hamisítási biztonsági rése
• CVE-2019-0866: Távoli kódvégrehajtási biztonsági rés a csővezetésekben
• CVE-2019-0867: Helyek közötti szkriptelés (XSS) biztonsági rése a Pipelinesban
• CVE-2019-0868: Helyek közötti szkriptelés (XSS) biztonsági rése a Pipelines rendszerben
• CVE-2019-0869: HTML-injektálási biztonsági rés a Pipelinesban
• CVE-2019-0870: Kereszthelyszínű szkriptelési (XSS) sérülékenység a pipelienekben.
• CVE-2019-0871: Helyek közötti szkriptelés (XSS) biztonsági rése a Pipelines-ben
• CVE-2019-0874: Cross-site scripting (XSS) sérülékenység a Pipeline-okban
• CVE-2019-0875: Jogosultság-emelési sebezhetőség a táblákban

---

Az Azure DevOps Server 2019 kiadási dátuma: 2019. március 5.

Jegyzet

Az Adatmigrálási eszköz körülbelül három héttel a kiadás után lesz elérhető az Azure DevOps Server 2019-ben. Az importálási jelenleg támogatott verzióinak listáját itt találja.

---

RC2 kiadási dátum: 2019. január 22.

Az Azure DevOps Server 2019 RC2 újdonságainak összefoglalása

Az RC2-hez a következő funkciókat adtuk hozzá:

• GitHub Enterprise commit-ek és pull requestek csatolása az Azure Boards munkaelemeihez
• Buildek konfigurálása YAML- használatával
• A kártyajegyzetek tartalmazzák a hibákat és az egyéni munkaelem-típusokat
• Továbbfejlesztett ágválasztó
• Változások az artefaktumok és a kiadáskezelési üzembe helyezési folyamat licencelésében

---

RC1 Kiadás dátuma: 2018. november 19.

Az Azure DevOps Server 2019 RC1 újdonságainak összefoglalása

Az Azure DevOps Server 2019 új navigációs felületet és számos új funkciót vezet be. Néhány fontos elem:

• Új navigációs felület
• Az Elemzési piactér jelentéskészítési bővítménye már elérhető
• Az Azure SQL Database támogatása
• Folyamatok öröklése új gyűjteményekben
• Új Munkaelemek Központ
• Új táblák, backlogok és sprintközpontok
• Új lekérdezések felület
• Lekéréses kérelmek leírásának szabványosítása sablonokkal
• Lekéréses kérelem célágának módosítása
• Felépítési folyamatok kezelése az új Builds oldal használatával
• A kiadási folyamatok kezelése az új Kiadások lapjának használatával
• Kiadási folyamat vizualizációja
• A(z) ügynöke helyi frissítése
• Fokozatosan fedje fel és hajtsa végre szakaszosan az üzembe helyezéseket kiadási kapuk révén
• felsőbb rétegbeli források
• Tartalomjegyzék létrehozása wikilapokhoz

Az új funkciók megtekintéséhez az egyes szakaszokra is ugorhat:

• Általános
• Táblák
• tárházak
• csővezetékek
• teszttervek
• Tárgyak
• Wiki
• jelentéskészítési

---

Általános

Az Azure DevOps Server bejelentése

Szeptember 10-én bejelentettük, hogy az Azure DevOps a Visual Studio Team Services és a Team Foundation Server fejlesztése. Az Azure DevOps Server 2019 az első helyszíni kiadásunk ezzel az új márkával. További információt blogbejegyzésünkben talál.

Új navigációs felület

Új navigációt vezetünk be a felhasználói élmény modernizálásához. Ez az új navigáció az Azure DevOps szolgáltatásban jelent meg, és már elérhető az Azure DevOps Server 2019-ben. További információért tekintse meg blogunk.

Összetevők és kiadáskezelési üzembehelyezési folyamat licencelésének módosítása

A felhasználói visszajelzések alapján az Azure DevOps Server 2019-ben két fő módosítást hajtunk végre a licenceinken. Először is az ügyfeleknek már nem kell megvásárolnia az Artifact bővítményt az Artifacts használatához. Az Artifacts-licencek használata mostantól az alapszintű licenc részét képezi. Mostantól minden olyan felhasználó használhatja az összetevőket, akiknek hozzá van rendelve alapszintű licenc. Másodszor, az ügyfeleknek többé nem kell megvásárolniuk a Kiadáskezelési telepítési csővezetéket. A buildelési folyamatokhoz hasonlóan a kiadáskezelési üzembehelyezési folyamatok is bekerülnek az Azure DevOps Server 2019-be.

Az Azure SQL Database támogatása

Az Azure DevOps 2019 Azure-ban való futtatásának egyszerűsítése érdekében engedélyeztük az Azure SQL Database támogatását (általános célú S3 vagy újabb). Lehetővé teszi, hogy az igényeinek megfelelően kihasználja a széles körű biztonsági mentési funkciókat és a skálázási lehetőségeket, miközben csökkenti a szolgáltatás futtatásával járó adminisztratív terheket. Vegye figyelembe, hogy a gazda virtuális gépnek ugyanabban az Azure-régióban kell lennie, mint az adatbázis, hogy a késés alacsony maradjon. További információért tekintse meg a dokumentációját.

Munkaelem & az ügyfélobjektum-modell SOAP API-jának tesztelése a jövőbeli verziókban

Az Azure DevOps Server 2019 továbbra is támogatja a SOAP API és az ügyfélobjektum-modell munkaelem-nyomon követését. Az Azure DevOps Server későbbi verzióiban azonban elavultként lesz megjelölve. További információt találhat a dokumentációnkban.

Folyamatöröklés új gyűjteményeken

A folyamatöröklés mostantól elérhető az új gyűjteményekben. A felhasználóknak lelkiismereti döntést kell hozniuk a folyamatmodellről egy új gyűjtemény létrehozásakor. Tekintse meg dokumentációnk, hogy mi az öröklési modell, és miben különbözik az XML-től.

Kibontott keresőmező

Tisztában vagyunk a keresés fontosságával, és visszahozzuk a termék fejlécére a kibővített keresőmezőt. Emellett most már meghívhatja a keresőmezőt úgy, hogy az Azure DevOps bármely szolgáltatásoldalán a "/" gombra kattint.

Itt található az alapértelmezett keresőmező:

A "/" beírása után megjelenik a kibontott keresőmező:

A munkám lebegő panelja

Nagy örömmel mutatjuk be az új funkciót: a a munkám felugró panelt. Visszajelzést kaptunk arról, hogy ha a termék egyik részén van, és egy másik részből szeretne információt kapni, nem szeretné elveszíteni a kontextusát. Ennek az új funkciónak köszönhetően a termék bármely pontjáról elérheti ezt az előugró panelt, amely gyors áttekintést nyújt fontos információkról, beleértve a munkaelemeket, a lekéréses kérelmeket és az összes kedvencet. Ezzel az új lebegő panellel, ha mélyen elmerül a kódolásban a Tárakban, de aztán gyorsan ellenőrizné, hogy melyik munkaelem következik, egyszerűen kattintson a panelre, és megtekintheti az önhöz rendelt munkaelemeket, és felveheti a következő elemet.

Az alábbiakban láthatja a munka beállításaim paneljét, ami a hozzám rendelt feladatokat mutatja:

Itt láthatja a második kimutatást, amely a hozzám rendelt PR-ket jeleníti meg. A legördülő panelen egy kattintással további lekéréses kérelmeket is megtekinthet.

Itt láthatja az utolsó pivotot, amely minden olyan dolgot tartalmaz, amit kedvencként jelölt. Ide tartoznak a kedvenc csapatai, irányítópultjai, táblái, hátralékai, lekérdezései és adattárai:

Táblák

GitHub Enterprise commit-ek és pull kérelmek csatolása az Azure Boards munkaelemeihez

Azok a csapatok, amelyek a GitHub Enterprise-t használják a kódhoz, és gazdag projektkezelési képességeket szeretnének, mostantól integrálhatják az adattáraikat az Azure Boardsba. A GitHub és az Azure Boards összekapcsolásávalminden olyan funkciót megkaphat, mint a hátralékok, táblák, sprinttervezési eszközök, több munkaelem-típus, és továbbra is rendelkezik a GitHub fejlesztői munkafolyamataival integrálható munkafolyamattal.

A véglegesítések és lekéréses kérelmek összekapcsolása a munkaelemekhez egyszerű. Említse meg a munkaelemet a következő szintaxissal:

AB#{work item ID}

Említsen meg egy munkaelemet egy véglegesítési üzenetben, a lekéréses kérelem címében vagy a lekéréses kérelem leírásában, és az Azure Boards létrehoz egy hivatkozást az összetevőre. Fontolja meg például a következőhöz hasonló véglegesítési üzenetet:

Adds support for deleting connections. Fixes AB#20.

Ezzel létrehoz egy hivatkozást a 20. munkaelemből a Véglegesítéshez a GitHubon, amely a munkaelem fejlesztési szakaszában jelenik meg. ​

Ha a "javítás", a "javítások" vagy a "javítva" szavak előzik meg a munkaelem említést (a fent látható módon), a munkaelem kész állapotba kerül, amikor a véglegesítést az alapértelmezett ágba egyesítik.

Azok a csapatok, amelyek az Azure Pipelines használatával építenek kódot a GitHubon, a build összegzésében a GitHub-véglegesítésekhez csatolt munkaelemeket is látni fogják.

Új Munkafeladatok központ

A Munkaelemek központ az új központunk, amely a munkaelemek otthonaként szolgál majd! Itt számos különböző listanézete van a munkaelemekről, amelyek hatóköre le van osztva az Ön számára. Megtekintheti a hozzám rendelt összes munkát a Hozzám rendelt nézetben, hogy gyors áttekintést kapjon, vagy a Nemrég frissített, amely a projektben a legutóbb frissített összes munkaelemet jeleníti meg. Az összes listabeállítás alább látható:

Ha még tovább szeretné hatókörbe helyezni a listákat, szűrhet a típusra, az állapotra, a területre, a címkékre és a kulcsszóra. Miután megkapta a kívánt listanézetet, az oszlop fejlécére kattintva rendezheti a munkaelemeket. Ha egy oszlop túl keskeny az oszlop teljes tartalmának megtekintéséhez, egyszerűen átméretezheti az oszlopot a fejlécterületen. Ezek az élmények alább láthatók:

Új táblák, hátralékok és sprintközpontok

A backlogs hub három különálló központra volt felosztva a felhasználói élmény javítása érdekében. Bár hatékony volt, a régi backlogs hub túl sok funkciónak adott otthont. Ez gyakran megnehezítette a felhasználók által keresett funkció vagy képesség megtalálását. A probléma megoldásához felosztottuk a hátralékközpontot a következőre:

• A backlogs hub mostantól csak a projekt hátralékainak ad otthont. A hátralék a csapat számára fontossági sorrendbe sorolt munkalista. A hátralékok olyan tervezési eszközöket biztosítanak, mint a munkaelem-hierarchia, az előrejelzés és az új futamtervezési élmény.
• Az új Boards központ minden Kanban-táblának otthont ad egy projekthez. A táblák az állapot és a folyamat kommunikálására szolgálnak. A kártyák (munkaelemek) balról jobbra haladnak a táblán a csapat által meghatározott oszlopokon keresztül.
• Az új Sprints hub ad otthont a munka növekményének megtervezéséhez és végrehajtásához használt funkcióknak. Minden sprint tartalmaz egy sprint teendők listáját, egy feladattáblát, valamint egy nézetet a csapat kapacitásának kezelésére és beállítására.

Új lekérdezési központ

Az új lekérdezési központ modernebb megjelenéssel és kialakítással egyszerűsíti a régi központ számos meglévő lekérdezési funkcióját, valamint új képességeket biztosít a fontos lekérdezések könnyebb elérése érdekében. Az új felület néhány fontos eleme:

• Az utoljára módosította információval rendelkező címtár oldalak és a lekérdezések keresésének lehetősége
• A mappák egyedi URL-címeivel rendelkező breadcrumb a fontos lekérdezéscsoportok könyvjelzőihez
• A kedvenc lekérdezésekhez való gyors hozzáférés az eredmények oldaláról

További információkat ezekről az izgalmas frissítésekről a DevOps blogontalál.

Munkaelemek áthelyezése egy másik projektbe, és munkaelemtípus módosítása

Most már módosíthatja a munkaelem típusát, vagy áthelyezheti a munkaelemeket egy projektcsoporton belüli másik projektbe. Ezekhez a funkciókhoz le kell tiltani az adattárházat. Ha az adattárház le van tiltva, az Analytics Service segítségével támogathatja a jelentéskészítési igényeket. További információ az adattárház letiltásáról: Az adattárház és a kockaletiltása.

Sprinttervezési funkciók

Az új sprinttervezési funkciók megkönnyítik és javítják a futamtervezési élményt.

• Hozza létre a következő futamot, vagy iratkozzon fel egy meglévő futamütemezésre közvetlenül a Sprints hubról.
• A hátralék új Tervezés paneljában húzza és ejtse a munkaelemeket a jövőbeli sprintekbe. A Tervezés panel a sprint dátumait, a feladatok számát és a tervezett erőfeszítést tartalmazza.
• Adjon hozzá követelményeket a Feladattábla tetejére, vagy a gyors létrehozási opcióval vegye fel a sprint-hátralékba, a felső, az alsó vagy egy választott sorba.
• Használjon szűrőket a Hozzárendelt személy, Munkaelem típusa, Állapot és Címkék szerint a nézetek igényeihez való igazításához.

Új címtárlapok

Az összes új csomópont, beleértve a hátralékokat, a táblákatés a sprinteket, mostantól az alábbi szakaszokkal vannak rendszerezve az új címtár oldalak:

• Folytassa ott, ahol abbahagyta Az új szakasz közvetlen kapcsolatot biztosít az utoljára látogatott (tábla | backlog | sprint) részhez.
• Kedvencek Az összes kedvenc táblád, futamod és hátralékod az összes csapatban.
• A azoknak a csapatoknak, amelyekhez tartozol, az összes táblája, hátraléka és futama.
• Minden A tábláid, teendőid és sprintek listája.

Új nézet beállításai menü

Az új központok, köztük hátralékok, táblákés futamok, új Nézetbeállítások menüvel rendelkeznek. Ez egy új otthon minden művelethez az elrendezés és a laptartalom testreszabásához. A Nézetbeállítások segítségével további nézeteket engedélyezhet, például megjelenítheti a hierarchiát a hátralékokban, vagy módosíthatja a Csoport szerint beállítást egy feladattáblán, bekapcsolhatja az oldalpanelt a leképezéshez és a futamok tervezéséhez, vagy megismerheti a munka részleteit ábrázoló diagramokat.

További információ ezekről az izgalmas frissítésekről, az új Csapatprofil panelről és a Kedvencekről a DevOps blog.

A kártya megjegyzései közé tartoznak a hibák és az egyedi munkaelem-típusok

Az emberek az intuitív ellenőrző lista nézet és interakció miatt kedvelik a kártyajegyzeteket. Korábban a kártya megjegyzések alapértelmezett hátralék szintjeire korlátozódtak, és nem támogatták a hibákat vagy az egyedi típusokat. Az új kiadással megszüntettük a munkaelemtípusokra vonatkozó korlátozást, és lehetővé tettük a hibák és az egyéni munkaelem-típusok kártyajegyzetként való megjelenítését.

A kártyajegyzetek táblabeállításai ki lettek bővítve, hogy az adott teendőlistaszinthez elérhető összes munkaelem-típust tartalmazzák.

Ha engedélyezve van a munkaelem széljegyzete, az adott munkaelemtípus számlálása külön ellenőrzőlistaként szerepel a kártyán.

Az engedélyezett munkaelem-típusok gyors létrehozása a kártya helyi menüjében is elérhető.

Munka áthelyezése a javasolt területek és iterációk használatával

Gyakori, hogy ugyanazon a területen vagy iterációban dolgozik, és a munkaelemek áthelyezésekor többször is végigböngészi a hierarchiát. A Terület és Iterációs útvonalvezérlői mostantól tartalmazzák a legutóbb használt értékek listáját Javaslatok, így gyorsan beállíthatja és továbbléphet.

Emellett iterációs dátumok is szerepelnek a név jobb oldalán, így gyorsan megállapíthatja, hogy mikor kell kézbesíteni egy munkaelemet.

Az iterációs ütemezésben végzett lekérdezések +/- @CurrentIteration időközzel

A @CurrentIteration makró, amely segít a csapatnak nyomon követni a munkát az iterációs ütemezés alapján, mostantól támogatja az egész szám eltolását. Könnyedén nyomon követheti a @CurrentIteration - 1-gyel nem lezárt munkát, vagy megtekintheti az előre tervezett munkát jövőbeli iterációkra a @CurrentIteration + 1 használatával. További információért tekintse meg a @CurrentIteration bejegyzését a Microsoft DevOps blogján.

A lekérdezési iteráció ütemezésének tisztázása a @CurrentIteration Csapat paraméterrel

Ha korábban már használta a @CurrentIteration makrót a lekérdezésekben, észrevehette, hogy az eredmények eltérőek lehetnek, ha a Csapat környezete eltérő iterációs ütemezéssel változik a Teamsben. Most, amikor létrehoz vagy módosít egy lekérdezést a @CurrentIteration makróval, ki kell választania azt a csapatot is, amely a lekérdezés szempontjából releváns iterációs ütemezéssel rendelkezik. A Csapat paraméterrel a @CurrentIteration makrót ugyanabban a lekérdezésben, de a csapatok között is használhatja. Ilyen lehet például két különböző csapatprojekt munkaelemeinek lekérdezése, amelyek különböző iterációs neveket és ütemezéseket használnak. Ez azt jelenti, hogy nem kell többé frissítenie a lekérdezéseket a futamok változásakor! További információért tekintse meg a @CurrentIteration bejegyzését a Microsoft DevOps blogján.

Egy csapat területi útjainak lekérdezése az új @TeamAreas makró segítségével

A csapat beállításaiban társíthat egy vagy több területútvonalat, amelyek segítenek a hátralékokat, táblákat, terveket, sőt, az irányítópultokat is kifejezetten az adott csapat munkájára összpontosítani. Ha azonban egy csapathoz szeretne lekérdezést írni, a lekérdezési záradékokban fel kellett sorolnia az adott csapat területútvonalait. Most egy új @TeamAreas makró érhető el, amely könnyen hivatkozhat a megadott csapathoz tartozó területútvonalakra.

Üres rich text mezők lekérdezése

Az új IsEmpty lekérdezési operátor használatával keressen olyan munkaelemeket, amelyek üres rich text mezővel (például Leírás) rendelkeznek.

Az összekapcsolási és említési funkciókban könnyen megtalálhatók a meglévő munkaelemek.

Ha két meglévő munkaelemet szeretne összekapcsolni, az új munkaelem-keresési vezérlővel egyszerűen megtalálhatja az Önnek fontos elemet. A lekérdezésválasztót a közelmúltban elért munkaelemek alapján beágyazott javaslatok, valamint egy belépési pont váltotta fel, amellyel azonosító vagy cím alapján kereshet egy adott munkaelemet.

Munkaelemek megnyitása a keresésből

Korábban nem lehetett megnyitni egy munkaelemet a keresési eredmények oldaláról, ha a munkaelem előnézeti panelje ki lett kapcsolva. Ez megnehezítené a keresési eredmények áttekintését. Most a munkaelem címére kattintva megnyithatja a munkaelemeket egy modális ablakban.

Repos

Továbbfejlesztett ágválasztó

Az Azure-adattárak legtöbb szolgáltatásához ki kell választania egy adattárat, majd egy ágat az adattárban. A nagy számú ággal rendelkező szervezetek számára ez a felhasználói élmény javítása érdekében egy új ágválasztót vezetünk be. A választó mostantól lehetővé teszi a kedvenc ágaid kiválasztását vagy az ágak gyors keresését.

Értesítések fogadása pull-kérelmek szabályzatok megkerülése esetén

A lekéréses kérelmeket (PRs) és ágszabályzatokathasználó csapatok esetében előfordulhatnak olyan esetek, amikor az embereknek felül kell írniuk és meg kell kerülniük ezeket a házirendeket – például amikor gyorsjavítást helyeznek üzembe egy éles problémára az éjszaka közepén. Érdemes megbízni a fejlesztőkben, hogy helyesen cselekedjenek, és takarékosan használják a felülbírálási képességet. A csapatoknak ugyanakkor módot kell adni annak ellenőrzésére, hogy a szabályzat felülbírálásait a megfelelő helyzetekben használják-e. Ennek támogatásához új értesítési szűrőt adtunk hozzá, amely lehetővé teszi, hogy a felhasználók és a csapatok e-mailes riasztásokat kapjanak a szabályzat megkerülésekor. Kezdje a Egy lekéréses kérelem létrehozása vagy frissítése sablonnal, majd válassza Szabályzat megkerülése lehetőséget a szűrők listájából. Válassza ki a Szabályzatok megkerülése értéket, és értesítést kap, ha egy lekéréses kérelem befejeződik és a szabályzatok megkerülésére került sor.

Az ágszabályzatok megkerülésének engedélyezése a leküldéses védelem feladása nélkül.

Számos olyan forgatókönyv van, amikor előfordulhat, hogy ki kell kerülnie egy ágpolitikát – visszaállíthat egy olyan módosítást, amely buildhibát okozott, gyorsjavítást alkalmaznia kell az éjszaka közepén stb. Korábban egy ("Kivétel a szabályzatkényszerítés alól") engedélyt kínáltunk, amely segít a csapatoknak kezelni, hogy mely felhasználók kapták meg a jogot az ágpolitikák megkerülésére egy lekéréses kérelem végrehajtásakor. Ez az engedély azonban lehetővé tette, hogy közvetlenül az ágra toljon, és a teljes PR-folyamatot megkerülje.

A felhasználói élmény javítása érdekében felosztottuk a régi engedélyt, hogy több vezérlést biztosítsunk a megkerülési engedélyeket biztosító csapatoknak. A régit két új engedély váltja fel:

1. A lekéréses kérelmek végrehajtásakor megkerülheti a szabályzatokat. Az ezzel az engedéllyel rendelkező felhasználók használhatják a lekéréses kérelmek "Felülbírálás" felületét.
2. Az előírások megkerülése feltöltéskor. Az ezzel az engedéllyel rendelkező felhasználók közvetlenül feltölthetik azokat az ágakat, amelyekhez szükséges szabályzatok vannak beállítva.

Ha megadja az első engedélyt, és megtagadja a másodikat, a felhasználó szükség esetén használhatja a megkerülési lehetőséget, de továbbra is védelemmel fog rendelkezni a szabályzatokkal rendelkező ágba való véletlen leküldéstől.

Jegyzet

Ez a módosítás nem vezet be semmilyen viselkedésbeli változást. Azok a felhasználók, akik korábban "Szabályzatkényszerítés alóli mentesség" engedéllyel rendelkeztek, megkapják a Engedélyt mindkét új engedélyre, így felülbírálhatják a pull requestek befejezését, és közvetlenül módosításokat indíthatnak a szabályzatokkal rendelkező ágakra.

További információt a Ágengedélyek beállítása dokumentációjában talál.

Lekéréses kérelmek gyors leírása véglegesítési üzenetekkel

A leíró véglegesítési üzenetek írása hozzáadott értéket ad bármely Git-adattár előzményeihez. A minőségi véglegesítési üzenetek ösztönzése érdekében a több véglegesítéssel rendelkező új lekéréses kérelmekhez (PR) a közreműködőknek manuálisan kell megadniuk a címet.

A lekéréses kérelmek leírásai alapértelmezés szerint továbbra is üresek maradnak, de egy új funkció megkönnyíti a lekéréses kérelmek véglegesítési üzeneteinek beépítését a lekéréses kérelmek leírásába. A véglegesítési üzenetek hozzáadásához egyszerűen kattintson a Véglegesítési üzenetek hozzáadása gombra, hogy hozzáfűzze őket a PR leírásának szövegéhez.

Pull requestek létrehozása alapértelmezett csapat nélkül mint véleményező

Amikor először elindítottuk a lekéréses kérelem (PR) felületét, úgy gondoltuk, hogy érdemes minden PR-t hozzárendelni ahhoz a csapatkörnyezethez, amelyet a lekéréses kérelem létrehozásakor választott. Ez a viselkedés frusztrációs pont volt, mivel sokan nem vették észre a csapatkörnyezet és a PR-hozzárendelés közötti kapcsolatot.

Az új navigációs változások részeként lehetőséget vettünk, hogy módosítsuk ezt az alapértelmezett társítást a csapatokkal. Két módosítást fog látni:

1. Pr létrehozásakor a rendszer alapértelmezés szerint nem ad hozzá véleményezőket. A véleményezők listája rendelkezik egy olyan funkcióval, amellyel egyszerűbben vehet fel olyan személyeket és csoportokat, amelyeket a közelmúltban adtak hozzá a PRS-ekhez. A szükséges véleményezői szabályzat azokat a csapatokat is segítheti, amelyek biztosítani szeretnék, hogy adott véleményezők fel legyenek kérve a kódjuk áttekintésére.
2. A Pull Requests központ új testreszabható szekcióval rendelkezik. Ez a szakasz alapértelmezés szerint a "Hozzárendelve a csapatomhoz" PRS-eket jeleníti meg, amelyek a régi szakasznak megfelelő funkciókat biztosítanak. Ha azonban több csapathoz tartozik, ez a szakasz a csapatokhoz rendelt PRS-eket jeleníti meg. A szakasz testre is szabható – csak kattintson a szakaszfejléc melletti "Nézet testreszabása" műveletre.

Lekéréses kérelmek leírásának egységesítése sablonok használatával

A jó lekéréses kérelmek leírásának megírása nagyszerű módja annak, hogy a véleményezők tudják, mire számíthatnak a kód áttekintésekor. Emellett kiválóan segítenek nyomon követni azokat a dolgokat, amelyeket minden változáshoz el kell végezni, például a teszteléshez, az egységtesztek hozzáadásához és a dokumentáció frissítéséhez. Sokan kérték, hogy adjunk hozzá lekéréses kérelemsablonokat, hogy megkönnyítsük a csapatok számára a nagyszerű leírások írását, és most hozzáadtuk ezt a funkciót.

Az alapértelmezett PR-leírássablon támogatása mellett a csapatok több sablont is hozzáadhatnak, amelyeket a pr létrehozása lap egyik menüjében mutatunk be. Egyszerűen kattintson a Sablon hozzáadása gombra, és válasszon az adattár bármely sablonjából, és fűzze hozzá a pr-leíráshoz.

Az ágspecifikus sablonok is támogatottak, ha eltérő sablont szeretne alkalmazni egy speciális ágba vagy ágkönyvtárba történő "pull request" (PR) során. Például, ha az összes "hotfix/"-szal kezdődő ágra vonatkozóan szeretne egyedi sablont használni, hozzáadhat egy olyan sablont, amely az összes PR-re vonatkozik, amelyek ezekbe az ágakba kerülnek.

A lekéréses kérelmek sablonjai dokumentációjában további információt talál a sablonok létrehozásáról és használatáról.

Lekéréses kérelem célágának módosítása

A legtöbb csapat esetében szinte minden lekéréses kérés ugyanazt az ágat célozza, például main vagy develop. Abban az esetben azonban, ha egy másik ágat kell megcéloznia, könnyen elfelejtheti módosítani a célágat az alapértelmezettről. Az aktív lekéréses kérelmek célágának módosítására vonatkozó új funkcióval ez most egy egyszerű művelet. A lekéréses kérelem fejlécében kattintson a célág neve melletti ceruza ikonra.

A hibák kijavítása mellett a célágak módosításának funkciója megkönnyíti a lekéréses kérések újraküldését is, amikor a célágat egyesítették vagy törölték. Fontolja meg azt a forgatókönyvet, amelyben egy olyan szolgáltatáságat céloz meg a lekéréses kérelem, amely tartalmaz néhány olyan funkciót, amelytől a módosítások függenek. A függő módosításokat a funkcióág más módosításaitól elkülönítve szeretné áttekinteni, így kezdetben a features/new-featurecélozza meg. A véleményezők ezután csak az Ön módosításait láthatják, és meghagyhatják a megfelelő megjegyzéseket.

Most gondolja át, mi történne, ha a feature ágon is aktív PR lenne, és a módosításaid előtt egyesítették volna a main-val? Korábban el kellene vetnie a módosításait, és létre kellene hoznia egy új PR-t main-ra, vagy egyesítenie kellene az PR-t features/new-feature-be, majd létre kellene hoznia még egy PR-t a features/new-feature-ből a main-ra. Ezzel az új művelettel frissítheti a célágat, egyszerűen módosíthatja a lekéréses kérelem célágát features/new-feature-ről main-ra, megőrizve az összes környezetet és megjegyzést. A célág módosítása még egy új frissítést is létrehoz a pull kérésre, amely megkönnyíti a korábbi diffek áttekintését a célág módosítása után.

A bővítménykészítők lekérdezhetik az aktuális adattár környezetét

A verziókövetési bővítmény szerzője számára az egyik kihívást az jelenti, hogy lekérheti a felhasználó számára megjelenített adattár környezetét, például a nevet, az azonosítót és az URL-címet. Ennek érdekében hozzáadtuk a VersionControlRepositoryService szolgáltatást bővítmény-akadálymentes szolgáltatásként. Ezzel a bővítményszerző lekérdezheti az aktuális Git-adattár környezetével kapcsolatos információkat a webes felhasználói felületen. Jelenleg egy metódusa van: getCurrentGitRepository().

• Ha egy Git-adattár van kijelölve, a GitRepository objektumot a függvény az adattár alapadataival (név, azonosító és URL-cím) adja vissza.
• Ha ki van jelölve egy TFVC-adattár, vagy a szolgáltatás az Azure-adattárakon kívül érhető el, a rendszer null értéket ad vissza.

Íme egy mintakiterjesztés, amely ezt a szolgáltatást használja.

Csővezetékek

Buildfolyamatok kezelése az új Buildek lapon

Számos fejlesztést hajtunk végre, és a Builds oldal új verzióját vezetjük be. Ez az új verzió egyesíti az összes buildelési folyamat könyvtárát és az aktuális buildek listáját, így gyorsan navigálhat a projekt buildjei között az állapotuk megtekintéséhez. Emellett a kiválasztott folyamat tesztelemzésének előzetes verzióját is tartalmazza.

A buildelési és üzembe helyezési befejezési e-mailek hatékonyabb kezelése továbbfejlesztett formázással

A build és telepítési befejező e-maileket úgy frissítettük, hogy jobban szűrhetők legyenek az e-mail-szabályokkal. Most a tárgysor több releváns információt tartalmaz egy pillantással, a törzs további részleteket tartalmaz, és a stílusuk frissült a legújabb márkával.

Az új formátum elemei a következők:

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

Íme néhány példa:

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Kövesse az új egységes Azure Pipelines-terminológiát

A buildek és kiadások során különböző kifejezéseket használtunk korábban hasonló fogalmakhoz. Más esetekben a kifejezések jelentése homályos volt. A például az ügynökkészlet és az ügynöksor közötti különbségmegállapítása.

A terminológia egységesítve lett az Azure Pipelinesban a fogalmak tisztázása érdekében. Most a következő egységes kifejezéseket fogja látni:

Előző kifejezés	Egyesített kifejezés	Jelentés
Üzemeltetett ügynök	Microsoft által üzemeltetett ügynök	A Microsoft által felügyelt felhőalapú infrastruktúrán futó build-/kiadási ügynök.
Privát ügynök	Saját üzemeltetésű ügynök	Az Ön által biztosított és felügyelt gépen futó build- és kiadási ügynök.
Ügynökkészlet	Ügynökkészlet	Egy szervezeti szintű ügynökgép-készlet, amely buildeket vagy kiadásokat futtathat.
Ügynöki sorban állás	Ügynökkészlet	Az ügynökgépek projektszintű készlete, amely buildeket vagy kiadásokat futtathat. Egy szervezeti szintű ügynökkészlethez van társítva.
Felépítés definíció	Folyamatfolyam építése	Egy alkalmazás buildelési lépéseinek végpontok közötti halmaza.
Épít	Épít	Futó vagy futtatott buildelési folyamat egy példánya.
Fázis	Foglalkozás	Egy ügynökön egymás után vagy párhuzamosan futó feladatok sorozata. A buildelési vagy kiadási folyamat egy feladatot vagy több feladatból álló gráfot tartalmazhat.
Kiadás definíciója	Kiadási csővezeték	A különböző szakaszokban üzembe helyezendő alkalmazások teljes körű kiadási lépései.
Kiadás	Kiadás	Egy futtatás alatt álló vagy már futtatott verziókiadási folyamat egy példánya.
Környezet	Színpad	Logikai és független entitás, amely a kiadási folyamatból létrehozott kiadás üzembe helyezésének helyét jelöli.
Egyidejű feladat/csővezeték	Párhuzamos feladat	A párhuzamos feladat lehetővé teszi, hogy a szervezetben egyszerre csak egy buildelési vagy kiadási feladatot futtasson. Ha több párhuzamos feladat érhető el, egyszerre több buildelési és kiadási feladatot is futtathat.
Szolgáltatásvégpont	Szolgáltatáskapcsolat	A beállítások egy csoportja, például hitelesítő adatok, amelyeket külső szolgáltatásokhoz való csatlakozásra használnak a feladatok buildben vagy kiadásban való végrehajtásához.

További információt a Fogalmak dokumentációjában talál.

Kiadási folyamatok kezelése az új Kiadások lapon

A kiadás kezdőlapján új és teljesen újratervezett felhasználói felület érhető el. Gyakran használt kiadási folyamatok listáját találja a bal oldalon. A csővezetékeket is keresheti, és kedvencek közé teheti őket.

A mappák nézetre váltva mappákat hozhat létre a szervezet és a biztonság számára. A biztonság mappaszinten állítható be.

A kiadás előrehaladásának megjelenítése

Az új kiadás előrehaladási nézete élő frissítéseket biztosít az üzembe helyezés előrehaladásáról, és egy kattintással hozzáférést biztosít a további részletekhez. Az új nézet a kiadási folyamatot vizualizálja, így könnyebben megértheti, hogy mi történik, és a kiadás különböző szakaszaiban megfelelő részleteket és műveleteket jelenít meg.

Folyamatok, kiadási adatok és környezetek

A Pipeline nézet a kiadás összetevőit és azokat a környezeteket jeleníti meg, ahol üzembe helyezik őket. A Kiadási terület olyan kiadási részleteket tartalmaz, mint a kiadási eseményindító, az összetevők verziói és a címkék.

A környezetek modellezése segít megérteni az állapotukat, valamint a részletes előrehaladást. Bármikor elérheti a naplókat az állapothivatkozásra kattintva a környezetben.

Üzembe helyezés előtti és üzembe helyezés utáni

Ha az üzembe helyezés előtti vagy az üzembe helyezés utáni feltételek be lettek állítva egy környezethez, ezt a környezeten a jóváhagyások és kapuk jelenléte jelzi. A jóváhagyások és kapuk folyamata a környezet állapotában is megjelenik. A környezet jobb vagy bal oldalán található állapotikonra kattintva műveletet hajthat végre, vagy további részleteket tekinthet meg.

Véglegesítések és munkaelemek

Minden új kiadás esetében külön-külön láthatja az egyes környezetekhez tartozó véglegesítések és munkaelemek listáját a környezetre kattintva. Ha a lista hosszú, szűrőkkel keresse meg a keresett véglegesítést vagy munkaelemet.

Üzembe helyezési folyamat és naplók

A környezetek a folyamatban lévő telepítések élő frissítéseit jelenítik meg, beleértve azt is, hogy hány fázis és tevékenység van befejezve, valamint a futási időtartamot. A környezeti állapotra kattintva megnyílik a naplókat tartalmazó nézet, amely a jelenleg aktív állapotra összpontosít.

A naplókra kattintva szűrt nézetet adhat meg.

Az Azure DevOps Server 2019-re való frissítés hatása a következő feladatokra: Windows gépi fájlmásolás és PowerShell a célgépen.

A gépcsoportokat a Test Hub alatt elavultnak nyilvánították a TFS 2017 RTM-ben. Az Azure DevOps Server 2019-ben a Gépcsoportok szolgáltatás már nem érhető el. Ez hatással lesz a "Windows Machine File Copy" feladat 1.* és a "PowerShell a célgépeken" feladat 1. verziójának felhasználóira.*. Ahhoz, hogy a pipelinek továbbra is működjenek,

• Át kell váltania a "Windows Machine File Copy" feladat 2.* verziójára, és meg kell adnia a célgép teljes tartománynevét a gép neve helyett.
• Váltson a "PowerShell a célgépen" feladat 2.* vagy újabb verziójára, és adja meg a gép teljes tartománynevét vagy a gépnevet, majd a Windows Remote Management portokat (http/https). Például: targetMachine:5985 vagy targetMachine:5986

Teszteredmények és bővíthetőség

A tesztvégrehajtás eredményei is felszínre kerülnek az egyes környezetekben. A teszteredményekre kattintva megnyílik egy olyan nézet, amely a folyamathoz hozzájáruló egyéb bővítmények eredményeit is tartalmazza.

A meglévő bővítmények ebben az új nézetben működnek, valamint vannak új bővíthetőségi pontok, amelyek lehetővé teszik a bővítmények fejlesztését, hogy még több információt jelenítsen meg egy környezet számára. További információért tekintse meg a hozzájárulásokat és bővítményeket dokumentációt.

Buildek konfigurálása YAML használatával

YAML-alapú buildelési folyamatok érhetők el az Azure DevOps Serveren. Automatizálja a folyamatos integrációs folyamatot az adattárba bejelentkezett YAML-fájllal. A YAML-sémára vonatkozó teljes hivatkozás itt található.

A YAML-alapú buildelési folyamatok zökkenőmentesebb támogatása érdekében módosítottuk a létrehozott összes új erőforrás (például szolgáltatáskapcsolatok, változócsoportok, ügynökkészletek és biztonságos fájlok) alapértelmezett viselkedését, hogy az a projekt összes folyamatában használható legyen. Ha szigorúbban szeretné szabályozni az erőforrásokat, letilthatja az alapértelmezett engedélyezési modellt (lásd az alábbi ábrát). Ha így tesz, az erőforrás használatára jogosult személynek explicit módon mentenie kell a folyamatot a webszerkesztőben, miután hozzáadtak egy erőforrás-hivatkozást a YAML-fájlhoz.

Kapcsoljon össze kapcsolódó buildeket build-befejezési triggerekkel

A nagy termékek több olyan összetevőből állnak, amelyek egymástól függenek. Ezek az összetevők gyakran egymástól függetlenül vannak felépítve. Ha egy felsőbb rétegbeli összetevő (például egy tár) megváltozik, az alsóbb rétegbeli függőségeket újra kell felépíteni és újra kell értékelni. A Teams általában manuálisan kezeli ezeket a függőségeket.

Most már elindíthat egy buildet egy másik build sikeres befejezése után. A felsőbb rétegbeli buildek által létrehozott összetevők letölthetők és használhatók a későbbi buildben, és a következő változókból is lekérheti az adatokat: Build.TriggerBy.BuildId, Build.TriggerBy.DefinitionId, Build.TriggerBy.BuildDefinitionName. További információt a buildindítók dokumentációjában talál.

Ne feledje, hogy bizonyos esetekben egyetlen többfázisú építés is kielégítheti az igényeit. A build befejezésének eseményindítója azonban akkor hasznos, ha a követelmények különböző konfigurációs opciókat, lehetőségeket vagy egy másik csapatot foglalnak magukban a függő folyamat tulajdonosaként.

Frissítsd fel helyben az ügynököt

A Galériából telepített feladatok néha újabb verziójú pipeline ügynököt igényelnek. Ha az Azure DevOps Server csatlakozni tud az internethez, a rendszer automatikusan letölti az újabb verziókat. Ha nem, akkor manuálisan kell frissítenie az egyes ügynököket. A jelen kiadástól kezdve konfigurálhatja az Azure DevOps Servert, hogy az ügynökcsomagfájlokat ne az internetről, hanem a helyi lemezén keresse meg. Ez rugalmasságot és szabályozást biztosít az elérhető ügynökverziók felett anélkül, hogy az Azure DevOps Servert az interneten kellene elérhetővé tennie.

Új build állapot jelvény URL-címe

Az adattár kezdőlapjába ágyazott jelvények gyakori módja az adattár állapotának szemléltetésére. Bár eddig voltak build jelvények, akadt néhány probléma:

• Az URL-cím nem volt intuitív
• A jelvény nem egy ágra volt jellemző
• Nem volt mód arra, hogy a felhasználó a jelvényre kattintva a definíció legújabb buildje felé vigye a felhasználót

Most egy új API-t vezetünk be a problémák megoldására szolgáló buildjelvényekhez. Az új API lehetővé teszi a felhasználók számára, hogy ágonkénti állapotot tegyenek közzé, és a felhasználók a kiválasztott ág legújabb buildjének használatára is képesek. Az új állapotjelvény URL-címének Markdown formátumát az új Builds oldal Állapotjelvény menüeleménekkiválasztásával kaphatja meg.

A visszamenőleges kompatibilitás érdekében továbbra is tiszteletben tartjuk a régebbi buildjelvény URL-címeit.

Egyéni buildszámlálók hozzáadása a buildekhez

A buildszámlálók lehetővé teszik a buildek egyedi számának és címkézésének módját. Ezt korábban a $(rev:r) speciális változóval is elvégezhette. Most már definiálhat saját számlálóváltozókat a builddefinícióban, amelyek automatikusan növeksenek a build minden futtatásakor. Ezt a definíció változók lapján teheti meg. Ez az új funkció a következő módokon nyújt nagyobb teljesítményt:

• Megadhatja az egyéni számlálót, és beállíthatja annak kezdőértékét. A számlálót például 100-nál indíthatja el. A $(rev:r) mindig 0-nál kezdődik.
• A számlálók alaphelyzetbe állításához használhatja a saját egyéni logikáját. A $(rev:r) a buildszám generálásához van kötve, és automatikusan alaphelyzetbe áll, amikor új előtag van a buildszámban.
• Definíciónként több számlálót is definiálhat.
• A builden kívüli számláló értékét is le lehet kérdezni. Megszámolhatja például a legutóbbi visszaállítás óta futó buildek számát számláló használatával.

A buildszámlálókkal kapcsolatos további információkért tekintse meg a felhasználó által definiált változók dokumentációját.

Azure Policy-megfelelőség és biztonsági ellenőrzés a Pipeline-ekben

Szeretnénk biztosítani a szoftver stabilitását és biztonságát a fejlesztési folyamat korai szakaszában, miközben a fejlesztés, a biztonság és a műveletek egybeesnek. Ehhez hozzáadtuk Azure Policytámogatását.

Az Azure Policy segítségével kezelheti és megelőzheti az erőforrásokra vonatkozó szabályokat és hatásokat kikényszerítő szabályzatdefiníciókkal kapcsolatos informatikai problémákat. Az Azure Policy használatakor az erőforrások megfelelnek a vállalati szabványoknak és a szolgáltatásiszint-szerződéseknek.

Annak érdekében, hogy a kiadási folyamat részeként megfeleljenek a megfelelőségi és biztonsági irányelveknek, továbbfejlesztettük az Azure-erőforráscsoport üzembe helyezésének élményét. Most az Azure-erőforráscsoport üzembe helyezési feladatát meghiúsítjuk a szabályzattal kapcsolatos hibák miatt, ha az ARM-sablonok üzembe helyezése során bármilyen szabálysértés történik.

Emellett hozzáadtuk az Azure Policy Release definíciós sablonját is. Ez lehetővé teszi a felhasználók számára, hogy Azure-szabályzatokat hozzanak létre, és ezeket a szabályzatokat a kiadási definícióból származó erőforrásokhoz, előfizetésekhez vagy felügyeleti csoportokhoz rendelik.

Azure Policy-sablon

Építés Linux/ARM és Windows 32 bites platformokra

Az Azure Pipelines nyílt forráskódú, platformfüggetlen ügynök mindig is támogatott 64 bites (x64) Windows, macOS és Linux rendszeren. Ezzel a kiadással két új támogatott platformot vezetünk be: Linux/ARM és Windows/32 bites. Ezek az új platformok lehetővé teszik, hogy kevésbé gyakori, de nem kevésbé fontos platformokra, például a Raspberry Pi-ra, egy Linux/ARM-gépre építsünk.

Továbbfejlesztett élmények a Pipeline-ok tesztjeihez

Tesztek lap most már modern felhasználói élményt kínál, amely részletes, környezeten belüli tesztelési információkat biztosít a Folyamatvonalakról. Az új felület biztosítja a folyamatban lévő tesztnézetet, a teljesoldalas hibakeresési élményt, a kontextusbeli tesztelőzményeket, a megszakított tesztvégrehajtás jelentését, és a futtatási szint összegzését.

Folyamatban lévő tesztek végrehajtásának megtekintése

A tesztek, például az integrációs és a funkcionális tesztek hosszú ideig futhatnak, ezért fontos, hogy bármikor lehessen látni a tesztek végrehajtását. A In-Progress Tesztnézettel már nem kell megvárnia, amíg a teszt végrehajtása befejeződik, hogy megismerje a teszt eredményét. Az eredmények futás közben közel valós időben érhetők el, így gyorsabban végezhet műveleteket. Hibaelhárítást, hibajelentés készítését vagy a folyamat megszakítását végezheti el. A funkció jelenleg elérhető mind a build, mind a release pipeline-ban, a VS Test feladat használatával a Multi Agent fázisban, valamint a Teszteredmények publikálása feladat vagy a teszteredmények API-k használatával történő publikálása során. A jövőben azt tervezzük, hogy kiterjesztjük ezt a felületet a tesztvégrehajtáshoz egyetlen ügynök használatával.

Az alábbi nézet a In-Progress teszt összegzését jeleníti meg az új kiadás előrehaladási nézetben, a teljes tesztszámot és a tesztelési hibák számát egy adott időpontban.

A fenti In-Progress tesztösszegzésre kattintva megtekintheti a részletes tesztösszegzést, valamint a sikertelen vagy megszakított tesztadatokat a teszttervekközött. A teszt összegzése rendszeres időközönként frissül, és igény szerint frissítheti a részletes nézetet az új eredmények rendelkezésre állása alapján.

A tesztfuttatás hibakeresési részleteinek megtekintése teljes lapon

A hibaüzenetek és a veremnyomok hosszadalmasak, és elegendő képernyőterülettel kell rendelkezniük a részletek megtekintéséhez a hibakeresés során. A modern hibakeresési élmény érdekében mostantól teljes oldalnézetre bonthatja a teszt- vagy tesztfuttatási nézetet, miközben továbbra is elvégezheti a szükséges műveleteket olyan környezeti műveletekben, mint a hibalétrehozás vagy az aktuális teszteredményhez tartozó követelménytársítás.

Tesztelőzmények megtekintése a kontextusban

Korábban a csapatoknak a teszteredmények előzményeinek megtekintéséhez a Futtatások központba kellett menniük. Az új felülettel a tesztelőzményeket közvetlenül a kontextusba hozjuk Tesztcsomagok lapon a buildeléshez és a kiadáshoz. A tesztelőzmények adatai fokozatosan lesznek megadva a kiválasztott teszt jelenlegi builddefiníciójával vagy környezetével kezdve, amelyet a build és a kiadás egyéb ágai és környezetei követnek.

Megszakított tesztek megtekintése

A tesztelés végrehajtása több okból is megszakadhat, például a hibás tesztkód, a tesztelés alatt álló forrás és a környezeti problémák miatt. A megszakítás okától függetlenül fontos, hogy diagnosztizálja a viselkedést, és azonosítsa a kiváltó okot. Mostantól megtekintheti a megszakított teszteket és tesztfuttatásokat, valamint a befejezett futamokat a Teszttervek-ben. A funkció jelenleg mind a build, mind a release folyamathoz elérhető, a Multi Agent fázisban történő VS Test Task használattal, vagy a teszteredmények API-k használatával történő közzétételével. A jövőben azt tervezzük, hogy kiterjesztjük ezt a felületet a tesztvégrehajtáshoz egyetlen ügynök használatával.

A tesztkövethetőség és a kiadási környezetek támogatása a Tesztelőzményekben

Támogatjuk egy automatizált teszt előzményeinek megtekintését különböző kiadási környezetek szerint csoportosítva, amelyekben a teszt fut. Ha kiadási folyamatként vagy tesztkörnyezetként modellezi a kiadási környezeteket, és teszteket futtat az ilyen környezetekben, megtudhatja, hogy egy teszt a fejlesztői környezetben halad-e át, de az integrációs környezetben sikertelen. Kiderülhet, hogy az angol területi beállítás mellett sikeres, de sikertelen egy török területi beállítással rendelkező környezetben. Minden környezetben a legújabb teszteredmény állapotát fogja megtalálni, és ha a teszt nem sikerült az adott környezetben, akkor azt a kiadást is megtalálja, amely óta a teszt sikertelen volt.

Összegzett teszteredmények áttekintése

A teszt végrehajtása során a teszt több olyan tesztpéldányt is elindíthat, amelyek hozzájárulnak az általános eredményhez. Néhány példa: a hibák miatt újrafuttatott tesztek, más tesztek rendezett kombinációjából álló tesztek (pl. rendezett teszt), vagy a megadott bemeneti paraméteren alapuló különböző példányokkal rendelkező tesztek (adatvezérelt tesztek). Mivel ezek a tesztek összefüggnek, ezeket az egyes teszteredmények alapján származtatott általános eredménnyel együtt kell jelenteni. Ezzel a frissítéssel a teszteredmények továbbfejlesztett verzióját mutatjuk be hierarchiaként a kiadás Tesztek lapján. Lássunk egy példát.

Korábban bevezettük a sikertelen tesztek újrafuttatásának lehetőségét a VS Test feladatban. Azonban csak egy teszt utolsó kísérletéről számoltunk be, amely némileg korlátozta a funkció hasznosságát. Ezt a funkciót kiterjesztettük a tesztvégrehajtás minden példányának kísérletként való jelentésére. Emellett a Test Management API mostantól támogatja a hierarchikus teszteredmények közzétételét és lekérdezését. További információt a Teszteredmények API dokumentációjában talál.

Jegyzet

A tesztösszegző szakaszban szereplő metrikákat (pl. Összes teszt, Átadott stb.) a rendszer a hierarchia gyökérszintje alapján számítja ki a tesztek minden egyes iterációja helyett.

Tesztelemzések megtekintése Pipeline-okban

A tesztminőség időbeli nyomon követése és a tesztfedezet javítása kulcsfontosságú az kifogástalan folyamat fenntartásához. A tesztelemzési funkció közel valós idejű betekintést biztosít a buildelési és kiadási folyamatok tesztadataiba. Segít a folyamat hatékonyságának javításában az ismétlődő, nagy hatású minőségi problémák azonosításával.

A teszteredményeket különböző elemek szerint csoportosíthatja, azonosíthatja az ág vagy a tesztfájlok fő tesztjeit, vagy lehatolást végezhet egy adott tesztre a trendek megtekintéséhez és az olyan minőségi problémák megértéséhez, mint a pelyhesség.

Az alábbi előzetes verzióban megtekintheti buildek és kiadásitesztelemzéseit:

További információért tekintse meg a dokumentációt.

Definíciók egyszerűsítése több ügynök nélküli tevékenységgel

Az ügynök nélküli fázisban lévő feladatokat a kiszolgáló vezényli és hajtja végre. Az ügynök nélküli fázisok nem igényelnek ügynököt vagy célszámítógépet. Az ügynökfázisokkal ellentétben a definíciókban csak egy tevékenység adható hozzá minden ügynök nélküli fázishoz. Ez azt jelentette, hogy több fázist kellett hozzáadni, amikor több ügynök nélküli tevékenység volt a folyamatban, így a definíció terjedelmessé vált. Enyhítettük ezt a korlátozást, amely lehetővé teszi, hogy ügynök nélküli fázisokban több feladatot is fenntartson. Az ugyanabban a fázisban lévő tevékenységek egymás után futnak, ugyanúgy, mint az ügynökfázisok esetében. További információt a kiszolgáló fázisai dokumentációjában talál.

A telepítések fokozatos elérhetővé tétele és fázisokban történő végrehajtása kiadási kapuk használatával.

A kiadási kapuk használatával megadhatja az alkalmazás egészségének kritériumait, amelyeket teljesíteni kell ahhoz, hogy a kiadás a következő környezetbe előléptethető legyen. A rendszer rendszeres időközönként kiértékeli az összes megadott kaput az üzembe helyezés előtt vagy után, amíg azok mind sikeresek nem lesznek. Alapértelmezetten négyféle kapu érhető el, és további kapukat adhat hozzá a Marketplace-ről. Lehetősége lesz ellenőrizni, hogy az üzembe helyezéshez szükséges összes kritérium teljesült-e. További információt a kiadási kapuk dokumentációjában talál.

Tartsa az üzembe helyezéseket, amíg a kapuk következetesen sikeresek nem lesznek

A kiadási kapuk lehetővé teszik az állapotfeltételek automatikus kiértékelését, mielőtt a kiadást a következő környezetbe továbbítják. Alapértelmezés szerint a kiadás az összes kapura vonatkozó sikeres minta beérkezése után halad előre. Még akkor is, ha egy kapu kiszámíthatatlan, és a kapott sikeres minta maga is zaj, a folyamat tovább halad. Az ilyen típusú problémák elkerülése érdekében konfigurálhatja a kiadást úgy, hogy az állapot konzisztenciáját minimális ideig ellenőrizze, mielőtt továbbhalad. Futásidőben a verzió biztosítaná, hogy a kapuk sorozatos kiértékelése sikeres legyen, mielőtt engedélyezné a továbbfejlesztést. Az értékelés teljes időtartama az "újraértékelés közötti időtől" függ, és általában több, mint a konfigurált minimális időtartam. További információért tekintse meg a kapuk használatával történő kiadás üzembe helyezési vezérléséről szóló dokumentációt.

Automatikus üzembe helyezés új célokra egy üzembe helyezési csoportban

Korábban, amikor új célokat adtak hozzá egy üzembehelyezési csoporthoz, manuális üzembe helyezésre volt szükség annak biztosításához, hogy minden cél ugyanazzal a kiadással rendelkezzen. Most már konfigurálhatja úgy a környezetet, hogy automatikusan telepítse az utolsó sikeres kiadást az új célokra. További információért tekintse meg a üzembehelyezési csoportok dokumentációját.

A buildelés utáni feldolgozással címkézett buildek folyamatos üzembe helyezése

A folyamatos üzembehelyezési eseményindítók kiadást hoznak létre a build befejezésekor. Azonban néha a buildek utófeldolgozáson mennek keresztül, és csak a feldolgozás befejezése után szabad kiadni őket. Most már használhatja az utófeldolgozás során hozzárendelt buildcímkéket a kiadási folyamathoz tartozó szűrőkben.

Változó beállítása a kiadás időpontjában

A kiadási definíciókban most már kiválaszthatja a kiadás létrehozásakor beállítani kívánt változókat.

A változóhoz a kiadás létrehozásakor megadott érték csak az adott kiadáshoz lesz felhasználva. Ez a funkció segít elkerülni a tervezetben történő létrehozás több lépését, frissíti a változókat a tervezetben, és a változóval indítja a kiadást.

Környezeti változók átadása tevékenységeknek

A CI/CD-feladatszerzők beállíthatnak egy új tulajdonságot, showEnvironmentVariables, a task.json környezeti változók tevékenységeknek való átadásához. Ha így tesz, egy további vezérlőfelület jelenik meg a feladaton az összeállítás-szerkesztőben. Ez a PowerShell-, Cmdés Bash- feladatokhoz érhető el.

Ez két forgatókönyvet tesz lehetővé:

• Egy tevékenységhez szükség van egy környezeti változóra, amelynek a neve kis- és nagybetűkkel van megőrzve. A fenti példában például a tevékenységnek átadott környezeti változó a "foo" és nem a "FOO" lenne.
• Lehetővé teszi a titkos kódok értékeinek biztonságos átadását a szkripteknek. Ez előnyben részesíti a titkos kulcsok argumentumként való átadását a szkripteknek, mivel az ügynök operációs rendszere naplózhatja a folyamatok meghívását, beleértve az argumentumaikat is.

Változócsoportok klónozása

Hozzáadtuk a változócsoportok klónozásának támogatását. Amikor replikálni szeretne egy változócsoportot, és csak néhány változót szeretne frissíteni, nem kell végighaladnia a változók egyesével történő hozzáadásának fárasztó folyamatán. Mostantól gyorsan másolatot készíthet a változócsoportról, megfelelően frissítheti az értékeket, és új változócsoportként mentheti.

Jegyzet

A titkos változó értékeit a rendszer nem másolja át változócsoportok klónozásakor. Frissítenie kell a titkosított változókat, majd mentenie kell a klónozott változócsoportot.

Üzembe helyezés kiadási kapujának figyelmen kívül hagyása

A kiadási kapuk lehetővé teszik az állapotfeltételek automatikus kiértékelését, mielőtt a kiadást a következő környezetbe továbbítják. Alapértelmezés szerint a kiadási csővezeték csak akkor lép tovább, ha az összes kapu egyszerre egészséges. Bizonyos helyzetekben, például a kiadás felgyorsításakor vagy az állapot manuális ellenőrzése után előfordulhat, hogy a jóváhagyó figyelmen kívül szeretne hagyni egy kaput, és engedélyezi a kiadás folytatódását még akkor is, ha a kapu még nem értékelhető egészségesnek. A kiadás további információért a dokumentációt tartalmazza.

További tesztelés végrehajtása pull request kiadási trigger használatával

Egy pull request (PR) alapján indíthat egy buildet, és folyamatosan megkaphatja a gyors visszajelzést az egyesítés előtt. Most már konfigurálhat egy PR-eseményindítót egy kiadáshoz is. A kiadás állapota visszakerül a kódtárba, és közvetlenül látható a PR oldalon. Ez akkor hasznos, ha további funkcionális vagy manuális tesztelést szeretne végezni a PR-munkafolyamat részeként.

Azure-szolgáltatáskapcsolat létrehozása olyan szolgáltatásnevet használva, amely tanúsítvánnyal hitelesít

Mostantól definiálhat egy Azure-szolgáltatáskapcsolatot egy egyszerű szolgáltatásnévvel és egy hitelesítéshez szükséges tanúsítvánnyal. Az Azure szolgáltatáskapcsolat mostantól támogatja a tanúsítvánnyal hitelesítő szolgáltatásnevet, így mostantól üzembe helyezhet az Azure Stackre, amely AD FS-szel van konfigurálva. Ha szolgáltatásnevet szeretne létrehozni tanúsítványhitelesítéssel, olvassa el a hivatkozást, hogyan hozhat létre olyan szolgáltatásnevet, amely tanúsítvánnyal hitelesít.

Futtatás az Azure App Service-környezetekben támogatott csomagból

Az Azure App Service Deploy task (4.*) verziója mostantól támogatja RunFromPackage (korábbi nevén RunFromZip.

Az App Service számos különböző technikát támogat a fájlok üzembe helyezéséhez, például msdeploy (más néven WebDeploy), git, ARM stb. De ezek a technikák korlátozottak. A fájlok a wwwroot mappában (pontosabban d:\home\site\wwwroot) vannak üzembe helyezve, és a futtatókörnyezet ezután onnan futtatja a fájlokat.

A Csomagból futtatás esetén már nincs olyan üzembe helyezési lépés, amely az egyes fájlokat a wwwroot fájlba másolja. Ehelyett megad egy zip-fájlt, és a zip csatlakozik a wwwroothoz írásvédett fájlrendszerként. Ennek számos előnye van:

• Csökkenti a fájlmásolási zárolási problémák kockázatát.
• Éles alkalmazásban (újraindítással) üzembe helyezhető.
• Biztos lehet az alkalmazásban futó fájlokban.
• Javítja az Azure App Service alkalmazásainak teljesítményét.
• Csökkentheti a hidegindítási időket, különösen nagy npm-csomagfákkal rendelkező JavaScript-függvények esetében.

Linux-tárolók üzembe helyezése az App Server üzembe helyezési feladatával

Az Azure App Service Deploy feladat 4.* verziója mostantól támogatja egyedi tárolók üzembe helyezését az Azure Functions Linuxon .

Az Azure Functions linuxos üzemeltetési modellje Docker-tárolókon alapul, amelyek nagyobb rugalmasságot biztosítanak az alkalmazásspecifikus függőségek csomagolása és kihasználása terén. A Linuxon futó függvények két különböző módban üzemeltethetők:

1. beépített tárolórendszerkép: A függvényalkalmazás kódját hozza létre, és az Azure biztosítja és kezeli a tárolót (beépített rendszerkép mód), így nincs szükség a Dockerhez kapcsolódó konkrét ismeretekre. Ez az App Service Deploy feladat meglévő verziójában támogatott.
2. egyéni tárolórendszerkép: Bővítettük az App Service Üzembe helyezési feladatát, amely támogatja az egyéni tárolólemezképek üzembe helyezését az Azure Functionsben Linuxon. Ha a függvényeknek egy adott nyelvi verzióra van szükségük, vagy a beépített rendszerképben nem megadott függőséget vagy konfigurációt igényelnek, az Azure Pipelines használatával egyéni rendszerképet hozhat létre és helyezhet üzembe a Linuxon futó Azure-függvényben.

Az Xcode feladat támogatja az újonnan kiadott Xcode 10-et

Az Apple Xcode 10-es kiadásával egybeesve most már beállíthatja a projektjeit, hogy kifejezetten az Xcode 10-zel építsenek vagy teszteljenek. A folyamat az Xcode-verziók mátrixával párhuzamosan is futtathat feladatokat. Ezeket a buildeket a Microsoft által üzemeltetett macOS-ügynökkészlet használatával futtathatja. Az Xcode Azure Pipelinesban való használatához tekintse meg az útmutatót.

A Kubernetes üzembe helyezésének egyszerűsítése a Helm használatával

Helm egy olyan eszköz, amely leegyszerűsíti a Kubernetes-alkalmazások telepítését és kezelését. Emellett az elmúlt évben nagy népszerűségre és közösségi támogatásra tett szert. Az Release Helm-feladat mostantól elérhető a Helm-diagramok Azure Container Service- vagy bármely más Kubernetes-fürtön való csomagolásához és üzembe helyezéséhez.

A Helm-feladat hozzáadásával most már beállíthat egy Helm-alapú CI/CD-folyamatot a tárolók Kubernetes-fürtbe való továbbításához. További információért tekintse meg az Üzembe helyezés Kubernetes használatával az Azure Container Service dokumentációjában.

A Kiadásban használt Control Helm verzió

A Helm Tool Installer feladat az internetről vagy az eszközök gyorsítótárából szerzi be a Helm egy adott verzióját, és hozzáadja az ügynök PATH-éhez (üzemeltetett vagy privát). Ezzel a feladattal módosíthatja a Helm későbbi tevékenységekben használt verzióját, például a .NET Core cli feladatot. Ha ezt a feladatot hozzáadja a Helm Deploy feladathoz egy build- vagy kiadásdefinícióban, az biztosítja, hogy az alkalmazást a megfelelő Helm-verzióval csomagolja és telepítse. Ez a feladat segít kubectl eszköz opcionális telepítéséhez is, ami a Helm működésének előfeltétele.

Folyamatos üzembe helyezés az Azure Database for MySQL-ben

Mostantól folyamatosan üzembe helyezheti Azure Database for MySQL - az Azure MySQL-adatbázisát szolgáltatásként. Kezelje a MySQL-szkriptfájlokat a verziókövetésben, és folyamatosan telepítsen egy kiadási folyamat részeként egy natív feladattal a PowerShell-szkriptek helyett.

Továbbfejlesztett Windows távoli PowerShell-alapú feladatok használata

Új és továbbfejlesztett Windows távoli PowerShell-alapú feladatok érhetők el. Ezek a fejlesztések számos teljesítményjavítást tartalmaznak, és támogatják az élő naplókat és a konzol kimeneti parancsait, például a Write-Host és a Write-Output parancsokat.

PowerShell a célfeladaton (verzió: 3.*): Hozzáadhat beágyazott szkriptet, módosíthatja a PSSession beállításait, szabályozhatja az "ErrorActionPreference" parancsot, és normál hiba esetén meghiúsulhat.

Azure-fájlmásolási feladat (verzió: 2.*): A legújabb AzCopyval (v7.1.0) kerül kiadásra, amely egy GitHub-problémátorvosol.

GitHub Enterprise-hez vagy külső Git-objektumokhoz tartozó ágak szűrése

A GitHub Enterprise-ból vagy a külső Git-adattárakból való kiadáskor most már konfigurálhatja a kibocsátandó ágakat. Előfordulhat például, hogy csak egy adott ágból származó verziókat szeretne üzembe helyezni éles környezetbe.

Go nyelven írt alkalmazások létrehozása

A Go Tool Installer feladatával menet közben telepítheti a Go Tool egy vagy több verzióját. Ez a feladat beszerzi a projekt által igényelt Go-eszköz egy adott verzióját, és hozzáadja a buildügynök PATH-fájljához. Ha a célzott Go Tool-verzió már telepítve van az ügynökön, ez a feladat kihagyja a letöltési és telepítési folyamatot.

A Go feladat segít letölteni a függőségeket, létrehozni vagy tesztelni az alkalmazást. Ezzel a feladatsal egy tetszőleges egyéni Go-parancsot is futtathat.

Beágyazott vagy fájlalapú Python-szkriptek futtatása a folyamatban

Egy új Python-szkript feladat leegyszerűsíti a Python-szkriptek futtatását a feladatfolyamatban. A feladat egy szkriptet futtat egy Python-fájlból (.py) az adattárban, vagy manuálisan beírhat egy szkriptet a feladat beállításaiba a folyamat részeként történő mentéshez. A feladat a Python verzióját fogja használni az elérési úton, vagy megadhat egy abszolút elérési utat a használni kívánt Python-értelmezőhöz.

Továbbfejlesztett Xcode buildelési és tesztelési kimenet használata xcprettyből

xcpretty javítja az xcodebuild kimenet olvashatóságát, és JUnit formátumban hoz létre teszteredményeket. Az Xcode építési feladata mostantól automatikusan az xcpretty-t használja, amikor az elérhető az ügynök gépen, hiszen a hostolt macOS-ügynökökön elérhető. Bár az xcpretty kimenete eltérő és kevésbé részletes, mint az xcodebuild kimenet, minden buildhez elérhetővé tesszük a teljes xcodebuild naplókat.

Tesztcsomagok

A Test Runner (Azure Test Plans) ügyfél manuális teszteket futtat asztali alkalmazásokhoz

Most már használhatja a Test Runner (Azure Test Plans) ügyfelet az asztali alkalmazások manuális tesztjeinek futtatásához. Ez segít a Microsoft Test Managerről az Azure Test Plansre való áttérésben. Tekintse meg útmutatónkat, itt. A Tesztfuttató ügyfél használatával futtathatja a manuális teszteket, és rögzítheti az egyes tesztlépések teszteredményeit. Emellett adatgyűjtési képességekkel is rendelkezik, például képernyőképekkel, képműveleti naplóval és hangvideó-rögzítéssel. Ha problémát tapasztal a tesztelés során, a Tesztfuttató használatával hozzon létre egy hibát, amely automatikusan tartalmazza a hiba tesztelési lépéseit, képernyőképeit és megjegyzéseit.

A Tesztfuttató (Azure Test Plans) használatához a futó egyszeri letöltése és telepítése szükséges. Válassza Futtatás asztali alkalmazáshoz az alább látható módon.

Tárgyak

Felsőbb rétegbeli források

Az Azure DevOps Server 2019 jelentős frissítéseket biztosít az Azure Artifacts-hírcsatornákon elérhető felsőbb rétegbeli forrásokhoz:

• A korábbi TFS-kiadásokban létrehozott meglévő hírcsatornákhoz nuget.org felsőbb rétegbeli forrásokat is hozzáadhat. További információért keresse meg a hírcsatorna csomagja feletti szalagcímet, beleértve a frissítés előtt figyelembe vehető viselkedésváltozásokat is.
• Más Azure DevOps Server-hírcsatornákat is hozzáadhat felsőbb rétegbeli forrásként a hírcsatornához, ami azt jelenti, hogy ezekből a hírcsatornákból nuGet- és npm-csomagokat használhat a hírcsatornán keresztül.

Új szerepkört is bevezettünk az Azure Artifactsben: "Közreműködő". A közreműködők menthetik a csomagokat egy felsőbb rétegbeli forrásból, de nem tehetnek közzé csomagcsomagokat közvetlenül a hírcsatornában (például nuget publish használatával). Ez lehetővé teszi a csomagok közzétételének korlátozását egy megbízható felhasználó vagy a buildelési rendszer számára, miközben lehetővé teszi a mérnökök számára, hogy új csomagokat használjanak a felsőbb rétegbeli forrásokból.

Csomagok követése

Még egyszerűbbé tettük az értesítések beállítását egy új Követés gombbal közvetlenül minden csomagon. A Follow gomb a kiadási nézetekkel is kompatibilis. Ha követ egy csomagot, miközben egy nézetben tekinti meg, csak az adott nézetre előléptetett új verziók frissítéseit kapja meg.

A hírcsatorna beállításainak módosítása manuális mentés nélkül

A hírcsatorna-beállítások lapon található interakciók közül néhány javult. Most a rendszer azonnal menti a módosításokat, például egy upstream kapcsolat vagy egy engedély hozzáadását. Ez azt jelenti, hogy a beállítások kimutatásai közötti váltáskor nem kell aggódnia a módosítások elvesztésétől.

Egyszerűsítse a hitelesítést a NuGet új platformfüggetlen hitelesítőadat-szolgáltatójának használatával

A hitelesített NuGet-hírcsatornákkal való interakció sokkal jobb lett. Az új .NET Core-alapú Azure Artifacts hitelesítőadat-szolgáltató az msbuild, dotnet és nuget (.exe) használatával működik Windows, macOS és Linux rendszeren. Amikor egy Azure Artifacts-hírcsatornából szeretne csomagokat használni, a hitelesítőadat-szolgáltató automatikusan beszerez és tárol egy jogkivonatot a használt NuGet-ügyfél nevében. Többé nem kell manuálisan tárolnia és kezelnie egy jogkivonatot egy konfigurációs fájlban.

Az új szolgáltató használatához menjen a GitHub oldalra, és kövesse a klienséhez és a platformjához tartozó utasításokat.

Szimbólumok tömörítése fájlmegosztásban való közzétételkor

Frissítettük a Index & Szimbólumok közzététele feladatot, hogy támogassa a szimbólumok tömörítését, amikor azok fájlmegosztásra kerülnek.

Wiki

Markdown-fájlok közzététele Git-adattárból wikiként

A fejlesztők dokumentációt hoznak létre az "API-k", az "SDK-k" és a kódtárakban található "kódokat magyarázó súgódokumentumok" számára. Az olvasóknak ezután át kell szitálnia a kódot, hogy megtalálják a megfelelő dokumentációt. Most egyszerűen közzéteheti a Markdown-fájlokat a kódtárakból, és tárolhatja őket a Wikiben.

A Wikiben először kattintson a Kód közzététele wikikéntlehetőségre. Ezután megadhat egy mappát egy Git-adattárban, amelyet elő kell léptetni.

Ha a Közzétételelemre kattint, a kijelölt mappa alatt lévő összes Markdown-fájl wikiként lesz közzétéve. Ezzel az ág vezetőjét is leképozza a wikire, így a Git-adattárban végzett módosítások azonnal megjelennek.

További információt a termékdokumentáció blogbejegyzésében talál.

Hivatkozás egy lapon belüli címsorokra

Most a wikilap bármely szakaszfejléce melletti hivatkozás ikonra kattintva közvetlenül az adott szakaszra hozhat létre URL-címet. Ezután másolhatja az URL-címet, és megoszthatja a csapattagokkal, hogy közvetlenül az adott szakaszhoz csatolja őket.

Fájlok és képek csatolása mappákba

A wikilapok offline szerkesztése közben egyszerűbb lehet fájlmellékleteket és képeket hozzáadni ugyanabban a könyvtárban, mint a wikilap. Most hozzáadhat egy mellékletet vagy egy képet a wiki bármely mappájába, és csatolhatja a laphoz.

Videó beágyazása wikibe

Mostantól beágyazhat videókat egy wikilapra olyan online szolgáltatásokból, mint a Microsoft Stream és a YouTube. A beágyazott videó URL-címét a következő szintaxissal adhatja hozzá:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Wiki átnevezése

Most átnevezheti a wikit a wiki felhasználói felületén és REST API-k használatával. A További menüben kattintson a Wiki átnevezése elemre, hogy emlékezetes nevet adjon a wikinek.

Lap megnyitása az új lapon

Most kattintson a jobb gombbal egy wikilapra, és nyissa meg az új lapon, vagy egyszerűen nyomja le a CTRL + balra kattintva egy wikilapra, hogy megnyissa egy új lapon.

Speciális karakterek megőrzése a wikilap címeiben

Mostantól speciális karaktereket tartalmazó wikilapokat is létrehozhat, például : < > * ? | -. Most már olyan címekkel rendelkező lapok, mint a "GYIK?" vagy "Beállítási útmutató" is létrehozható a Wikiben. A következő karakterek az UTF-8 kódolású sztringekre lesznek lefordítva:

Karakter	Kódolt sztring
:	%3A
<	%3C
>	%3E
*	%2A
?	%3F
|	%7C
-	%2D

Hibás hivatkozások megtekintése

A wikiben a nem megfelelően csatolt hivatkozások külön piros színnel és hibás hivatkozás ikonnal jelennek meg, így vizuálisan látható lesz a wikilap összes hibás hivatkozása.

Hibás hivatkozások javítása lapok áthelyezésekor

A hibás oldalhivatkozások az egyik leggyakoribb oka a rossz oldalminőségnek minden dokumentációs megoldásban. Korábban a Wiki-ben, amikor áthelyezett egy lapot a hierarchiában, vagy átnevezett egy lapot, az megszakíthatta volna a más lapokról és munkaelemekről érkező hivatkozásokat. Most ellenőrizheti és kijavíthatja a hivatkozásokat, mielőtt megtörnének.

Fontos

Ne felejtse el használni a []() markdown szintaxist a lapok hivatkozásaihoz, valamint a wikilap hivatkozástípusát a munkaelemekben, hogy Wiki megkereshesse és kijavíthassa ezeket a potenciálisan hibás hivatkozásokat. A funkció nem veszi fel a munkaelemek egyszerű szöveges URL-címeit és hivatkozásait.

Amikor átnevez vagy áthelyez egy lapot, a rendszer kérni fogja, hogy ellenőrizze az érintett abszolút vagy relatív hivatkozásokat.

Ezután megjelenik az laphivatkozások listája, és a művelet végrehajtása előtt érintett munkaelemeket.

Tartalomjegyzék létrehozása wikilapokhoz

Néha a wikilapok hosszúak lehetnek, és a tartalom több címsorba van rendezve. Mostantól bármely olyan laphoz hozzáadhat tartalomjegyzéket, amely legalább egy címsort tartalmaz a [[_TOC_]] szintaxis használatával.

A tartalomjegyzéket úgy is beszúrhatja, hogy a lap szerkesztésekor a megfelelő gombra kattint a formátum panelen.

A markdown Azure DevOpsban való használatával kapcsolatos további információkért tekintse meg a markdown-útmutatót dokumentációjában.

Surface-metaadatok wikilapokhoz és kódelőnézethez YAML-címkék használatával

A metaadatok dokumentációhoz való hozzáadása segíthet az olvasóknak és a keresési indexeknek a tartalom felvételében és felszínre hozásában. Ebben a frissítésben a fájl elején yaML-blokkot tartalmazó fájlok egy fejből és egy sorból álló metaadattáblává alakulnak. A YAML-blokknak érvényes YAML-halmaz formájában kell lennie három szaggatott vonal között. Támogatja az összes alapszintű adattípust, listát és objektumot értékként. A szintaxist a Wiki és a kódfájl előnézet támogatja.

PÉLDA YAML-címkékre:

---
tag: post
title: Hello world
---

YAML-címkék példa listával:

---
tags:
- post
- code
- web
title: Hello world
---

Kód közzététele wikiként közreműködői engedélyekkel

Korábban csak azok a felhasználók tehették közzé a kódot wikiként, akik Tárház létrehozása engedéllyel rendelkeztek egy git-adattárban. Ez az adattárak rendszergazdáira vagy létrehozóira szűk keresztmetszetet jelentett a Git-adattárakban wikiként felhasznált Markdown-fájlok közzétételére irányuló kérések esetében. Mostantól wikiként közzéteheti a kódot, ha csak Közreműködői engedéllyel rendelkezik a kódtárban.

Jelentési

Az Elemzési piactér jelentéskészítési bővítménye már elérhető

A Analytics Marketplace-bővítmény már elérhető az Azure DevOps Serverhez. Az Elemzés az Azure DevOps és az Azure DevOps Server jelentéseinek jövője. Az Analytics bővítmény telepítése speciális widgeteket, Power BI-integrációtés OData-hozzáféréstbiztosít.

További információért tekintse meg a Mi az az elemzés? és a Jelentési ütemterv. Az elemzés nyilvános előzetes verzióban érhető el. Jelenleg tartalmaz adatokat a táblákról és az automatizált teszteredményekről, amik csővezetéken keresztül érhetők el. Lásd: Analytics Service-elérhető adatok.

Buildelőzmények vizsgálata új buildelési irányítópulton keresztül

Új és továbbfejlesztett buildelőzmény-widgetünk van, amelyet hozzáadhat a vezérlőpultokhoz. Ezzel a widgettel mostantól megtekintheti egy adott ág buildjeinek előzményeit az irányítópulton, és konfigurálhatja egy nyilvános projektben névtelen látogatók számára.

Fontos

Ha szeretne betekintést nyerni az XAML-buildekre, használja tovább a régebbi widgetet, és olvassa el a cikket az XAML-buildekről való migrálásról az új buildekre. Ellenkező esetben javasoljuk, hogy lépjen az újabb widgetre.

---

Visszajelzés

Örömmel hallanánk tőled! Jelenthet egy problémát, vagy ötleteket adhat meg, és nyomon követheti azt fejlesztői közösség, és tanácsokat kaphat Stack Overflow.

---

lap tetején