Edit

New Boards Hubs public preview

  • Article

New Boards Hubs is now available in public preview. The web platform has been updated to provide a new modern design, responsive reflows, accessibility compliance, and improved page performance.

Check out the release notes for details.

General

Azure Boards

Azure Pipelines

General

Auditing is now an opt-in feature for your organization

Auditing has now been made an opt-in feature on Azure DevOps. If your organization does not actively use Auditing today (i.e. have visited Auditing logs at least twice in the past 90 days or have a configured Auditing stream), you will have to explicitly turn On the auditing feature for your organization to start doing so. After turning On, auditing events will be included in your organization’s audit log. For organizations that are active users of Auditing, the feature will remain On.

You can enable Auditing on your organization from your Organization settings page.

On the right-hand sidebar, you will see Policies underneath the Security header. Assuming your organization is backed by Azure Active Directory, you should see that one of the available security policies to enable is Log Audit Events. MSA-backed organizations will no longer have the Auditing features available to them.

Audit events

Simply toggle this policy On and Auditing should now be available (if it does not immediately appear, refresh the page and it should be available). If you no longer want to receive Auditing events, toggle the button to Off. When the button is toggled off, the Auditing page will no longer appear in the sidebar and the Auditing Logs page will be unavailable. All configured audit streams will stop receiving events.

Guest users will only see public user data

When the External guest access policy is disabled and the Allow public projects policy is enabled, guest users will only be able to see public user data, like display name, etc., for members of public projects. This is the same experience granted for anonymous users. This applies to any personal data available through the web experience (e.g. in the Identity Picker that appears when a user tries to mention another user or assign work items) and any personal data available through our REST APIs.

Azure Boards

New Boards Hubs now available in public preview

For the last several months our team has been focused on modernizing the user experience for the Azure Boards Hubs. The UI has been updated to provide a faster user interface, consistency with other parts of the product, and improved accessibility. The team is excited to finally announce the public preview for the new Azure Boards experience.

The functionality remains the same, but you can expect the following:

  • Modern design
  • Responsive reflows
  • Improved performance
  • Accessibility compliance

To opt-in to the public preview, in the preview features section toggle the feature named New Boards Hubs to On.

Gif to demo opt-in to the public preview.

If for some reason the New Boards Hubs are causing you a blocking issue, you can turn off the preview. But please try the new experience and send us your feedback. Be sure to let us know if anything is missing or not working as expected.

Azure Pipelines

Extended YAML Pipelines templates can now be passed context information for stages, jobs, and deployments

With this update, we are adding a new templateContext property for job, deployment, and stage YAML pipeline components meant to be used in conjunction with templates.

Here is a scenario for using templateContext:

  • You use templates to reduce code duplication or to improve the security of your pipelines

  • Your template takes as parameter a list of stages, jobs, or deployments

  • The template processes the input list and performs some transformations on each of the stages, jobs, or deployments. For example, it sets the environment in which each job runs or adds additional steps to enforce compliance

  • The processing requires additional information to be passed by the pipeline author into the template for each stage, job, or deployment in the list

Let's look at an example. Say you are authoring a pipeline that runs end-to-end tests for pull request validation. Your goal is to test only one component of your system, but, because you plan to run end-to-end tests, you need an environment where more of the system's components are available, and you need to specify their behavior.

You realize other teams will have similar needs, so you decide to extract the steps for setting up the environment into a template. Its code looks like the following:

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 }}

What the template does is, for each job in the testSet parameter, it sets the response of the system's components specified by ${{ testJob.templateContext.requiredComponents }} to return ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Then, you can create your own pipeline that extends testing-template.yml like in the following example.

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

This pipeline runs two tests, a positive and a negative one. Both tests require the dimensionsapi component be available. The positive_test job expects the dimensionsapi return HTTP code 200, while negative_test expects it return HTTP code 500.

Updated retirement date for Windows 2016 hosted images

We have moved the retirement date for Windows 2016 images from April 1 to June 30. While most customers using this image have updated their pipelines, there are still customers who are using this image. To verify if your organization is using Windows 2016, use these instructions to identity pipelines using deprecated images.

To help customers identify pipelines, we will continue to perform brownouts. These are 24 hour periods in which the image will not be available, causing pipeline jobs that run during this time to fail. The brownouts will happen on:

  • Monday April 18
  • Tuesday April 26
  • Wednesday May 4
  • Thursday May 12
  • Friday May 20
  • Monday May 23
  • Tuesday May 31
  • Wednesday June 8
  • Thursday June 16
  • Friday June 24
  • Monday June 27

Next steps

Note

These features will roll out over the next two to three weeks.

Head over to Azure DevOps and take a look.

Go to Azure DevOps

How to provide feedback

We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.

Make a suggestion

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Aaron Hallberg