New Boards Hubs public preview
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
- Extended YAML Pipelines templates can now be passed context information for stages, jobs, and deployments
- Updated retirement date for Windows 2016 hosted images
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.
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.
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
, ordeployments
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.
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.
You can also get advice and your questions answered by the community on Stack Overflow.
Thanks,
Aaron Hallberg