I have a Salesforce org with a nontrivial amount of Apex code and custom objects. We aren't using a VCS for our metadata yet and we're in "sandbox hell" even with only a few developers writing Apex. We've been looking forward to DX but we're having a bit of trouble getting started.
In particular, the Adopting Salesforce DX webinar published in August advocates "breaking up the happy soup" - i.e. modularizing an org's code and other metadata into separate projects, and hence separate VCS repositories. They recommend using unmanaged packages as the temporary mechanism to extract the needed pieces from the source org. This sounds good in theory, but I'm getting a bit stuck on the mechanics of how to create unmanaged packages when there are dependencies across packages. Obviously I don't want to have duplicated components in the packages/VCS repos. I want to be able to make one package depend on another package. How do I do that?
- I create Package 1 with some base components A, B, and C.
- I then want to create Package 2 with components D, E, and F. D depends on A, so the Salesforce Package Manager automatically adds A to Package 2.
I don't want A to be pulled into Package 2 - I don't want any metadata to be duplicated between my two packages/repos. How do I fix this? Do I need to use managed packages and extension packages (and hence dev edition orgs) as part of this process? Should I just manually doctor up the source from Package 2 after I extract it from my sandbox using the Metadata API to remove the duplicated pieces, before I commit the code to git?
If there are any examples out there that illustrate this process using something more complex than the Dreamhouse app (e.g. showing multiple repos with dependencies), I'd love some pointers!