Personally I use one one repository per client project (i.e. feature), and so each repo contains a single SDF project as well.

So the same client with two features would have two separate repos?

Yep

so this has been our current strategy. the nightmare has been two fold 1) managing dependencies and 2) creating some real guidance about when a “feature” should belong to a repo that some other feature should then depend on or when it should be split off into its own repo.

What have been your biggest challenges with dependency management?

keeping them consistent

Interesting. Do you think it's really an all-or-nothing decision? It's either this way or a mono-repo?

no. I don’t think any of this is that strict

To me, there's 2 options: 1. On repo/project per "feature" 2. One repo/project per "client Breaking all of it up like this seems to be an artificial barrier for no real gain. NetSuite code isn't that re-useable so there's no real need to go nuts splitting everything out. If you need something for another project, you can take that from the other project later (unless its clearly reusable code obviously). Deploy should be smart enough to just not go crazy and start overwriting all of your stuff.

This makes sense @creece and it follows what you’ve been saying @erictgrubaugh

Thats what I'd do. You could always try it for a project and see if it works well. I wouldn't start just converting everything until you give it a go.

Yeah I think if you are going to make a transition, it doesn't necessarily have to be all at once

When you want the part 2 of this discussion (branching), let me know 😄

well versioning was actually one of the original reasons we settled on the polyrepo model.

Isn't that a nightmare? With several different repos, you'll have several different versions rather than single versions of apps. Like if your core repo is 1.0 but your extensions is is release 5 vs. just a single release with everything.

Early on it seemed like a single repo version was the more problematic choice – in hindsight, version changes don’t really matter – we don’t even have to do semantic versioning. We can leave the Changelog as documentation of what’s affected.

Especially for SDF, all of the changes are documented from commit to commit due to the objects and everything before declaratively defined.

you’re right

I've used and recommend this article for how to branch for years (no ads/popups or anything just a nice to the point blog) https://nvie.com/posts/a-successful-git-branching-model/

looks like under SDF, combining everything is actually preferable

Yes and no really for lumping it together. To erics point, you may want to do a particular feature for a client and keep that separate.

well we are in house development

So what works better for you? Keeping every "feature" separate? or just lumping it together? Combination of the 2?

well hence the dicussion. we’ve had challneges with the polyrepo approach and only reservations with the monorepo approach but no real experience with it outside of being burnt when we used SuiteBundler for deployment

I work for a company with in house development as well and have had similar discussions with co-workers. I prefer keeping the features separate and customizing the deploy.xml file so I can deploy them without overwriting anything. On the other hand, it gets annoying when I have to deploy something between the dev SB, to the QA sb, to Prod where one file might be different between all three environments because of features being developed/QA'd/Deployed

this conversation seems to support that a monorepo approach will give us more benefits than we currently have. We would still need to work through the deployment strategy (guidance on how developers should modify their

deploy.xml

files so that only the feature they’re working on is getting deployed and tested.

The concerns are certainly different when all your development goes into one account.

been using this concept. it can be a challenge having dynamic deployments, but you can also setup frequent projects using npm commands that seed your deploy.xml differently then the (bootstrap) template approach the article uses. note that this does use the gitflow @creece mentioned above, but it does so using git-flow git addons specifically.

I often take a simpler approach - monorepo, modify deploy.xml in a feature branch, then tag the repo as of that deployment when I merge it back to master. This gives the ability to recall the code and deploy.xml on any release. Just need a convention for tags to make it easy to find.

I like the modify

deploy.xml

in the feature branch. How do you account for that when it merges back to master. I assume master has the “full” project deploy @stalbert

I also prefer the use of a monolithic project for a single account vs. many feature repos. If you need to support multiple shared components across clients and projects I would recommend using a package manager like npm for versioning and distribution of components. Some kind of build pipeline is preferable for managing that kind of complexity though.

in my case,

master

has whichever deploy.xml was last merged in from a feature branch - we don't even try to keep some sort of 'everything' deploy.xml. I considered that since outside of netsuite I subscribe to the notion of always deploying 'all the bits' to avoid missing anything. However SDF (and NS development) seems more aligned with smaller project deployments. As Brendan mentioned, we do use NPM for binary artifacts (libs like NFT).

Thanks for the insights @Brendan Boyd and @stalbert