Pipeline step "Change control" attribute not reactive

[Bartosz Glowac1]

Hi All,

we are testing our DevOps Change Velocity implementation. I would say everything works pretty well for both Azure DevOps and GitHub Tools configured. We are getting changes created when release pipeline is triggered on ADO side, we configured auto-approval and the change gets closed automatically.

However, when we, just for tests, switched "Change control" attribute to FALSE for our pipeline step that is creating the change, the change is still being created when the release pipeline is triggered on ADO side.  And what is more interesting, at the same time the change is created, the "Change control" attribute is being  automatically set to TRUE.

I would expect that with "Change control" FALSE we should not get the change created on ServiceNow side even the release pipeline is triggered. Am I correct that this is a bug, or I do not understand something here, please correct me if I'm wrong. 

Thanks,

Bartosz

[Daxin]

In ServiceNow the pipelines and the steps are auto discovered after the tool is onboarded. 

So if the ADO release pipeline is executed and the hits the step that contains the release gates, that step will be marked as "Change Control" true in ServiceNow. 

[Bartosz Glowac1]

Hi @Daxin , thanks for your answer.

So what for the "Change Control" attribute can be used then if switching it to FALSE does not modify anything and even is set back to true with the change creation. I would like to understand toe logic behind this, thanks. 

[Bartosz Glowac1]

My recent finding is:

when you configure your pipeline on Azure DO side but it is not yet discovered on ServiceNow side for particular configured project, triggering the pipeline won't create the new change in ServiceNow.

However, once your pipeline gets discovered in the project by ServiceNow DevOps, then triggering the ADO pipeline ends with change creation in ServiceNow (even the pipeline step configuration is not configured at all and "change control" is false), and the pipeline step which created the change gets "change control" attribute set to true automatically.

So I understand the "change control" attribute rather as some information than something that would really control the behavior here. Please correct me if I'm wrong.

[Daxin]

Hi @Bartosz Glowac1 , 

The behavior could varies for different tools. For ADO the change control seems to be enabled by default, so when the pipeline reaches the release gates the step is updated with change control as true.

Each tool has their own implementation for "isChangeControlEnabledByDefault" and that seems to drive the behavior.