Posted it here as well to get more opinions.
# suitescript
t
Posted it here as well to get more opinions.
a
SDF is not monolithic repo friendly without significant customization to assist with deployment. If you move away from a monolithic repo structure SDF works very well, is not perfect but it works well.
t
I have branches for every other type of object, list, entity fields, transaction forms, I am doing it very structured, but still it is a pain, there are still dependencies that pop up, where I have to resolve those, with time and experience it gets easier for sure, but still I don’t see it comparable to bundles. It has been great help with development though. I am concerned on migration part. I am getting the full environment migration projects.
Screenshot 2026-03-25 at 7.57.40 PM.png
Also, I think it is not pocket friendly for client as well. It can take from 50 to 100+ hrs depending on the scale of project.
a
You could have cross dependencies or even circular dependencies, a monolithic repo would make that hard to maintain no matter how you structure it (at least in my experience). I switched to per project / business problem / folder structure 8 years ago and I don't even entertain the idea of a monolithic repo for NetSuite development.
t
That sounds good, per business problem. Maybe you can do that. But we are using a Migration Tracker, where all the FCs and devs add there customizations and dependencies. So I cannot make the process change. I or devs like me get the final sheet, that these are 1000 objects deploy these. That is my pain, if there objects that are missing from the sheet, which happens frequently, I again have to go back and forth on branches to add, objects and resolve dependencies. I am currently using SDF Suitecloud IDE plugin for VS code, do you think CLI is better for this case? My process includes this 1. Get the migration tracker, add columns for SDF fetch and prod deplyment for tracking. 2. Create a github repo, and add branches, 3. In the individual branches, fetch the objects, mark back on tracker, sometimes vlookups are needed if the list is bigger. 4. Add dependencies on each braches. 5. Start prod deployment per branch(Object type) in order, not always but it matters. 6. Put on hold, if there are objects which can’t be deployed now because of errors or dependencies. 7. Continue with all branches, deployment and then switch back and forth in branches to resolve dependencies. (add/deploy new objects) 8. Mark back in sheet for everything deployed, or issues. Where can I improve the process? Have you done any full project migrations?
a
I have to assume you're just frustrated about your current situation and that's coloring your opinion - SDF isn't prefect by any means - but it is 100% objectively better than bundles.
💯 2
e
IIRC, with SDF you get ACCOUNT_SPECIFIC_VALUE, with bundles you get blank and need to adjust your workflows. Both suck. If you're using SDF with a pipeline you can leverage git diff and only deploy objects that change. This will cut your deployment time down significantly and SDF wins here.
t
I understand that you guys are doing pipelines, however that is the not the case for me. It is more of waterfall for me. the 2nd last step. So it’s a problem for me. I’ll look to build any automations around this. Q: Is CLI better than IDE plugin?