Update Application Acces group task not available in deployment manager
Hi,
We are currently testing the business change pipeline in our customer decision hub setup. From our deployment manager setup we would like to update some (custom) accesgroups automatically. From the task list we are expecting the task in the following link.
https://community.pega.com/knowledgebase/articles/devops/85/update-application-access-group
However this task is not available in our deployment manager (5.2.1) How should we update our acces groups ?
Update application on access group VERSION:
8.5
Update access groups with new application version.
This task is available in Merge, Development and Business change pipelines.
Pegasystems Inc.
IN
Hi @JSPEKSCH,
This task is no longer available in 5.2 and the documentation is undergoing some updates to reflect the latest state of play,but you can create a custom task which can update your custom acces groups and add that task in your pipeline by following this document "https://community.pega.com/knowledgebase/articles/devops/85/creating-and-using-custom-tasks".
Thanks,
Nikitha
Updated: 16 Jun 2021 6:07 EDT
Achmea
NL
@yeran Hi Yeran, thnx for your awnser. But I do have another question concering the 'normal' way of working of a Business Change Pipeline with regards to updating accesgroups.
https://community.pega.com/knowledgebase/articles/devops/85/creating-business-change-pipeline
In the BCH pipeline template on the dev stage/environment a new application version is created of the highest "Enterprise" application. In our case this is the application on which the RMO-Application is build. For example:
TESTAPPRMO is build on TESTAPP
In the Dev stage: For the TESTAPP the version is incremented to for example01-01-03 by the task "Create application version". TESTAPPRMO stays on 01-01-01.
In the stage/environment where you accept the Revision changes we see behaviour that the Deployement Manager updates all the Enterprise Application accesgroups to the latest version.
That is correct.
So TESTAPP accesgroups point to 01-01-03. But how do we correct the other stages for example Dev? Here the accesgroup of TESTAPP would still point to 01-01-02.
Should we run a seperate Pipeline with update accesgroups?
Are we doing something wrong?
Kind regards.
Pegasystems Inc.
IN
Hi @JSPEKSCH,
When you say "in a environment access group are pointing to latest application", is it the Production environment? You can verify the environment template by opening the pipeline and clicking on the intended environment stage, It will show the environment template value. If the value is BusinessChange_Production then that environment will have all the tasks intended for a Production environment.
And yes, only in the Production environment, once you 'Activate to all', the access group will be pointing to latest application version. In other systems we are not updating the enterprise access groups to point to latest application version. Only revision users will be able to see the latest changes via the overlay application.
Thanks,
Nikitha
Achmea
NL
Hi Nikitha. I understand the BusinessChange_Production will activiate the revision and update the accesgroup for that production stage.
If we would like to schedule a campaign or trigger a service for testing purposes in a stage before the production environment. It is mandatory to first update the PegaNBAM:Agents / Services acces group to the latest application version.
Should we do this through a seperate pipeline?
It would be nice if after the revision deploy all enviroments are updated :)
Kind regars
Pegasystems Inc.
GB
Good to hear from you. I don't want to distract from your conversations with Nikitha but a couple of points to add and an offer :-)
The business change pipeline is very new. We decided to build an integration with Deployment Manager due to Pega's (and the industry's) increasing focus on DevOps. We knew it was going to be something our customers would expect so wanted to implement the MLP version to get initial usage feedback.
We have tried to be opinionated and explicit about how we expect the pipeline to be used and do not expect as much configuration as you would with a deployment pipeline. That said we know there are things we want to improve.
- With regard to Test and Activate capability. This is only available in the designated production environment. We did not see the need to implement in non-prod environments.
- After revision deployment, all envs are updated. The pipeline works slightly differently. We merge the revision package to the SOR (most likely the Dev environment) and then deploy the new app version through environments to production. So the environment will all be automatically updated.
- We mandate 1 business change pipeline, you do not want more than 1 in progress. Will cause you a lot of complications with pipeline dependencies etc.
Good to hear from you. I don't want to distract from your conversations with Nikitha but a couple of points to add and an offer :-)
The business change pipeline is very new. We decided to build an integration with Deployment Manager due to Pega's (and the industry's) increasing focus on DevOps. We knew it was going to be something our customers would expect so wanted to implement the MLP version to get initial usage feedback.
We have tried to be opinionated and explicit about how we expect the pipeline to be used and do not expect as much configuration as you would with a deployment pipeline. That said we know there are things we want to improve.
- With regard to Test and Activate capability. This is only available in the designated production environment. We did not see the need to implement in non-prod environments.
- After revision deployment, all envs are updated. The pipeline works slightly differently. We merge the revision package to the SOR (most likely the Dev environment) and then deploy the new app version through environments to production. So the environment will all be automatically updated.
- We mandate 1 business change pipeline, you do not want more than 1 in progress. Will cause you a lot of complications with pipeline dependencies etc.
Now the offer. We would love to have Achmea as an adoption partner. This would give Achmea the opportunity to influence the business change pipeline roadmap and give Pega the opportunity to get valuable feedback.
If this is something of interest to you, please reach out to me direct. I can organise an initial meeting where we can catch up on where Achmea are up to and how we can work together.
Cheers, Alex