https://netsuiteprofessionals.com logo
Join Slack
Powered by
so like 1 client can be 1 project
# sdf
c
so like 1 client can be 1 project
a
Yep, that's how I would do it
s
the problem is 
deploy
deploys the entire thing, which is almost never desirable?
a
What's the problem of that? Sorry, I dont get it
If you have a custom field already deployed, it's not going to change anything unless there's a change in the Custom field definition
What's the problem of deplying "the entire thing"?
s
I may have changed a file(s) on disk for whatever reason.... I need to be able to control exactly what goes into a deployment, and that definition may not be 'everything that's changed'
c
this is also my concern
but i guess the xml is what would dictate that
s
my initial thoughts are to dynamically generate an entire SDF project for individual scripts, as that is often the granularity we expect to deploy. It is most common (for us) that a developer is working on a single script at a time, and in no way wants to risk uploading/changing anything outside the scope of that one script in the course of their dev/deploy/debug cycle.
c
yes... 100% agree
thats where im thinking sdf isn't a good fit for that type of development
but i could also be very wrong
s
well, in traditional development I'm a big fan of 'deploy everything' so that you're sure every bit is exactly what came out of your build system.
However, NS is a shared environment, with (sometimes) many people making various changes outside your build system...
c
right but client work isn't traditional development.. if i was building an app.. sure why not.. but people freak out constantly if modified dates change and you reupload stuff
whether the freak out is warranted is debatable (IMO no) but it happens
s
I agree with @creece
Sorry to have two similar threads going on this general topic
c
yeah they are basically the same now we can keep this one
s
@Albert Margarit (NS Eng Lead) the most common dev flow I see is 1. developer uploads initial script 2. creates script record and deployment (one time), 3. iterates on the script 1000 times, re-uploading to file cabinet and testing.
c
or what about a scenario where say stalbert and I are working on client code.. we are in the same sdf project.. if we deploy its gonna be crazy as i may be working on one part and hes on another
s
the real win is making step 3 easy during development time, and step 2 easy only at deployment-to-another-account time.
yes - @creece hits on another way that files outside my immediate concern would be updated and perhaps accidentally deployed.
c
that could happen with any level of development (X devs on the same script constantly overwriting each other) but if you can only deploy everything, you have no control over it w/ sdf
a
or what about a scenario where say stalbert and I are working on client code.. we are in the same sdf project.. if we deploy its gonna be crazy as i may be working on one part and hes on another -> how is this a problem of SDF? How do you solve this today without SDF?
s
if we are not working on the same script file, I can deploy my file and he can deploy his independently just by uploading files to the File Cabinet
c
SDF deploys the entire thing to the file cabinet. I solve it in "non-sdf dev" by not uploading the entire project and script files to the file cabinet. I work on only my stuff and upload only my stuff.
a
SDF is not just about deploying, it's about keeping your customizations in code. You can upload a single file through the tools if that's what you need. If you want to create an object in the account and still you don't want to deploy the whole project, you can create the object manually and then import that object into XML into the project so then that's transformed into code and you can track it in your source control
Multiple devs working in the same account is a challenge with or without SDF. It will require devs to have an agreed process to avoid steping into each other toes. With SDF, at least you have a code representation of the account customizations so you can keep track of which customizations you created in the customer account
c
since you can upload a single file it seems to solve the issue... i'd like to see a manual 1 off object customization so i don't HAVE to manually create anything though too
i've never used it so i could just be totally wrong here
(never used it successfully)
a
Are you coming to SuiteWorld this year? We can play with it together 🙂
c
Yes, i'll be there and i'll gladly do that
s
having a generic 'upload` command that could handle files and/or single customizations (e.g. a custom record and/or field(s)) may be useful
to be honest, I'd prefer the 
uploadfiles
to allow me to specify a 
from
folder and 
to
folder, so I could upload any file from my filesystem to any folder in the file cabinet.
c
that would be nice.. a single file upload or a way to pick and chose from the xml what you want
Open in Slack
PreviousNext
Powered by