2

What are good ways to migrate solutions from one environment to another? Packages? Is gitHub a solution and if yes, why ?

Improve this question

1 Answer 1

Reset to default
6

There are two basic frameworks elucidated on Trailhead for how to do development across orgs: the Org Model and the Package Model. Both models should use source control (such as Git and GitHub) as a source of truth. To very broadly summarize, the former organizes development around the metadata for a whole org, and the latter around modular packages that can be composed into a complete business solution.

That two-fold solution is in contrast to some traditional methods of organizing and deploying metadata between environments. The classic "Sandbox and Changeset Model", where one or more Salesforce orgs serve as the source of truth and customizations are migrated between orgs using Change Sets, should not be used for new development today. It scales poorly, demands a high degree of manual and error-prone work from deployment managers, doesn't use source control, and doesn't offer any of the new functionality provided by tools like Unlocked Packages. That said, existing practices that are built around the sandbox and changeset model can and should adopt source control as an add-on to their existing practices, and may find commercial CI/CD tools valuable in bridging that gap.

To more directly answer the question, Git is a repository and source of truth, but is not a deployment tool. You can use Salesforce DX or any Metadata API client as the deployment bridge between your source control repository and your Salesforce orgs if you're practicing the org development model.

Unmanaged Packages (as distinct from Unlocked Packages) do almost nothing as a tool. They're little more than a name for a set of metadata components, the in-org representation of a package.xml. Unmanaged Packages aren't really versioned artifacts in the way that Managed and Unlocked Packages, and don't do anything for you about dependency management or upgrade behavior. There's essentially no benefit to adopting them as a tool

If you want to develop your Salesforce org based on a package model, evaluate whether Unlocked Packages or Managed Packages better suit your needs. If you manage one Salesforce org, it's likely that Unlocked Packages are what you need; if you manage authoritative customizations for a collection of Salesforce orgs, you may want to consider either Unlocked or Managed Packages.

Improve this answer
3
  • Also, 2GP can now be listed as AppExchange apps, making Managed Packages truly obsolete as a packaging model. You still need a dedicated developer org to reserve the namespace, but you don't use it for packaging any longer. This also allows developers to post many apps under a single namespace, which is really beneficial. Maybe you should mention that Managed Packages are really only meant for ISVs?
    – sfdcfox
    Mar 23, 2020 at 14:52
  • I think there are still use cases, albeit a small and rapidly shrinking number, for 1GP Managed Packages outside the ISV ecosystem - primarily groups that act as an internal ISV for a large conglomeration of Salesforce orgs. In particular, Managed 2GPs don't support push upgrades yet, and I believe there are still small differences in component manageability between 1GMP and 2GMP (although that gap is closing).
    – David Reed ♦
    Mar 23, 2020 at 15:06
  • 1
    Yeah, it's like how LWC is poised to replace Aura. There are still gaps, but they're closing every day. I agree that saying 1GMP is 100% obsolete is a bit forward-looking, but I think that for "most" orgs, 2GMP is a better deal than trying to learn 1GMP only to have to migrate later. At the very least, it's worth researching rather than ignoring outright.
    – sfdcfox
    Mar 23, 2020 at 15:10

You must log in to answer this question.

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