Friction-free process to switch to SalesforceDX with existing managed package

Dreamforce ’17 made it crystal clear. Salesforce DX is ready for prime time. With Second-Generating Packaging SGP even for ISVs.

Salesforce DX is awesome, nonetheless we fear that getting started with DX will introduce more friction and problems we can handle for existing apps. Thousands of paying users expect us to be agile with patches and new releases.

  1. What if we get stuck and can’t release to our customers in the meantime? There seems to be no going back or converting to DX in steps.
  2. What happens to the namespace? Do we keep them? Should we restructure our apps using Packaging 2.0 feature to live in the same context?
  3. Will I destroy my packaging org when I push the DX-converted metadata into it? Will I be able to revert that when something goes wrong?

There is a ton of great content out there to learn DX but not enough material (e.g. Trailhead) for ISVs that outline the full process of migrating existing apps to DX.

So, how did you do it? What roadblocks did you experience? What else should we know?

Answer

Summary The next generation of packaging is still very much a work in progress. The core focus is embracing the source control driven
approach of DX into how we develop and distribute packages. The
current road map shows that the first GA release is until Summer 2018:
enter image description here

Moreover, this schedule is really about migrating existing packages to
use the DX format. The more difficult process of consolidating
packages to take advantage of the new features that DX promises is
still being discussed. So my approach for 2018 is to look at migrating
some simple, standalone packages to DX to test out the new process and
provide feedback, and look to incorporate some of the CI/Test
capabilities of DX into my development process.

Discussion
I went to the DX Packaging/Packaging 2.0 session in the partner lodge, and my takeaways were this…

Firstly, they can’t decide on the name, though I think DX Packaging will eventually win out, but feels like that is symptomatic of the current state of DX Packaging…very much a work in progress

I might start the process with a free package I support for NPOs, but I am going to wait until next DF 18 to see where they are in the process before I start moving any commercial packages – it is too much of a moving target right now.

Most sessions I saw about packaging and DX admitted they weren’t really using DX for development – more for CI and Testing (e.g. this session had some good examples). The ability to create multiple scratch orgs with different setups, configurations and test data was very appealing. If you have that one customer with x feature enabled, you can easily test that configuration with the right test data.

There was a lot of talk at this session about migrating packages – but that is specifically referring to migrating packages from the current Packaging Org approach to the new DX Source Control approach. It sounds like that by mid 2018, you will be able to convert a package to the DX format, build it and push the upgrade into a customer’s org, and it will be invisible to the customer. But I think once you upgrade that customer, you have to keep going down the DX approach. However, it also sounds like you can/should keep building packages with the old format in parallel, and if you want to, keep customers on that format – so I guess you could have some form of pilot program from some customers that are using DX Packages.

But like you say, the bigger question for many ISVs is how to take multiple extension packages and create the single namespace that DX will provide better support for when you create different configurations of the package. This was referred to by some SFDC folks as consolidating packages, and seemed be more theory than reality. I need much more clarity about how I would consolidate my packages before I can move them to DX. I have customers with millions of records in an object that uses an extension’s namespace – very unclear how that sort of migration will be handled. I think we might see more clarity at the DX Conference in March 2018, and I am waiting for that before I start considering DX for those packages.

I also felt there was some confusion for me because DX Packaging will be available/intended for use with any org, not just for managed packages for ISVs. (see this session for overview) So larger customers might decide to create multiple small modules via DX packaging to make development and deployment easier. But although that is a good direction to be going in, I think that might lead to some confusion about what makes sense for one org vs ISV creating a package – but that might just be my lack of understanding.

I would definitely check out the partner sessions on DX Packaging – the PM and Dev Engineer who presented are very active in the success groups…but for me, I’ll try and take advantage of the CI/Testing functions of DX, and adopt a wait and see attitude for the rest…

Attribution
Source : Link , Question Author : Robert Sösemann , Answer Author : BritishBoyinDC

Leave a Comment