function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Aaron M OlsonAaron M Olson 

Help understanding dev process with dx/vcs project structure

Hello,
 
I am working through to trying to understand dx.  I am not a sf developer but have some knowledge concerning it. 
 
We are running today bitbucket as our git repo.  We are not using it yet aside from daily backups of sorts.  Coding is being done strictly within the orgs themselves. 
 
We want to start using dx and our repo and refine our development process.  For me the part I am struggling the most with is our repo structure I think.  I have spent some time searching but have not found anything on this that helps me wrap my head around this. 
 
Our repo structure today is a listing of all metadatatypes and the files underneath it.  Class folder for example and all classes under it.  As part of dx it seems you create a project that includes the class folder and files within the force-app (I believe it was) folder.  Within this there a number of other folders and so on.  This structure is very different.  Are there folks in, or that were in a similar situation that married these 2 structures in some way and if so how did you do it? 
 
I believe we can do these conversions from one to the other and back but that sure seems like a lot of overhead. 
 
Also, I would love a better understanding of folks that are in a similar situation as we are, how did you go about starting to use dx and your vcs repo.  Another point I am struggling a bit with is so I spin up a scratch org and I am working on an issue with a few classes and workflows for example.  What is my process here in how I should work this with my git structure as I have it today?   
 
Do I create an empty project, bring in the classes I need from my repo, work them, work the workflow in the scratch org and sync that change down locally in to my project.  When ready to push back up to our vcs convert the project to the structure we have today then push?  
 
If there is a video on this or a good blog that I have overlooked I would love to read it and better understand what we need to do here.    
 
Thanks for the help.
 
Best Answer chosen by Aaron M Olson
Jayant DasJayant Das
This does sound reasonable but can't really say if it's common or not. Organizations are still adapting development methodologies around DX, but definitely there will be more adaption in coming days.

All Answers

Jayant DasJayant Das
The project structure definitely is different as you have observed. DX follows a new project structure whereas the traditional way was more aligned to Metadata format. To be able to continue using your existing repo structure for say any deployments, and use DX for your build, both needs to be transformed as and when required. That means that once the build is done using DX, you convert it to the Metadata format and similarly you can convert a Metadata to DX.

A good place to get started around knowing and how to around DX is trailhead. Look for DX modules in there which will provide you a better understanding around the overall approach, process and tools utilized.

https://trailhead.salesforce.com/en/search?keywords=salesforce+dx
Aaron M OlsonAaron M Olson
Thanks for the quick reply.  So it sounds like the method to working with DX and our repo in the metadata format is correct.  That is fine and I can start to generate steps for our devs to follow if we choose to use this format.  (i say that as we are not using our repo for dev yet today)  

We likely should starty adopting this project strucutre.  Within the vcs do you create a new repo to house these projects or do you have a repo that is a hybrid of sorts where you have your metadata format living along side the project format?   Or, since we aren't really using ours should we create a brand new repo and any dev going forward should be project based and house here?

Also, i think i read that you can not have classes across projects.  So shared classes for example should either be in a shared project (for lack of better words) used by other projects or something here.  Any thoughts on how shared classes in the project structure work?

Thanks for the trailheads.  I have made it through only a couple and will continue them.  I need to get used to all this command line stuff  
Jayant DasJayant Das
From a repo perspective, yes - you will need to have two different repos mapped to the different project structures i.e., DX and MDAPI. You will also need automated tasks to be able to convert contents as and when required. E.g., one a developer finishes their work, they commit it in the DX repo and then convert the contents in metadata format and commit it to the MDAPI repo sort of.

As for shared classes/resources, I don't really have a working example, but for shared resources, everytime you create a scratch org, you will need to make sure it's available in there so that any dependencies are resolved.
Aaron M OlsonAaron M Olson
Thanks for your patience with me and help.  

So if i am understanding you do have a method of trying to keep these two repos in sync and that is why you have this conversion mechanism for now.  If we aren't really using the mdapi repo yet it seems we should simply start adopting the dx structure?  

What does the structure of the dx repo look like with these packages?  the mdapi structure is simply a series of folders so easy to be able to identify who might be working on the same thing for example.  what I am concerned about is somehow the same class gets added to multiple projects and now that class looks very different and we have conflicts again and code being overwritten.  I need something it seems to ensure that when a class is added to one project you either need to include that in your current project (shared class i was mentioning) to utilize it or something here.  Does this make sense? 
Jayant DasJayant Das
With DX upping the game, for sure it's the way forward. However at this point of time, not sure if you can really deploy directly from DX project structure to the live sandboxes. Most likely you will need to utilize the packages (refer documentation for details). But until then, the conversion mechanism looks to be the only option.
Aaron M OlsonAaron M Olson
ah ok so that is the reason for the conversion as there isn't a good way to do this yet.  OK that makes some sense and clears things up for me.  This is probably why I haven't been able to find a whole heck of a lot about it.  

I think for us I will think about using the mdapi structure and a single repo for now.  At least until this has matured a bit more it sounds. 

To outline a bit what I am thinking so i am clear and not introducing overcomplexity.  The process could be something like this.
1. Dev creates a new branch and pulls mdapi structure local
2. Dev spins up scratch org and creates project structure and builds/fixes away
3. When complete with the bug or the project the dev will have to convert this project structure to that of mdapi
4. Once converted copy and paste in to the mdapi branch done in #1.  
5. Commit changes to remote

I think our biggest challenge now it seems is we have a discconect between the scratch org and vcs since we won't really be following this project structure.  hmpf.....

Doing the above I think will get us using vcs in addition turning on dx since we know it is going that way.  Once the project piece and how all that works is better defined we can then make the transition over to that.   

Does that sound reasonable and common would you say?   Not sure if you are a dev, but if you are does that sound like a pain in the butt?  
Jayant DasJayant Das
This does sound reasonable but can't really say if it's common or not. Organizations are still adapting development methodologies around DX, but definitely there will be more adaption in coming days.
This was selected as the best answer
Aaron M OlsonAaron M Olson
Great and agreed.  We simply need a better dev process in addition we want to use what SF is pushing and adopting to some degree.  In addition, i do not want to make things more difficult or hard to convert over to the dx structure once that occurs.  

Thanks for the help and comment.  Really appreciate it.  
Jayant DasJayant Das
Glad that we had this discussion. Wish you the best in your journey. Will also recommend to share your experiences on this journey so that others can get some help around this hot topic.