3

We are in the process of writing a gitlab pipeline for our application. We have a couple of questions on Unlocked packages vs just using the metadata api and the package.xml to deploy our project.

  1. If we do go with unlocked packages, is there anyway we can have both projects installed at the same time, and eventually migrate to the unlocked package version? We don't want to destroy our application and have no way to back out.

  2. Is it proven to be faster to install an unlock package then to just use sfdx deploy commands and the package.xml? I understand that having a package application is better in terms of a self-contained artifact that can be deployed and redeployed. But it would be awesome if it were faster to install as well.

  3. We are part of a large organization (who's applications are also not packaged). And Our application depends on some of that metadata (objects and so on). Can we create an unlocked package if we have not packaged our dependencies?

1 Answer 1

5

If we do go with unlocked packages, is there anyway we can have both projects installed at the same time, and eventually migrate to the unlocked package version? We don't want to destroy our application and have no way to back out.

An unlocked package overlays the metadata it contains. If you choose to uninstall later, or remove components, you can retain that metadata without any problems. They will be marked as "deprecated" until set in another package, but that's just a UI symbol that doesn't materially affect that metadata. It's generally safe to use Unlocked Packages in that sense, but be sure to read the directions carefully.

Is it proven to be faster to install an unlock package then to just use sfdx deploy commands and the package.xml? I understand that having a package application is better in terms of a self-contained artifact that can be deployed and redeployed. But it would be awesome if it were faster to install as well.

The thing about unlocked packages is that, instead of having to run unit tests when you deploy, you instead pay that penalty when you promote the package. In other words, you will find out ahead of time if your package will be installable, rather than finding such surprises at deployment time. In addition, if you are distributing this across multiple production orgs, for whatever reason, each install won't require any unit tests, so the entire thing runs in a sliver of the time it takes to deploy. Unlocked Packages are the subscriber version of Managed Packages for ISVs, with more flexibility.

We are part of a large organization (who's applications are also not packaged). And Our application depends on some of that metadata (objects and so on). Can we create an unlocked package if we have not packaged our dependencies?

That's called an Org-Dependent Unlocked Package. However, if you do this, you lose the aforementioned benefit above. That said, you could build the dependency initially, then move things around as you need to. I guess it depends on what metadata you're concerned about, the details would be important for a final consideration.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .