Share via

Új Analytics-jelentések és Azure Boards-alkalmazás a Slackhez – Sprint 155 Update

  • Cikk

Az Azure DevOps 155-ös futamú frissítésében új Azure Boards-jelentéseket vezetünk be, hogy könnyebben nyomon követhesse a csapat fontos metrikáit. Az új jelentéseket a Boards, a Backlog és a Sprint központok Elemzés apján találja. Ezek a jelentések teljes mértékben interaktívak, és saját igényei szerint módosíthatja őket.

Örömmel jelentjük be továbbá az új Azure Boards-alkalmazást a Slackhez. Az alkalmazással monitorozhatja a munkaelemek tevékenységét, és munkaelemeket hozhat létre a Slack-csatornából.

További információért tekintse meg az alábbi Szolgáltatások listát.

Az Azure DevOps újdonságai

Funkciók

Általános:

Azure Boards:

Azure Repos:

Azure Artifacts:

Azure Pipelines:

Többfázisú YAML-folyamatok

   Üzemeltetett virtuális gépek

Kubernetes

Test

   Azure-használat

Integrations

General

GitHub-közreműködők meghívása az Azure DevOpsba

Mostantól meghívhat közreműködőket a GitHubról az Azure DevOpsba, amikor bejelentkezik a GitHub-identitásával. Kereshet és meghívhat más GitHub-felhasználókat a Project kezdőlapjáról és a Szervezet beállításainak Felhasználók lapjáról.

Invite GitHub collaborators into Azure DevOps.

Ezt a képességet a meglévő szervezetek számára a Szervezeti beállítások Házirendek területén megadott beállításon keresztül kell engedélyezni. A GitHub-identitás által létrehozott szervezetek esetében azonban alapértelmezés szerint be van kapcsolva.

Enable for existing organizations.

Megjegyzés:

Ez a funkció nem GitHub-felhasználók számára nem érhető el, még akkor sem, ha a szabályzat be van kapcsolva.

A csapattagok meghívásával kapcsolatos további információkért tekintse meg a dokumentációt itt. Ha problémákat tapasztal az Azure DevOpshoz a GitHub használatával való csatlakozáskor, tekintse meg a GitHub-felhasználók hitelesítésének hibaelhárítását és a GitHub-felhasználók gyakori kérdéseinek meghívását.

Azure Boards

Három új Azure Boards-jelentés érhető el, melyekkel a csapat állapotáról szerezhet információkat

Nem tudja kijavítani, amit nem lát. Ezért érdemes figyelni a munkafolyamatok állapotát és állapotát. Ezekkel a jelentésekkel egyszerűbbé tesszük a fontos metrikák nyomon követését minimális erőfeszítéssel az Azure Boardsban.

A három új interaktív jelentés: Burndown, Göngyölt folyamatábra (CFD) és Velocity. A jelentéseket az új elemzési lapon tekintheti meg.

Az olyan metrikák, mint a sprint burndown, a munkafolyamat és a csapatsebesség, betekintést nyújtanak a csapat előrehaladásába, és segítenek megválaszolni az olyan kérdéseket, mint például:

  • Mennyi munka maradt ebben a futamban? Jó úton haladunk a befejezéshez?
  • A fejlesztési folyamat melyik lépése tart a leghosszabb ideig? Tehetünk valamit?
  • A korábbi iterációk alapján mennyi munkát kell terveznünk a következő futamra?

Megjegyzés:

A fejlécekben korábban látható diagramokat lecseréltük ezekre a továbbfejlesztett jelentésekre.

Az új jelentések teljesen interaktívak, és lehetővé teszik az igényeinek megfelelő beállításukat. Az új jelentéseket az Egyes központok Elemzés lapján találja.

  • A leégés diagram a Sprints hub alatt található.

    Analytics tab in Sprint hub.

  • A CFD- és sebességjelentések a táblák és hátralékok alatti Elemzés lapról érhetők el a megfelelő kártyára kattintva.

    CFD and velocity reports in boards.

Az új jelentésekben több irányítás és információ áll rendelkezésre a csapatról. Íme néhány példa:

  • A Sprint Burndown és a Velocity-jelentések beállíthatók úgy, hogy a munkaelemek számát vagy a hátralévő munka összegét használják.
  • A futamok leégésének időkeretét a projektdátumok befolyásolása nélkül módosíthatja. Így ha a csapat általában az egyes futamtervezések első napját tölti, akkor most már megfelelhet a diagramnak ennek megfelelően.
  • A Burndown-diagramon most már van egy vízjel, amelyen a hétvégék láthatók.
  • A CFD-jelentés lehetővé teszi, hogy eltávolítsa a táblaoszlopokat, például a Tervezést, hogy jobban összpontosítson arra a folyamatra, amelyen a csapatok irányítják az irányítást.

Íme egy példa a CFD-jelentésre, amely a Stories-hátralék utolsó 30 napjának folyamatát mutatja be.

Example of the CFD report.

A Sebesség diagram mostantól nyomon követhető az összes hátralékszinten. Mostantól hozzáadhatja például a Funkciókat és az Eposzokat is, míg az előző diagram előtt csak a Követelmények támogatottak. Íme egy példa a szolgáltatások hátralékának utolsó 6 iterációjára vonatkozó sebességjelentésre.

Example of a velocity report.

Azure Boards-alkalmazás a Slackhez

Örömmel jelentjük be az új Azure Boards-alkalmazást a Slackhez. Ezzel az alkalmazással figyelheti a munkaelemek tevékenységeit, és létrehozhat munkaelemeket a Slack-csatornából.

Az alkalmazás lehetővé teszi az esemény-előfizetések beállítását és kezelését, beleértve a létrehozást és a munkaelem-frissítéseket, valamint értesítéseket kaphat ezekről az eseményekről a Slack-csatornában. A Slack-csatornában lévő beszélgetések munkaelemek létrehozására használhatók. Személyes értesítéseket is kap, ha a munkaelemek önhöz vannak rendelve. Emellett a munkaelem URL-címeinek előnézetei lehetővé teszik a megbeszélések kezdeményezését.

Azure Boards app for Slack.

Az Azure Boards alkalmazás telepítéséhez kattintson ide.

Feladattáblaoszlopok testreszabása

Örömmel jelentjük be, hogy hozzáadtunk egy lehetőséget, amellyel testre szabhatja a tálcán lévő oszlopokat. Mostantól hozzáadhatja, eltávolíthatja, átnevezheti és átrendezheti az oszlopokat.

A tálcán lévő oszlopok konfigurálásához válassza az Oszlopbeállítások lehetőséget.

Customizing columns on the taskboard.

Ezt a funkciót a fejlesztői közösség javaslata alapján rangsorolásra került.

Befejezett gyermekelemek mutatása/elrejtése a hátralékokban

A hátralék finomításakor sokszor csak a nem befejezett elemeket szeretné látni. Most már megjelenítheti vagy elrejtheti a befejezett gyermekelemeket a hátralékban.

Ha a kapcsoló be van kapcsolva, az összes gyermekelem kész állapotban jelenik meg. Ha a kapcsoló ki van kapcsolva, a befejezett állapotban lévő összes gyermekelem el lesz rejtve a hátralék elől.

Show or hide child items on the backlog.

Mostantól egyszerűen elérheti a legutóbb meglátogatott táblákat, hátralékokat, lekérdezéseket és futamokat a keresőmezőből a keresőmező aktiválásával az Azure Boardsban.

Activate the instant search box.

Emellett megkeresheti a táblákat, a hátralékokat, a lekérdezéseket és a futamokat a projektben, ha beírja a tábla nevét a keresőmezőbe. Most, a táblák, hogy a legfontosabb önnek csak egy kattintásra.

Search for a board name.

A legutóbbi címkék megjelenítése munkaelem címkézésekor

Munkaelem címkézésekor az automatikus kiegészítési lehetőség mostantól legfeljebb öt legutóbb használt címkét jelenít meg. Ez megkönnyíti a megfelelő információk hozzáadását a munkaelemekhez.

Most recent used tags displayed when tagging a work item.

Azure Repos

Továbbfejlesztett kódkereső-szűrési lehetőségek

Korábban a kódkeresés 39 kódkeresési szűrőt támogatott, például megjegyzést: és def:. Az adatok azt sugallták, hogy sok szűrőt nem használnak, ezért eltávolítunk néhány szűrőt, és egyesítünk másokat. Ezzel a frissítéssel a szűrők számát 19-re csökkentettük. Ez segít a kódkeresési lekérdezések hatékonyabbá tételében és a felület zsúfoltságának csökkentésében.

Code search filter options.

Például a func: metódusra van leképezve:, azaz ha a func:Account Rendszergazda függvényre keres, az eredmények a metódus:Account Rendszergazda lesznek leképezve. Ehhez hasonlóan a makródef: és a macroref: a makróra van megfeleltetve: Másfelől az olyan szűrők, mint az unió: és a szervezet: a használat hiánya miatt elavultak.

Kódlefedési metrikák és elágaztatási szabályzatok lekéréses kérelmekhez

Mostantól a lekéréses kérelem (PR) nézetben láthatja a módosítások kódlefedettségi mérőszámait. Ez biztosítja, hogy automatikus tesztek segítségével megfelelően tesztelje a módosításokat. A lefedettség állapota megjegyzésként jelenik meg a lekéréses kérelem áttekintésében. A fájldiff nézetben módosított kódsorok lefedettségi adatainak részleteit megtekintheti.

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

Emellett az adattártulajdonosok beállíthatják a kódlefedési szabályzatokat, és megakadályozhatják, hogy a nagy, nem tesztelt módosítások egy ágba egyesülnek. A kívánt lefedettségi küszöbértékek definiálhatók az azurepipelines-coverage.yml adattár gyökerénél bejelentkezett beállításfájlban, és a lefedettségi szabályzat definiálható a meglévő ágszabályzattal az Azure-adattárak további szolgáltatásokhoz való funkciójához.

Define coverage thresholds.

Megjegyzésekről szóló értesítések szűrése lekéréses kérelmekhez

A lekéréses kérelmek megjegyzései gyakran nagy zajt okozhatnak az értesítések miatt. Hozzáadtunk egy egyéni előfizetést, amellyel szűrheti, hogy mely megjegyzésértesítésekre iratkozhat fel a megjegyzés kora, a megjegyzéskezelő, a törölt megjegyzés, az említett felhasználók, a lekéréses kérelmek szerzője, a célág és a téma résztvevői szerint. Ezeket az értesítési előfizetéseket úgy hozhatja létre, hogy a jobb felső sarokban lévő felhasználói ikonra kattint, és a Felhasználói beállításokra navigál.

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

Szolgáltatáshookok lekéréses kérelmek megjegyzéseihez

Mostantól létrehozhat szolgáltatási horgokat a megjegyzésekhez egy lekéréses kérelemben az adattár és a célág alapján.

Service hooks for pull request comments.

Azure Artifacts

Csomagok nyilvános megosztása nyilvános csatornákon (előzetes verzió)

Most már létrehozhatja és tárolhatja a csomagokat nyilvános hírcsatornákban. A nyilvános hírcsatornákban tárolt csomagok hitelesítés nélkül érhetők el az interneten, függetlenül attól, hogy az Ön szervezetében vannak-e, vagy akár bejelentkeztek egy Azure DevOps-szervezetbe. További információ a nyilvános hírcsatornákról a hírcsatornák dokumentációjában, vagy ugorjon közvetlenül a csomagok nyilvános megosztására vonatkozó oktatóanyagunkba.

Share your packages with public feeds.

Azure Pipelines

kustomize és kompose mint létrehozási lehetőségek a KubernetesManifest-feladatban

A kustomize (a Kubernetes sig-cli része) lehetővé teszi a nyers, sablonmentes YAML-fájlok több célra történő testreszabását, és érintetlenül hagyja az eredeti YAML-fájlokat. A KubernetesManifest-feladat bake művelete alatt egy kustomize-beállítás lett hozzáadva, így a kustomization.yaml fájlokat tartalmazó összes mappa használható a KubernetesManifest-feladat üzembe helyezési műveletében használt jegyzékfájlok létrehozásához.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose átalakítja a Docker Compose-fájlokat Kubernetes-erőforrássá.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Fürtadminisztrátor hitelesítő adatainak támogatása a HelmDeploy-feladatban

Korábban a HelmDeploy-feladat a fürt felhasználói hitelesítő adatait használta az üzemelő példányokhoz. Ez interaktív bejelentkezési kéréseket és sikertelen folyamatokat eredményezett egy Azure Active Directory-alapú RBAC-kompatibilis fürthöz. A probléma megoldásához hozzáadtunk egy jelölőnégyzetet, amely lehetővé teszi a fürt rendszergazdai hitelesítő adatainak használatát a fürt felhasználói hitelesítő adatai helyett.

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

Folyamatváltozók kezelése YAML-szerkesztőben

Frissítettük a folyamatváltozók kezelésének élményét a YAML-szerkesztőben. A yaML-folyamatok változóinak hozzáadásához vagy frissítéséhez már nem kell a klasszikus szerkesztőbe lépnie.

Manage pipeline variables in YAML editor.

Új előre definiált változók YAML-folyamatokban

A változók segítségével kényelmesen lekérheti a kulcsbiteket a folyamat különböző részeibe. Ezzel a frissítéssel hozzáadtunk néhány előre definiált változót egy üzembehelyezési feladathoz. Ezeket a változókat a rendszer automatikusan beállítja, és az adott üzembehelyezési feladatra terjed ki, és írásvédett.

  • Environment.Id – A környezet azonosítója.
  • Environment.Name – Az üzembe helyezési feladat által megcélzott környezet neve.
  • Environment.ResourceId – Az üzembe helyezési feladat által megcélzott környezetben lévő erőforrás azonosítója.
  • Environment.ResourceName – Az üzembe helyezési feladat által megcélzott környezet erőforrásának neve.

Jelenleg a munkaelemeket automatikusan összekapcsolhatja a klasszikus buildekkel. Ez azonban a YAML-folyamatoknál nem volt lehetséges. Ezzel a frissítéssel megoldottuk ezt a hiányosságot. Ha sikeresen futtat egy folyamatot egy adott ágból származó kód használatával, az Azure Pipelines automatikusan társítja a futtatást az összes munkaelemhez (amelyek a kódban szereplő véglegesítéseken keresztül következtetnek). A munkaelem megnyitásakor láthatja azokat a futtatásokat, amelyekben az adott munkaelem kódja készült. Ennek konfigurálásához használja a folyamat beállítások panelét.

Fázis törlése többfázisú YAML-folyamat futtatásánál

Többfázisú YAML-folyamat futtatásakor most már megszakíthatja egy szakasz végrehajtását, amíg az folyamatban van. Ez akkor hasznos, ha tudja, hogy a szakasz sikertelen lesz, vagy ha van egy másik futtatás, amelyet el szeretne indítani. Ez a funkció előfeltétele annak is, hogy a jövőben támogatni tudjuk a sikertelen fázis újrapróbálkozását.

Jóváhagyások többfázisú YAML-folyamatokban

Továbbra is fejlesztjük a többfázisú YAML-folyamatokat, mostantól manuális jóváhagyásokat adhat ezekhez a folyamatokhoz. Az infrastruktúra-tulajdonosok megvédhetik környezetüket, és manuális jóváhagyást kérhetnek, mielőtt bármely folyamat egy szakasza üzembe helyezené őket. Az infrastruktúra (környezet) és az alkalmazás (folyamat) tulajdonosai közötti szerepkörök teljes elkülönítésével biztosíthatja a manuális kijelentkezést egy adott folyamatban való üzembe helyezéshez, és központi vezérlést kap abban, hogy ugyanazokat az ellenőrzéseket alkalmazza az összes üzembe helyezésre a környezetben.

Approvals in multi-stage YAML pipelines.

A folyamat fejlesztői üzembe helyezése a fázis elején leáll jóváhagyásra.

Pipeline runs deploying to dev will stop for approval.

Üzemeltetett folyamatok lemezképeinek frissítései

Számos Azure Pipelines által üzemeltetett virtuálisgép-rendszerképet frissítettünk. A legújabb kiadásokról itt talál további részleteket. A frissítés részeként a következő módosítások lettek hozzáadva:

  • VS2017 és VS2019 esetén:

  • Ubuntu 16.04 esetén:

    • Frissített helm, hogy mindig a legújabb lekérés (már nem rögzített v2.14.0)
    • Több népszerű Docker-tároló hozzáadása
    • A Python frissítése a 2.7.16-os, 3.4.10-s, 3.5.7-ös, 3.6.9-ös és 3.7.4-ös verzióra
    • Módosított rozsda alapértelmezett elérési útjai és környezeti változói

  • Az összes képhez hozzáadtunk egy ImageVersion környezeti változót a kép verziójához

Az adott rendszerképhez elérhető eszközök teljes listájáért tekintse meg Gépház > Ügynökkészletek > részletei című cikket.

DevOps-projektek továbbfejlesztése virtuális gépekhez

Ebben a frissítésben továbbfejlesztettük a DevOps Projects virtuális gép (VM) munkafolyamatát, hogy tartalmazza azokat a virtuális gépeket, amelyek nem felelnek meg a helyenkénti kvótakorlátozásnak. Korábban név és ajánlat alapján kellett kiválasztania a virtuális gépet. Most egy igény szerinti nézettel rendelkezik, amely további részleteket tartalmaz a virtuálisgép-ajánlatokról, például költség/hónap, RAM, adatlemezek stb. Ez megkönnyíti a szükséges virtuális gép kiválasztását.

Enhancements to DevOps Project for virtual machine.

Egyedül üzemeltetett készlet

Az utolsó futamban azt közöltük, hogy egy új, Azure Pipelines nevű üzemeltetett készletet vezetünk be, amely az összes többi üzemeltetett készletet lecseréli : Hosted, Hosted VS2017, Hosted Ubuntu 1604, Hosted Windows 2019 with VS2019, Hosted macOS és Hosted macOS High Sierra. Ez a módosítás ezzel a kiadással lesz implementálva.

A több üzemeltetett készlet időnként zavaró lehet. Nem kap pontos képet arról, hogy hol használja fel az egyidejűséget. Ha például 10 párhuzamos feladat egyidejűsége van, az üzemeltetett készletek mindegyikében 10 virtuális ügynök jelenik meg, ami nem pontos. Ha a feladat egy adott üzemeltetett készletre (például üzemeltetett VS2017) vár az összes tétlen ügynökkel, úgy gondolhatja, hogy az Azure Pipelines szolgáltatás megszakadt anélkül, hogy felismerte, hogy az egyidejűség esetleg más üzemeltetett készletekben (például üzemeltetett Ubuntu 1604- ben) lesz felhasználva.

Ezzel a módosítással egyetlen üzemeltetett készlet jelenik meg, amely pontos képet ad arról, hogy hány feladat fut a készletben. Azt tervezzük, hogy ezt a változást a következő néhány futamon fogjuk elvégezni. A folyamatokat nem kell módosítania, mivel automatikusan átirányítjuk a feladatokat a régi üzemeltetett készletekből az új egyesített készlet megfelelő rendszerképére.

Helyes készletadatok megjelenítése mindegyik feladatnál

Korábban, amikor egy mátrixot használt a feladatok kibontásához vagy egy változót egy készlet azonosításához, problémákat tapasztaltunk a megfelelő készletadatok megjelenítésével a naplók oldalán. Ezzel a frissítéssel kijavítottuk azokat a problémákat, amelyek miatt bizonyos feladatoknál helytelen készletinformációk jelennek meg.

Terméken belüli támogatás kiszámíthatatlan tesztelések kezeléséhez

A pelyhes tesztek hatással lehetnek a fejlesztők termelékenységére, mivel előfordulhat, hogy a teszthibák nem kapcsolódnak a tesztelés alatt álló változásokhoz. Ezek hatással lehetnek a szállított kód minőségére is. Ezért adtunk hozzá terméken belüli támogatást a pelyhes tesztkezeléshez. Ez a funkció a teljes életciklust támogatja észleléssel, jelentéskészítéssel és megoldással. A pelyhes tesztkezelés támogatja a rendszer és az egyéni észlelést.

A rendszerészlelés a VSTest-feladat újrafuttatási képességen keresztül érhető el. A pikkelyes teszt olyan teszt, amely különböző eredményeket biztosít, például átengedi vagy meghiúsul, még akkor is, ha a forráskódban vagy a végrehajtási környezetben nincs változás. Az ugyanahhoz az ághoz tartozó összes további tesztvégrehajtás is pelyhesnek lesz jelölve, amíg meg nem oldja és nem jelöli. Az API-k használatával az egyéni észlelési mechanizmust is csatlakoztathatja. Ha egy teszt pelyhesként van azonosítva, lekérheti a részleteket a folyamatban lévő helyszíni tesztjelentésben. Ezután eldöntheti, hogy a pelyhes tesztek hatással vannak-e a folyamat meghibásodására. Alapértelmezés szerint a pelyhes tesztinformációk további metaadatokként érhetők el.

In-product support for flaky test management.

Íme egy példa egy jelentésre a teszt összegzésével.

Example of a report with the test summary.

A pelyhes tesztkezeléssel kapcsolatos további részletekért tekintse meg a dokumentációt itt.

A WebApp üzembehelyezési központjának fejlesztései az Azure Portalon

Továbbfejlesztettük a WebApp üzembehelyezési központját az Azure Portalon, több összetevőt tartalmazó folyamatok támogatásával. Most, ha az Azure Pipelines nem elsődleges összetevője üzembe van helyezve a webalkalmazásban, az Azure Portalról fogja megkapni a vonatkozó részleteket. Az üzembe helyezett adattárra mutató mély hivatkozással közvetlenül az Azure Portalról navigálhat az adattárhoz. Az adattár üzemeltethető az Azure Reposban vagy a GitHubon.

CI-triggerek új ágakhoz

Hosszú ideig függőben lévő kérés volt, hogy ne aktiválja a CI-buildeket egy új ág létrehozásakor, és amikor az ág nem változik. Tekintse az alábbi példákat:

  • A webes felületen létrehozhat egy új ágat egy meglévő ág alapján. Ez azonnal elindít egy új CI-buildet, ha az ágszűrő megegyezik az új ág nevével. Ez nem kívánt, mert az új ág tartalma megegyezik a meglévő ág tartalmával.
  • Van egy adattára két mappával – alkalmazással és dokumentumokkal. Beállít egy útvonalszűrőt a CI-hez, hogy megfeleljen az "alkalmazásnak". Más szóval nem szeretne új buildet létrehozni, ha egy módosítást leküldtek a dokumentumokba. Helyileg létrehoz egy új ágat, módosítja a dokumentumokat, majd leküldi az ágat a kiszolgálóra. Korábban egy új CI-buildet aktiváltunk. Ez nem kívánatos, mivel kifejezetten kérte, hogy ne keressen módosításokat a dokumentumok mappájában. Az új ágesemények kezelésének módja miatt azonban úgy tűnik, mintha az alkalmazásmappán is módosítás történt volna.

Most már van egy jobb módja annak, hogy az új ágak ci-t kezeljenek ezeknek a problémáknak a megoldásához. Új ág közzétételekor kifejezetten új véglegesítéseket keresünk az adott ágban, és ellenőrizzük, hogy azok megfelelnek-e az elérésiút-szűrőknek.

Terraform-integráció az Azure Pipelines-zal

A Terraform egy nyílt forráskódú eszköz az infrastruktúra biztonságos és hatékony fejlesztéséhez, módosításához és verziószámozásához. A Terraform deklaratív konfigurációs fájlokká kodifikálja az API-kat, így magas szintű konfigurációs nyelv használatával definiálhat és építhet ki infrastruktúrát. A Terraform bővítmény használatával erőforrásokat hozhat létre az összes főbb infrastruktúra-szolgáltatóban: az Azure-ban, az Amazon Web Servicesben (AWS) és a Google Cloud Platformban (GCP).

A Terraform-bővítménysel kapcsolatos további információkért tekintse meg az itt található dokumentációt.

Terraform integration with Azure Pipelines.

Integráció a Google Analytics-szel

A Google Analytics kísérletek keretrendszerével szinte bármilyen módosítást vagy módosítást tesztelhet egy webhely vagy alkalmazás esetében annak egy adott célkitűzésre gyakorolt hatásának méréséhez. Lehetnek például olyan tevékenységei, amelyeket el szeretne végezni a felhasználók számára (pl. vásárlás, hírlevélre való feliratkozás) és/vagy a javítani kívánt metrikák (például bevétel, munkamenet időtartama, visszapattanási arány). Ezek a tevékenységek lehetővé teszik, hogy a szolgáltatás teljesítményére gyakorolt közvetlen hatásuk alapján azonosítsa a implementálni kívánt módosításokat.

Az Azure DevOps Google Analytics-kísérletek bővítménye kísérletezési lépésekkel bővíti a buildelési és kiadási folyamatokat, így folyamatosan iterálhat, tanulhat és helyezhet üzembe gyorsított ütemben a kísérletek folyamatos kezelésével, miközben az Azure Pipelines minden DevOps-előnyét kihasználhatja.

A Google Analytics kísérletek bővítményét a Marketplace-ről töltheti le.

Integration with Google Analytics.

Folyamatok gyorsítótárazása (nyilvános előzetes verzió)

A folyamat gyorsítótárazásával mentheti egy hosszú ideig futó művelet eredményeit, például egy csomag-visszaállítást vagy egy függőségi fordítást, és visszaállíthatja azt a folyamat következő futtatása során. Ez gyorsabb buildelést eredményezhet.

További részletekért lásd a blogbejegyzést a teljes bejelentést itt.

Parancsok folyamat-változócsoportok és változók kezeléséhez

A YAML-alapú folyamatokat nehéz lehet egyik projektből a másikba portolni, mivel manuálisan kell beállítania a folyamatváltozókat és a változócsoportokat. A folyamatváltozók csoportjával és a változókezelési parancsokkal azonban most már szkriptelheti a folyamatváltozók és változócsoportok beállítását és kezelését, amelyek viszont szabályozhatók, így egyszerűen megoszthatja a folyamatok egyik projektből a másikba való áthelyezésére és beállítására vonatkozó utasításokat.

Folyamatfuttatás lekéréses kérelem ágához

Pr létrehozásakor nehéz lehet ellenőrizni, hogy a módosítások megszakíthatják-e a folyamat futtatását a célágon. Ha azonban képes elindítani egy folyamatfuttatást vagy egy build várólistára helyezését egy PR-ághoz, most már ellenőrizheti és megjelenítheti a folyamatban lévő módosításokat a célfolyamaton való futtatással. További információkért tekintse meg az az pipelines run és az az pipelines build queue parancsdokumentációját.

Az első folyamatfuttatás kihagyása

Folyamatok létrehozásakor előfordulhat, hogy YAML-fájlt szeretne létrehozni és véglegesíteni, és nem aktiválni a folyamatfuttatást, mert az számos okból hibás futtatást eredményezhet – az infrastruktúra nem áll készen, vagy változó-/változócsoportok létrehozására és frissítésére van szükség stb. Az Azure DevOps CLI-vel most már kihagyhatja az első automatizált folyamatfuttatást egy folyamat létrehozásakor a --skip-first-run paraméter hozzáadásával. További információkért tekintse meg az az pipeline create parancsdokumentációját .

Szolgáltatásvégpont-parancsok fejlesztése

A szolgáltatásvégpont cli-parancsai csak az Azure RM és a GitHub szolgáltatásvégpont beállítását és kezelését támogatták. Ezzel a kiadással azonban a szolgáltatásvégpont-parancsok lehetővé teszik bármely szolgáltatásvégpont létrehozását a konfiguráció fájlon keresztüli biztosításával, és optimalizált parancsokat biztosít – az az devops service-endpoint github és az az devops service-endpoint azurerm, amelyek első osztályú támogatást nyújtanak az ilyen típusú szolgáltatásvégpontok létrehozásához. További információt a parancsdokumentációban talál.

További lépések

Megjegyzé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 visszajelzési menüben jelentheti a problémát, vagy javaslatot adhat.

Make a suggestion

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

Köszönettel:

Sam Guckenheimer