AZ-400 Question 48
Select 2You are setting up a new release pipeline for a .NET Core microservices project in Azure DevOps. Each microservice includes XML documentation comments for generating API documentation, and your team also wants to maintain release notes that list completed work items and any relevant commit messages. As part of the release process, you need to automate the generation of both the API documentation and the release notes, then publish them for stakeholders to review. Which two actions should you configure in your pipeline to meet these requirements?
- A
A. Use a Marketplace extension or a custom script to parse commits and work items from the current release, then generate formatted release notes.
- B
B. Include a task that runs 'dotnet build' with XML documentation enabled, then upload the generated .xml files by using a Publish Pipeline Artifact task.
- C
C. Attach the raw .csproj files to the release pipeline for stakeholders to manually extract documentation and determine work items.
- D
D. Configure a test task to run during the Integration Test phase that automatically produces and commits updated release notes to the repository.
Show answer and explanation
Correct answers: A, B
Explanation
To configure release documentation in Azure DevOps, you typically set up two distinct steps: one to generate release notes by parsing commits or linked work items, and another to generate API documentation from XML comments or similar metadata. Azure DevOps supports these through Marketplace extensions (such as generating release notes) and tasks that publish artifacts (such as XML files produced by 'dotnet build'). These artifacts can then be made available to stakeholders through the Releases section or other distribution methods. Refer to official Azure DevOps documentation on building, publishing artifacts, and using Marketplace extensions for best practices in automating release documentation.
- A. Correct.
Option A is correct: Generating release notes often involves parsing commits and work items linked to the builds or pull requests. Marketplace extensions (like 'Generate Release Notes (Crossplatform)') or custom scripts can be integrated into your pipeline to automate this process, creating clear and structured output for stakeholders.
- B. Correct.
Option B is correct: .NET Core can generate XML documentation based on code comments when 'dotnet build' is run with the proper configuration in the .csproj. Once generated, you'll need to publish these artifacts (e.g., .xml files) using a Publish Build or Publish Pipeline Artifact task so they are accessible to stakeholders. Optionally, you could further process them with tools like DocFX, but publishing the XML is the first step for API documentation.
- C. Incorrect.
Option C is incorrect: Simply attaching the .csproj files to the release pipeline does not automatically provide human-readable documentation or release notes. Stakeholders would have to rebuild or parse them themselves, which is not a best practice or a meaningful automation strategy.
- D. Incorrect.
Option D is incorrect: While it might seem convenient to generate release notes during integration tests, this blurs the separation of concerns. Release notes should be generated as part of a dedicated build or release step rather than within test tasks, which typically validate code functionality rather than produce documentation.