Pipeline migration

1. Import the Deployment Manager 5.x RAPs and restart the server.
2. Log in to Deployment Manager using the DMReleaseAdmin operator.
3. In the lower-left corner of the application, click the Operator icon, and then select Switch to Dev Studio.
4. Open the operator record, and then update the default access group to SuperAdmin.
5. Log out of the application, and then log in as the DMReleaseAdmin operator.
6. On the Deployment Manager banner, click the info icon.
7. Click Migration assistant.
8. In the Pipeline Migration section, select the pipelines that you want to migrate.
   Note: Migrate dependent pipelines first. View dependencies link provides details of all pipeline dependencies.

9. Click Migrate.
10. Confirm the pipeline migration by clicking Submit.
11. When the migration is complete, the pipelines indicate the status of their migration:

    Success

    Indicates that the migration of the pipeline is successful. Expanding the row provides additional details on the pipeline migration.

    Fail

    Indicates that the creation of pipeline failed. Click View log to understand the cause of the failure.

    Not migrated

    Indicates that the pipeline is not migrated and the user can start the migration as required.

12. If pipeline migration fails due to a loading error, ensure that the open ruleset in which pipeline case types are stored is present in the Deployment Manager 5.x application stack.

Migrating the operator

After a successful upgrade to the 5.x version, you can upgrade operators from the Migration assistant page. Operator migration migrates the existing roles to associate them with selected operators.

1. On the Deployment Manager banner, click the info icon.
2. Click Migration assistant.
3. In the Operator Migration section, select the operators that you want to migrate.
4. Click Migrate.
5. Confirm the operator migration by clicking Submit.
6. The operators table provides the status of operator migration:

   Success

   Indicates that the selected operator migration succeeded.

   Fail

   Indicates that either role or operator migration failed. For more information, you can click View upgrade logs on the Migration assistant page.

   Not migrated

   Indicates that the operator is not migrated and the user can start the migration as required.

   Note: Operators that you migrate manually to version 5.x are not tracked by the operator migration feature.

Updating access group

If you are upgrading to version 5.x, ensure the PegaDevOpsFoundation:Administrators access group is updated to point to version 5 of the PegaDevOpsFoundation application. Perform this update for all candidates that are upgraded to PegaDevOpsFoundation 5.x.

Rolling back to Deployment Manager 4.x from 5.x

After a successful upgrade to the 5.x version, you can rollback your migration to a 4.x version if you choose.

1. Ensure the candidate application points to a PDF 4 application and the PegaDevOpsFoundation:Administrators access group is pointed back to application PegaDevOpsFoundation 4.
2. Change DMReleaseAdmin AccessGroup to PegaDeploymentManager:Administrator. This points your PegaDeploymentManager application to 4.x.
3. If pipelines have already been migrated:
   • Log in to Deployment Manager 4.x portal. Go to the archived landing page, and manually activate the required pipelines.
   • Run the DeleteCreatedPipelines activity to clean up all pipelines created as part of the DM 5.x migration. This will ensure a smooth migration should you choose to return to 5.x.
4. If operators were migrated to 5.x, you can roll them back using the UpdateDMOperatorsTo4x activity with parameter ALL.

Frequently asked questions (FAQ)

1. Will custom tasks automatically migrate to Deployment Manager 5.x?
   • Custom tasks are not currently supported in Deployment Manager 5.1. Custom tasks are removed from the pipeline during migration, and the pipeline is disabled by default in Deployment Manager 5.1.x.
2. Why are pipelines disabled after migration to Deployment Manager 5.x?
   • There are a few possible reasons that pipelines may be disabled after migration.
     • If the original pipeline was disabled, it remains disabled after being migrated.
     • Pipeline included custom tasks. Custom tasks are not supported in Deployment Manager 5.x.
3. Why are pipelines archived after migration to Deployment Manager 5.x?
   • To ensure no deployments are triggered in Deployment Manager 4.x after migration to 5.x. Therefore:
     • If the original pipeline was in an archived state, it remains archived post-migration.
     • If the original pipeline was in an active state, it becomes archived post-migration.
4. What happens to original pipelines after migration?
   • Deployment Manager aborts any active deployments and archives the pipeline before migration.
5. Why does Deployment Manager create two new pipelines after the 5.x migration if merge is enabled in the original pipeline?
   • Deployment Manager 5.x and later support template-based pipeline creation to define a structured release process. The template-based model splits merge pipelines and deployment pipelines into two separate entities, differing from the combined model in previous releases. If you are migrating a pipeline with merge enabled, this is split into two pipelines to align with the new template-based model.
6. Is deployment history migrated to Deployment Manager 5.x?
   • Deployment history is not migrated. Only the latest and dependent artifacts are migrated. This data is still accessible by switching the Deployment Manager portal to the corresponding version of historical data.
7. Why is my pipeline migration is failing with a Failed to load pipeline from DM 4.x error?
   • This error can occur if pipeline case types are not present in the PipelineData ruleset. Include the custom ruleset and retry migration.
8. When I try to save a newly created merge pipeline from the 5.1 migration, the save fails with an error stating a task could not be found.
   • Pipelines created from the migration process do not enforce environment templates. However, Deployment Manager portal enforces the recommended and mandatory tasks on an environment template selected for the stage. Hence, if any edits are required on the pipeline after the merge, you must abide to the environment template tasks. For more information, see Pipeline templates.