The more I am doing SDF deployment, I am getting against it, It takes so much time, Tracker and then fetching dependencies, and specially forms and workflows are real pain. Yesterday, I spent significant time deploying wfs, and then there were some big workflows which would take atleast an 30-45 minutes for each, for account specific values, and other dependencies, then another guy used suitebundles to deploy them all in like in an hour. Question is: Is SDF really worth it for migration? from SBX to PROD, especially for big projects, implementations or phased go live? I still feel bundles are less painful and more time efficient.

I'd say yes still worth it. Bundle works better in some cases but you can't rely on them long term. You also forfeit versioning as code. It's a pita but fighting account specific values beats manually recreating states and transitions any day!

Thank you @SimonC, have you done any full migration/deployments? Like all the objects, for a new implementations, How do you manage repeated effort?

What sort of a migration are you talking about? And what are your main pain points?

@tuli I'd be interested to know how you got workflows to deploy using SDF

So, 1. I pick the ones first that are shorter in file size, you can see the map in right in VS Code. 2. I check for any account specific value, and then go back to sbx, pick the text value of that record(location,class,subsidiary or department majorly) and then find that value in PROD, get the internal id of that from PROD and replace account specific values in workflow xml. 3. add dependencies, and then validate, resolve for any other dependencies, and then deploy. Also gets harder if there is custom record, with different script ids, or if a wf state/transition have script ids have more that 42 chars.

yep I saw it. But that's why I asked, if the migration you refer to is a repeatable 1000+ object deployment it's likely going to be very difficult to automate fully. What are your specific pain points?

My pain points are, 1. Fetching objects from sheet and then doing a lookup and marking back there for the once that are fetched and if not available. I am thinking for a google sheet integration with my local node server, I’ll write a script and then it will pull script id from there and import items. 2. I want to run validate and deploy command together. in IDE every command is a two step process. I am thinking to use CLI here. the output of validate command, it should filter out the dependencies need and add it manifest. run command again to verify. and then run deploy. 3. Then again update on tracker, that this object is deployed. It is hard, but I have some ideas, I’ll do it sooner or later. I will also include one script for removing unused tags, for example, transaction forms, there are lot of roles attached, but all of them are preferred F, so it makes no sense to wait for those dependencies, I basically remove the roles which have preferred F, less dependencies.

If you are against the SDF deployment, you are doing something (read: everything) wrong, IMO. You probably need to change the deployment process at your company.

@NickSuite I am not against it, I love it for development or small deployments, but it has been hectic on deployment projects that ranges from 700-1000+ objects.

Your approach sounds good Som but I'm afraid you will likely run into issues trying to deploy this bundle using SDF in one gulp. It will likely timeout

@tuli we’re dealing with the same thing. I do almost the exact some thing your do in CI. 1. I create certificates that are in my secret store 2. I set up M2M credentials in netsuite for each client we have (with cert from step 1) 3. CI server installs the suitecloud CLI (and node and java along with everything else we need to build) 4. CI Server authenticates to all accounts we need to deploy to 5. CI Server run a build script that converts our Account Customization packages into a SuiteApp 6. CI Server runs

suitecloud project:deploy

on the new SuiteApp There is a ‘build’ step we use for all of our other software that my CI server does

suitecloud project:validate

on (pre-deployment) for whatever certanty I can get that my code is going to be able to get deployed. I’ve been on calls with Netsuite asking about the perf of SDF and we spend about 30 min a deployment waiting on

suitecloud project:deploy

. Our PR process is like an hour bc I have a netsuite account that I use for integration testing before the PR can be approved. It’s a nightmare for development momentum- you get some work done then you debate whether or not you want to risk changing contexts before you have to fix some issue that might have cropped up with your prior deployment.