0

We have a consultancy that may or may not update an org dependent unlocked managed package as well as a managed package. They made customizations on top of the package and we are trying to get all of the work into our pipeline. It has been recommended that we

  1. install managed package in source/target
  2. deploy unlocked manage package via our Copado pipeline
  3. deploy dependent customizations on top of managed package

Currently we are excluding managed package from .gitignore but since it’s being installed in each org don’t see the issue.

Problem is. We are not able to select the Unlocked Managed package as a whole for deployment so are creating a package by selecting individual components via our Copado UI.

All components are added, but there are some failing test classes

  1. do those need to be modified?
  2. should we be deploying the unlocked managed package through Copado and tracking it in our repo in the first place as after reading a bit it seems test coverage in unlocked managed packages can be limited to the package itself?
Improve this question
4
  • I'm guessing by "org dependent unlocked managed package" and "unlocked manage package" you mean "org dependent unlocked package" and "unlocked package" respectively. You should simply install the org dependent unlocked package directly in the target org. If you have modified any of the unlocked package metadata you will then want to add these to a change set that you promote to the target org.
    – Phil W
    Commented Nov 3, 2023 at 12:45
  • Hey there @PhilW. Thanks for clarifying I meant “org dependent unlocked package” and “managed packaged”. Currently architects say it would be best to deploy all changes for “org dependent unlocked package” due to potential modifications for multiple phases of the project but I am concerned this is not best practice or the deployment will fail when it finally is being validated for promotion against prod.
    – coinjar
    Commented Nov 6, 2023 at 12:53
  • I believe you should first install the unlocked package then promote any "local changes" for it.
    – Phil W
    Commented Nov 6, 2023 at 12:57
  • (If you manage all the metadata, there should be no local changes for the unlocked package - all changes should be applied to that unlocked package ASAP. It gets messy when in a "collaborative" org where different actors are making "uncontrolled changes". Fundamentally the key is to get all parties to apply best practice and use version control and packaging.)
    – Phil W
    Commented Nov 6, 2023 at 12:59

0

Reset to default

You must log in to answer this question.