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

Új sprint burndown widget és továbbfejlesztett folyamatok biztonsága – Sprint 160 Update

  • Cikk

Az Azure DevOps Sprint 160 frissítésében hozzáadtunk egy új sprint burndown widgetet, amely támogatja a leégést történetpontok, tevékenységek száma és egyéni mezők összegzése alapján. Emellett továbbfejlesztettük a folyamatok biztonságát is azzal, hogy korlátoztuk a hozzáférési jogkivonatok hatókörét.

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

Az Azure DevOps újdonságai

Funkciók

Azure Repos:

Azure Pipelines:

Azure Artifacts:

Jelentések:

Wiki:

Azure Repos

Több adattárra kiterjedő ágszabályzat felügyelete

A fiókszabályzatok az Azure-adattárak egyik hatékony funkciója, amely segít a fontos ágak védelmében. Bár a szabályzatok projektszinten történő beállításának lehetősége a REST API-ban létezik, nem volt hozzá felhasználói felület. Most a rendszergazdák beállíthatnak szabályzatokat egy adott ágra vagy az alapértelmezett ágra a projekt összes adattárában. Egy rendszergazdának például két minimális felülvizsgálóra lehet szüksége a projekt minden fő ágában végrehajtott lekéréses kérelmekhez a projekt minden adattárában. Az Ágvédelem hozzáadása funkciót a Tárprojekt beállításai között találja.

Tárházközi fiókházirend-felügyelet.

Azure Pipelines

Többfázisú folyamatok felhasználói felület

A folyamatok kezeléséhez frissített felhasználói felületen dolgozunk. Ezek a frissítések modernebbé teszik a folyamatokat, és összhangban vannak az Azure DevOps irányával. Ezenkívül ezek a frissítések egyetlen felületen egyesítik a klasszikus buildfolyamatokat és a többfázisú YAML-folyamatokat. Az új felület például a következő képességeket tartalmazza; több fázis megtekintése és kezelése, a folyamatfuttatások jóváhagyása, a naplókban való görgetés lehetősége, miközben egy folyamat még folyamatban van, és egy folyamat ágonkénti állapota.

Köszönjük mindenkinek, aki kipróbálta az új élményt. Ha még nem próbálta, engedélyezze a többfázisú folyamatokat az előzetes verziójú funkciókban. A többfázisú folyamatokkal kapcsolatos további információkért tekintse meg az itt található dokumentációt.

Többfázisú folyamatok UX.

Visszajelzésének köszönhetően az alábbiakat kezeltük az utolsó két frissítésben.

  1. A mappák nézet felderíthetősége.
  2. Jumpiness a naplók nézetben.
  3. Az előző és az aktuális tevékenységek naplóinak megjelenítése akkor is, ha futtatás van folyamatban.
  4. A naplók áttekintésekor megkönnyítheti a tevékenységek közötti navigálást.

Az új felület funkciói.

Feljegyzés

A következő frissítésben azt tervezzük, hogy ezt a funkciót alapértelmezés szerint bekapcsoljuk mindenki számára. Továbbra is lehetősége lesz kikapcsolni az előnézetet. Néhány héttel ezt követően a funkció általánosan elérhetővé válik.

Tesztcsoportos üzembe helyezési stratégia levezénylése a Kubernetes-környezetben

Az alkalmazásfrissítések folyamatos kézbesítésének egyik fő előnye, hogy gyorsan le lehet küldeni a frissítéseket az éles környezetbe adott mikroszolgáltatásokhoz. Ez lehetővé teszi, hogy gyorsan reagáljon az üzleti követelmények változásaira. A környezet első osztályú koncepcióként lett bevezetve, amely lehetővé teszi az üzembehelyezési stratégiák vezénylését és a nulla állásidő-kiadás megkönnyítését. Korábban támogattuk a runOnce stratégiát, amely egymás után hajtotta végre a lépéseket. A többfázisú folyamatokban a kanáristratégia támogatásával csökkentheti a kockázatot, ha lassan kis részhalmazra gördíti a módosítást. Az új verzióba vetett nagyobb bizalommal kezdheti el a bevezetést az infrastruktúra több kiszolgálójához, és több felhasználót irányíthat hozzá.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

A Kuberenetes kanári-stratégiája először 10%-os podokkal fogja üzembe helyezni a módosításokat, majd 20%, miközben a postRouteTraffic során figyeli az állapotot. Ha minden jól megy, 100%-ra fog előléptetni.

Jóváhagyási szabályzatok YAML-folyamatokhoz

A YAML-folyamatokban egy erőforrás tulajdonos által vezérelt jóváhagyási konfigurációját követjük. Az erőforrás-tulajdonosok jóváhagyásokat konfigurálnak az erőforráson és az összes olyan folyamaton, amely az erőforrás-szüneteltetést használja jóváhagyásra az erőforrást használó fázis megkezdése előtt. A SOX-alapú alkalmazások tulajdonosai gyakran korlátozzák, hogy az üzembe helyezés kérelmezője jóváhagyja a saját üzemelő példányait.

Most már speciális jóváhagyási lehetőségeket is használhat a jóváhagyási szabályzatok konfigurálásához, például a kérelmezőnek nem szabad jóváhagynia, jóváhagyást igényelnie a felhasználók egy részhalmazától és a jóváhagyási időtúllépéstől.

Jóváhagyási szabályzatok YAML-folyamatokhoz.

Az ACR mint első osztályú folyamaterőforrás

Ha a folyamat részeként az ACR-ben (Azure Container Registry) közzétett tárolórendszerképet kell használnia, és az új rendszerkép közzétételekor aktiválnia kell a folyamatot, használhatja az ACR-tárolóerőforrást.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production

Emellett az ACR-rendszerkép metaadatai előre definiált változókkal is elérhetők. Az alábbi lista tartalmazza azokat az ACR-változókat, amelyekkel definiálhat egy ACR-tárolóerőforrást a folyamatban.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Folyamat-erőforrás metaadatai mint előre definiált változók

Előre definiált változókat adtunk hozzá a folyamat YAML-folyamatok erőforrásaihoz. Íme az elérhető folyamaterőforrás-változók listája.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

Folyamatok és ACR-erőforrások nyomon követhetősége

Teljes E2E-nyomon követhetőséget biztosítunk, ha folyamatokat és ACR-tárolóerőforrásokat használnak egy folyamatban. A YAML-folyamat által felhasznált összes erőforrás esetében visszakövetheti a véglegesítéseket, a munkaelemeket és az összetevőket.

A folyamatfuttatás összefoglaló nézetében a következő látható:

  • A futtatás aktiváló erőforrásverziója. A folyamat most aktiválható egy másik Azure-folyamatfuttatás befejezésekor, vagy egy tárolórendszerkép ACR-be való leküldésekor.

    A futtatásokat aktiváló erőforrásverzió.

  • A folyamat által felhasznált véglegesítések . A véglegesítések lebontását a folyamat által felhasznált erőforrások szerint is megtalálhatja.

    A folyamat által felhasznált véglegesítések.

  • A folyamat által felhasznált egyes erőforrásokhoz társított munkaelemek .

  • A futtatás által használandó összetevők .

    A futtatás által használható összetevők.

A környezet üzembe helyezési nézetében láthatja a környezetbe telepített egyes erőforrások véglegesítéseit és munkaelemeit.

Véglegesítések és munkaelemek a környezetben üzembe helyezett egyes erőforrásokhoz.

Az erőforrások egyszerűsített hitelesítése a YAML-folyamatokban

Az erőforrás a folyamaton kívüli folyamatok által használt bármi. Az erőforrásokat a használatuk előtt engedélyezni kell. Korábban, amikor jogosulatlan erőforrásokat használt egy YAML-folyamatban, az erőforrás-engedélyezési hibával meghiúsult. A sikertelen futtatás összefoglaló oldaláról kellett engedélyeznie az erőforrásokat. Emellett a folyamat meghiúsult, ha jogosulatlan erőforrásra hivatkozó változót használt.

Mostantól egyszerűbbé tesszük az erőforrás-engedélyezések kezelését. A futtatás sikertelensége helyett a futtatás megvárja az erőforrások engedélyeit az erőforrást használó szakasz elején. Az erőforrás tulajdonosa megtekintheti a folyamatot, és engedélyezheti az erőforrást a Biztonság lapon.

Egyszerűsített erőforrás-engedélyezés YAML-folyamatokban.

Továbbfejlesztett folyamatbiztonság a hozzáférési jogkivonatok hatókörének korlátozásával

Az Azure Pipelinesban futó összes feladat kap egy hozzáférési jogkivonatot. A hozzáférési jogkivonatot a feladatok és a szkriptek használják az Azure DevOpsba való visszahíváshoz. A hozzáférési jogkivonat használatával például lekérjük a forráskódot, feltöltjük a naplókat, teszteljük az eredményeket, az összetevőket, vagy REST-hívásokat indítunk az Azure DevOpsba. Minden feladathoz létrehoz egy új hozzáférési jogkivonatot, és a feladat befejeződése után lejár. Ezzel a frissítéssel a következő fejlesztéseket adtuk hozzá.

  • A jogkivonat csoportprojekten kívüli erőforrások elérésének megakadályozása

    Eddig az összes folyamat alapértelmezett hatóköre a csapatprojekt-gyűjtemény volt. A hatókört módosíthatja csoportprojektként a klasszikus buildelési folyamatokban. A klasszikus kiadási vagy YAML-folyamatok esetében azonban nem rendelkezik ezzel a vezérlőkkel. Ezzel a frissítéssel egy szervezeti beállítást vezetünk be, amely minden feladatot arra kényszerít, hogy projekthatókörű jogkivonatot kapjon, függetlenül attól, hogy mi van konfigurálva a folyamatban. A beállítást a projekt szintjén is hozzáadtuk. Mostantól minden létrehozott új projekt és szervezet automatikusan bekapcsolja ezt a beállítást.

    Feljegyzés

    A szervezeti beállítás felülírja a projektbeállítást.

    Ha ezt a beállítást bekapcsolja a meglévő projektekben és szervezetekben, bizonyos folyamatok meghiúsulhatnak, ha a folyamatok hozzáférési jogkivonatokkal férnek hozzá a csoportprojekten kívüli erőforrásokhoz. A folyamathibák csökkentése érdekében explicit módon hozzáférést adhat a Project Build szolgáltatásfiókjának a kívánt erőforráshoz. Javasoljuk, hogy kapcsolja be ezeket a biztonsági beállításokat.

  • A hozzáférési jogkivonat bizonyos engedélyeinek eltávolítása

    Alapértelmezés szerint több engedélyt adunk a hozzáférési jogkivonathoz, az egyik ilyen engedély a Queue build. Ezzel a frissítéssel eltávolítottuk ezt az engedélyt a hozzáférési jogkivonatra. Ha a folyamatoknak szüksége van erre az engedélyre, a használt jogkivonattól függően explicit módon adhatják meg a Project Build szolgáltatásfiókjának vagy a Project Collection buildszolgáltatás-fiókjának .

Munkadarabok ellenőrzésének értékelése

Most már definiálhat egy szabályzatkészletet, és hozzáadhatja a szabályzat kiértékelését a tárolólemezkép-összetevők környezetének ellenőrzéseként. Amikor egy folyamat fut, a végrehajtás szünetel, mielőtt elindít egy olyan szakaszt, amely a környezetet használja. A rendszer kiértékeli a megadott szabályzatot az üzembe helyezett rendszerkép elérhető metaadatai alapján. Az ellenőrzés akkor megy át, ha a szabályzat sikeres, és sikertelenként jelöli meg a szakaszt.

Az összetevők ellenőrzésének kiértékelése.

Markdown-támogatás a tesztek automatikus hibaüzeneteinél

Mostantól támogatjuk a Markdownt az automatizált tesztek hibaüzeneteiben. A hibaüzeneteket egyszerűen formázhatja a tesztfuttatáshoz és a tesztelés eredményéhez is, így javítható az olvashatóság, és könnyebben elhárítható a hiba az Azure Pipelinesban. A támogatott Markdown-szintaxis itt található.

Markdown-támogatás automatizált tesztelési hibaüzenetekben.

Cron-ütemezések diagnosztizálása a YAML-ban

Folyamatosan nőtt a cron szintaxis használata a YAML-folyamatok ütemezéseinek megadásához. Amikor meghallgattuk a visszajelzését, azt hallottuk, hogy nehéz megállapítani, hogy az Azure Pipelines helyesen dolgozza-e fel a szintaxist. Korábban meg kell várnia az ütemezett futtatás tényleges időpontját az ütemezési problémák hibakereséséhez. Az ág-/szintaxishibák diagnosztizálásához új műveleti menüt adtunk hozzá a folyamathoz. A Futtatás folyamat menüjében az Ütemezett futtatások menüben megtekintheti a folyamat közelgő néhány ütemezett futását, hogy könnyebben diagnosztizálhassa a cron-ütemezésekkel kapcsolatos hibákat.

Cron-ütemezések diagnosztizálása a YAML-ben.

Az ARM-sablon üzembehelyezési feladatának frissítései

Korábban nem szűrtük a szolgáltatáskapcsolatokat az ARM-sablon üzembe helyezési feladatában. Ez azt eredményezheti, hogy az üzembe helyezés meghiúsul, ha alacsonyabb hatókörű szolgáltatáskapcsolatot választ az ARM-sablonok szélesebb hatókörbe történő üzembe helyezéséhez. Most hozzáadtuk a szolgáltatáskapcsolatok szűrését, hogy kiszűrjük az alacsonyabb hatókörű szolgáltatáskapcsolatokat a választott üzembehelyezési hatókör alapján.

Projektszintű biztonság a szolgáltatási kapcsolatokhoz

Ezzel a frissítéssel központi szintű biztonságot adtunk hozzá a szolgáltatáskapcsolatokhoz. Mostantól hozzáadhat/eltávolíthat felhasználókat, szerepköröket rendelhet hozzá és kezelheti a hozzáférést egy központosított helyen az összes szolgáltatáskapcsolathoz.

A szolgáltatáskapcsolatok projektszintű biztonsága.

Ubuntu 18.04-készlet

Az Azure Pipelines mostantól támogatja a feladatok Ubuntu 18.04-en való futtatását. Frissítettük a Microsoft által üzemeltetett Azure Pipelines-készletet, hogy tartalmazza az Ubuntu-18.04 rendszerképet. Most, ha a YAML-folyamatok készletére hivatkozik ubuntu-latest , az azt jelenti ubuntu-18.04 , és nem ubuntu-16.04. A feladatokban ubuntu-16.04 lévő 16.04-képeket továbbra is megcélzhatja explicit módon.

Szolgáltatási háló interfészén alapuló tesztcsoportos üzembe helyezés a KubernetesManifest-feladatban

Korábban, amikor a KubernetesManifest tevékenységben meghatározták a kanári-stratégiát, a tevékenység alapkonfigurációt és kanári számítási feladatokat hoz létre, amelyek replikái megegyeznek a stabil számítási feladatokhoz használt replikák százalékával. Ez nem volt pontosan ugyanaz, mint a forgalom felosztása a kívánt százalékra a kérelem szintjén. Ennek megoldásához a KubernetesManifest feladathoz hozzáadtuk a Service Mesh Interface-alapú kanári-telepítések támogatását.

A Service Mesh interface absztrakciója lehetővé teszi a plug-and-play konfigurációt olyan szolgáltatásháló-szolgáltatókkal, mint a Linkerd és az Istio. A KubernetesManifest-feladat most elveszi az SMI TrafficSplit objektumainak stabil, alapkonfigurációs és kanári-szolgáltatásokhoz való leképezésének kemény munkáját az üzembehelyezési stratégia életciklusa során. A forgalom kívánt százalékos felosztása a stabil, az alapterv és a kanári között pontosabb, mivel a forgalom százalékos felosztását a szolgáltatásháló síkon lévő kérések vezérlik.

Az alábbiakban az SMI-alapú kanári-telepítéseket gördülő módon hajtjuk végre.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Alkalmazás áttekintése a környezetben

A ReviewApp minden lekéréses kérelmet üzembe helyez a Git-adattárból egy dinamikus környezeti erőforrásba. A véleményezők láthatják, hogyan néznek ki ezek a módosítások, valamint más függő szolgáltatásokkal is dolgozhatnak, mielőtt egyesítenék őket a főágban, és üzembe helyezték őket az éles környezetben. Ez megkönnyíti a reviewApp-erőforrások létrehozását és kezelését, valamint a környezeti funkciók nyomon követhetőségének és diagnosztizálásának előnyeit. A reviewApp kulcsszóval létrehozhat egy erőforrás klónját (dinamikusan létrehozhat egy új erőforrást egy meglévő erőforrás alapján egy környezetben), és hozzáadhatja az új erőforrást a környezethez.

Az alábbiakban egy minta YAML-kódrészletet tekintünk meg, amely a reviewApp környezetekben való használatát ismerteti.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

Azure Artifacts

Frissítés a hírcsatornához való csatlakozáshoz

A Csatlakozás a hírcsatornához párbeszédpanel az Azure Artifacts használatának belépési útja; Információkat tartalmaz arról, hogyan konfigurálhatja az ügyfeleket és az adattárakat csomagok leküldésére és lekérésére az Azure DevOps csatornáiból. Frissítettük a párbeszédpanelt, hogy részletes beállítási információkat adjunk hozzá, és kibővítsük azokat az eszközöket, amelyekhez útmutatást adunk.

Általánosan elérhetők a nyilvános csatornák kiinduló támogatással

A nyilvános hírcsatornák nyilvános előzetes verziója nagyszerű bevezetést és visszajelzést kapott. Ebben a frissítésben további funkciókat bővítettünk az általános rendelkezésre állásra. Most beállíthat egy nyilvános hírcsatornát felsőbb rétegbeli forrásként egy privát hírcsatornából. A konfigurációs fájlok egyszerűek maradnak, ha privát és projekthatókörű hírcsatornákba is be- és leküldhetők.

Projekthatókörű hírcsatornák létrehozása a portálon

Nyilvános hírcsatornák kiadásakor projekthatókörű hírcsatornákat is kiadtunk. Eddig a projekthatókörű hírcsatornák REST API-kkal vagy egy nyilvános hírcsatorna létrehozásával hozhatók létre, majd a projekt privátvá alakításával. Mostantól bármelyik projektből létrehozhat projekthatókörű hírcsatornákat, ha rendelkezik a szükséges engedélyekkel. Azt is láthatja, hogy mely hírcsatornák projektalapúak, és melyek szervezeti hatókörrel vannak elosztva a hírcsatornaválasztóban.

Jelentéskészítés

Egy Sprint Burndown widget mindennel, amit kért

Az új Sprint Burndown widget támogatja az írást történetpontok, feladatok száma vagy egyéni mezők összegzése alapján. A funkciókhoz vagy az Epicshez akár sprint burndownt is létrehozhat. A widget megjeleníti az átlagos leégést, a készültségi %- ot és a hatókör növekedését. Konfigurálhatja a csapatot, így több csapat sprintleütéseit jelenítheti meg ugyanazon az irányítópulton. Ezzel a nagyszerű információval akár 10x10-et is átméretezhet az irányítópulton.

Sprint Burndown widget.

A kipróbáláshoz hozzáadhatja a widgetkatalógusból, vagy a meglévő Sprint Burndown widget konfigurációjának szerkesztésével és az új verzió kipróbálása jelölőnégyzet bejelölésével.

Feljegyzés

Az új widget az Analytics szolgáltatást használja. Megtartottuk az örökölt Sprint Burndownt, ha nem fér hozzá az Analyticshez.

Wiki

Szinkron görgetés wiki-oldalak szerkesztéséhez

A wikilapok szerkesztése mostantól egyszerűbbé vált a szerkesztés és az előnézeti ablaktábla közötti szinkron görgetéssel. Az egyik oldalon való görgetés automatikusan görget a másik oldalon a megfelelő szakaszok leképezéséhez. A váltógombbal letilthatja a szinkron görgetést.

Szinkron görgetés a wikilapok szerkesztéséhez.

Feljegyzés

A szinkron görgetőkapcsoló állapota felhasználónként és szervezetenként lesz mentve.

Oldallátogatottság wiki-oldalakhoz

Most már betekintést nyerhet a wikilapok oldallátogatásaiba. A REST API lehetővé teszi az oldallátogatások adatainak elérését az elmúlt 30 napban. Ezekkel az adatokkal jelentéseket hozhat létre a wikilapokhoz. Emellett ezeket az adatokat az adatforrásban is tárolhatja, és irányítópultokat hozhat létre, hogy konkrét megállapításokat kapjon, például a legnézettebb lapokat.

A laplátogatások összesített száma is megjelenik az elmúlt 30 napban minden oldalon.

A wikilapok oldallátogatások.

Feljegyzés

Az oldallátogatásokat egy adott felhasználó oldalnézetként definiálja 15 perces időközönként.

Következő lépések

Feljegyzés

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

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

Ugrás az Azure DevOpsra

Visszajelzés küldése

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

Javaslat készítése

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

Köszönettel:

Jeff Beehler