21

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?

  • 1
    Josh Kaplans DX talk on DF17 covers a few of the topics: youtube.com/watch?v=UaPPhFWHBQ0 e.g. you can go back! – Robert Sösemann Nov 15 '17 at 20:40
  • 1
    I'll be interested on how they are going to make the transition seamless for those of us that already have extension packages while being able to not affect current installations....Given the current multiple namespaces – Eric Nov 20 '17 at 6:13
12
+50

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...

| improve this answer | |
  • Great answer and up-to-date insights. Would you mind adding some references to #DF17 videos or a bullet list of what you heard where and by whom? – Robert Sösemann Nov 21 '17 at 11:53
  • 1
    Added links to the two sessions, which now have videos in the session feed at least, and links to the profiles of the SFDC folks who presented and who I talked to afterwards. – BritishBoyinDC Nov 21 '17 at 13:04
  • 1
    If you now also add a Management Summary/TL;DR that answers the question : Should ISVs already use DX and if not why? you get my bounty. – Robert Sösemann Nov 21 '17 at 13:22
  • 1
    Added quick summary and a link to another packaging session – BritishBoyinDC Nov 22 '17 at 10:01
  • The #DF17 session "Managed Packages in Salesforce DX and Feature Management" (success.salesforce.com/Sessions?eventId=a1Q3A00000stRRuUAM#/…) also has some great infos on that topic. Especially the Q&A. – Robert Sösemann Nov 30 '17 at 10:45
1

There are two Dreamforce '17 session recording that perfectly answer most of the questions. The main line is that Salesforce knows about the fears and is currently working on making the switch very easy. So watch:

1) Salesforce DX Packaging for AppExchange Partners

  • Seamless 1-to-1 migration in a phased approach with being totally transparent from a customer standpoint. (from minute 13)
  • Breaking down a package into smaller one
  • Consolidating multiple existing packages ino a single one

2) The above mentioned Demystifying Salesforce DX for ISVs

  • ISV NimbleUser giving proof that DX can be even used now
| improve this answer | |
  • 1
    I feel like I hear everyone saying you need break down packages/code into smaller modules, but have seen very few concrete examples - they are always seem a big vague on the details ("maybe a schema module, or an standalone app" - have you seen any good posts about approaches to breaking down a package or big org? – BritishBoyinDC Nov 30 '17 at 18:28
  • I know that every good architecture is based on breaking down a system into independent components that can be maintained and extended separated from each other. Like Java JARs, C++ DLLs or OSGI bundles. In that sense Salesforce DX is an architectural breakthrough. – Robert Sösemann Nov 30 '17 at 23:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.