Document how to start fresh

[bars0um]

It may take a few turns for us to come up with the best setup for a specific team in terms of the bug template and the kind of information they would like in their tickets.

Is there an easy method to clean up and re-start the process with FoD-Azure?

At present I'm having to do the following:

• Create a new release on FoD
• Delete the old one with the associated bug links
• Update release id
• Rerun the utility and check again if are happy with the grouping/layout and so on

Thanks!

[rsenden]

Short version: The approach you are currently using is probably the cleanest approach.

Long version: The utility can store bug links in FoD either as native FoD bug links, or in FoD issue comments. Depending on which approach you are using:

• Native bug links: I would need to check with the FoD team whether FoD provides any functionality for removing all existing bug links from a release, but I doubt that this functionality exists. In SSC you could simply set the bug tracker configuration to 'None' in order to clear bug links, but I don't think this will work for FoD (you may want to double-check though). Even if that approach would work, the difficulty is that the bug tracker is configured at application level in FoD, so all bug links in all releases in that application would be cleared.

• Bug links in comments: I don't think you can delete comments in FoD, and even if you could, it would be a tedious job to manually delete the bug link comment for every individual vulnerability. The utility does allow you though to configure the target name used in the comments through the commentTargetName property. Changes to this property will result in all issues being re-submitted to the target system.

So, while testing different layouts you could do the following:

• Temporarily configure the utility to store bug links as comments:
  • Set addNativeBugLink property to false
  • Set addBugDataAsComment property to true
• Before every test run, change the commentTargetName to a different value, for example ADO-test1, ADO-test2, ...

You could even keep a copy of the configuration file for each test run around, allowing you to easily switch back and forth between your different test configurations. This could for example be useful if you wish to test bug state management with different configurations:

• Create configuration file test1.xml with commentTargetName set to test1
• Run the utility with test1.xml
• Copy test1.xml to test2.xml
• Modify test2.xml to your needs, and update commentTargetName to test2
• Run the utility with test2.xml
• Make some changes on the FoD side (new scan with some vulnerabilities introduced/remediated, suppress/unsuppress some issues, ...)
• Run the utility with test1.xml
• Run the utility with test2.xml

Needless to say, for every commentTargetName value, a new comment will be added to every submitted vulnerability. You may want to clean this up once you're done testing, using your original approach of deleting and recreating the application release.

[bars0um]

@rsenden Thanks for your response!

I believe I've tried clearing the bug tracker setting on FoD but the tracker was still trying to synchronize bugs.

Perhaps an API call to just set the bug-links to blank for a release would work?