I'm curious what everyone else's philosophy is on SDF projects and repos structure? Do you create separate projects per transaction type? Same question for repo's. I'm having a hard time deciding when to break something out into a separate SDF project or not.

Most consulting firm teams I work with do one Project per Client, and most end user teams I work with do one monolithic project for their entire account. Back when I was doing contract dev work, I used to do a separate project per Feature, and that works great for clients with very few Features, but starts to get messy the more you add and the more interconnected the Features become.

Okay gotcha that makes sense to me. I just wasn't sure if it was cleaner to do separate projects like I have been doing. But to your point it does get a bit chaotic so I was thinking of switching away from that since we do have a lot of customizations

we start with a single SDF project - until/if a customization gets complex enough that we want it to be deployed and versioned independently. That's our logical breakpoint for using a separate SDF project(s).

Have a mono repo for the whole instance seems insane, wouldn't that take forever to deploy and validate anything?

Have a mono repo for the whole instance seems insane, wouldn't that take forever to deploy and validate anything?

For most instances, no. For Object-heavy instances, yes. But by then, almost every team I've worked on or advised has built a diff engine that only deploys the Objects which have changed. SDF already does the same for files.

I like to create separate projects/repos based on functional area. You're going to compromise a bit repeating yourself, but being able to test and deploy isolation is worth it. This further facilitates multiple developers working simultaneously, and ultimately externalizing functionality to Netsuite when decomposition of the monolith becomes the goal. Ideally I prefer projects like my scripts files : specific. The trick is to implement in such a way that you are not creating unexpected second order effects. So each project has it's own automated testing protocol, and then when you push to stage, you can run all the tests for all the projects. I typically do this using a combination of Unit and API based testing and again this requires that you approach your code with testing in mind.