Dela via

Ny offentlig förhandsversion av Boards Hubs

  • Artikel

Nya Boards Hubs är nu tillgängligt i offentlig förhandsversion. Webbplattformen har uppdaterats för att ge en ny modern design, dynamiska omflöden, tillgänglighetsefterlevnad och förbättrade sidprestanda.

Mer information finns i viktig information.

Allmänt

Azure-tavlor

Azure-pipelines

Allmänt

Granskning är nu en opt-in-funktion för din organisation

Granskning har nu gjorts till en opt-in-funktion i Azure DevOps. Om din organisation inte aktivt använder granskning i dag (d.v.s. har besökt granskningsloggar minst två gånger under de senaste 90 dagarna eller har en konfigurerad granskningsström) måste du uttryckligen aktivera granskningsfunktionen för att din organisation ska börja göra det. När du har aktiverat På inkluderas granskningshändelser i organisationens granskningslogg. För organisationer som är aktiva granskningsanvändare förblir funktionen På.

Du kan aktivera granskning i din organisation från sidan Organisationsinställningar .

I sidofältet till höger visas Principer under säkerhetsrubriken. Förutsatt att din organisation backas upp av Azure Active Directory bör du se att en av de tillgängliga säkerhetsprinciperna som ska aktiveras är Logggranskningshändelser. MSA-stödda organisationer har inte längre granskningsfunktionerna tillgängliga för dem.

Granskningshändelser

Det är bara att växla den här principen på och Granskning ska nu vara tillgängligt (om den inte visas omedelbart uppdaterar du sidan så ska den vara tillgänglig). Om du inte längre vill ta emot granskningshändelser växlar du knappen till Av. När knappen är inaktiverad visas inte längre sidan Granskning i sidofältet och sidan Granskningsloggar är inte tillgänglig. Alla konfigurerade granskningsströmmar slutar ta emot händelser.

Gästanvändare ser endast offentliga användardata

När principen för extern gäståtkomst är inaktiverad och principen Tillåt offentliga projekt är aktiverad kan gästanvändare endast se offentliga användardata, till exempel visningsnamn osv., för medlemmar i offentliga projekt. Det här är samma upplevelse som beviljas för anonyma användare. Detta gäller för alla personuppgifter som är tillgängliga via webbupplevelsen (t.ex. i identitetsväljaren som visas när en användare försöker nämna en annan användare eller tilldela arbetsobjekt) och alla personliga data som är tillgängliga via våra REST-API:er.

Azure-tavlor

Nya Boards Hubs är nu tillgängliga i offentlig förhandsversion

Under de senaste månaderna har vårt team fokuserat på att modernisera användarupplevelsen för Azure Boards Hubs. Användargränssnittet har uppdaterats för att ge ett snabbare användargränssnitt, konsekvens med andra delar av produkten och förbättrad tillgänglighet. Teamet är glada över att äntligen kunna presentera den offentliga förhandsversionen av den nya Azure Boards-upplevelsen.

Funktionerna förblir desamma, men du kan förvänta dig följande:

  • Modern design
  • Dynamiska omflöden
  • Förbättrade prestanda
  • Tillgänglighetsefterlevnad

Om du vill anmäla dig till den offentliga förhandsversionen går du till avsnittet för förhandsgranskningsfunktioner och växlar funktionen med namnet New Boards Hubs till På.

Gif för att demonstrera anmäl dig till den offentliga förhandsversionen.

Om de nya boards-hubbarna av någon anledning orsakar ett blockeringsproblem kan du inaktivera förhandsversionen. Men prova den nya upplevelsen och skicka oss din feedback. Meddela oss om något saknas eller inte fungerar som förväntat.

Azure-pipelines

Utökade YAML-pipelinesmallar kan nu skickas kontextinformation för faser, jobb och distributioner

Med den här uppdateringen lägger vi till en ny templateContext egenskap för job, deploymentoch stage YAML-pipelinekomponenter som är avsedda att användas tillsammans med mallar.

Här är ett scenario för att använda templateContext:

  • Du använder mallar för att minska kodduplicering eller för att förbättra säkerheten för dina pipelines

  • Mallen tar som parameter en lista med stages, jobseller deployments

  • Mallen bearbetar indatalistan och utför vissa transformeringar på var och en av faserna, jobben eller distributionerna. Den anger till exempel den miljö där varje jobb körs eller lägger till ytterligare steg för att framtvinga efterlevnad

  • Bearbetningen kräver att ytterligare information skickas av pipelineförfattaren till mallen för varje steg, jobb eller distribution i listan

Låt oss ta en titt på ett exempel. Anta att du redigerar en pipeline som kör slutpunkt till slutpunkt-tester för validering av pull-begäranden. Målet är att bara testa en komponent i systemet, men eftersom du planerar att köra tester från slutpunkt till slutpunkt behöver du en miljö där fler av systemets komponenter är tillgängliga och du måste ange deras beteende.

Du inser att andra team har liknande behov, så du bestämmer dig för att extrahera stegen för att konfigurera miljön i en mall. Koden ser ut så här:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Vad mallen gör är att för varje jobb i parametern testSet anges svaret för systemets komponenter som anges av ${{ testJob.templateContext.requiredComponents }} för att returnera ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Sedan kan du skapa en egen pipeline som sträcker sig testing-template.yml som i följande exempel.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Den här pipelinen kör två tester, en positiv och en negativ. Båda testerna kräver att komponenten dimensionsapi är tillgänglig. Jobbet positive_test förväntar sig att dimensionsapi HTTP-koden 200 returneras, medan negative_test den förväntar sig att den returnerar HTTP-kod 500.

Datum för indragning för värdbaserade Avbildningar i Windows 2016 har uppdaterats

Vi har flyttat tillbakadragningsdatumet för Windows 2016-avbildningar från 1 april till 30 juni. De flesta kunder som använder den här avbildningen har uppdaterat sina pipelines, men det finns fortfarande kunder som använder den här avbildningen. Om du vill kontrollera om din organisation använder Windows 2016 använder du de här anvisningarna för att identifiera pipelines med inaktuella avbildningar.

För att hjälpa kunderna att identifiera pipelines fortsätter vi att utföra brownouts. Det här är 24-timmarsperioder där avbildningen inte är tillgänglig, vilket gör att pipelinejobb som körs under den här tiden misslyckas. Brownouts kommer att ske på:

  • Måndag 18 april
  • Tisdag 26 april
  • Onsdag 4 maj
  • Torsdag 12 maj
  • Fredag 20 maj
  • Måndag 23 maj
  • Tisdag 31 maj
  • Onsdag 8 juni
  • Torsdag 16 juni
  • Fredag 24 juni
  • Måndag 27 juni

Nästa steg

Anteckning

Dessa funktioner kommer att distribueras under de kommande två till tre veckorna.

Gå till Azure DevOps och ta en titt.

Gå till Azure DevOps

Så här ger du feedback

Vi vill gärna höra vad du tycker om de här funktionerna. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.

Ge ett förslag

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Aaron Hallberg