Pega Deployment Manager Access Group doesnot exist in QA because it's name has been changed
Hi, we have this senario.
the Application XY-010101 has been deployed on QA System via the Pipeline XY-010101 with this AccessGroup: XY:Administrators, it pointes
And now we will use a dedicated Access Group for Deployment Manager, i.e. XY:DeploymentManager, it pointes also XY-010101, then we updated the Pipeline XY-010101 with this new access Group, but during diagnose we got this error: the Access Group does not exist on QA.
i understood this error, the access Group does not exist on QA. But i wonder, why will DM force this Access Group be avaiable on all candidate systems?
And if we deploy a brand-new application, the access group is also not on QA. But in this case the diagnose is successful.
Anyway, does some have an idea, how could we solve this issue.
Pegasystems Inc.
IN
Hi @LiL95470,
Diagnostics will skip access group check if the application configured in the pipeline does not exist in target environment.For example if its first time deployment, QA will not have application and acces group check will get skipped. So you will get diagnostics success.
If application is already deployed and present in target environment ex:QA then diagnostcs will try to check if access group configured in the pipeline exists in the environment. This is because Deployment Manager when runs most of the tasks(except deploy task), switches to the context of access group configured in pipeline and runs the task in that application context for ex: guardrail compliance check task. If the access group does not exist then tasks will fail.
So I would recommend you to first deploy your new access group XY:DeploymentManager in all candidate environments and then configure the same in the pipeline so that both diagnostics and task which expects access group to be present also will not fail in case of not brand new deployment.
W&W
DE
thank you very much for your answer. we could deploy the new access group to all candidate systems to solve this problem now we have. But it is only a workaround, not a right solution
From my point of view the Logic of DM in this case is too strange.
I know, the access group will be changed in runtime to run most of the tasks(except the deploy task). But if a new accessgoup has been specified in the pipeline, Diagnostics should check if the access group is included in the deployment package instead of checking if it is exisiting on target system. Because first of all, the package will be deployed on the target system. Once the new AccessGroup has been deployed on the target system, it is exisiting there. Those tasks will be run after the deployment.
Best Regards Li