How to structure repo for Netlify subdomain support?

Viewed 1019

Netlify subdomains work based on branches on a repo. If I have a domain say xyz.com and repo Repo-A, the master branch will deploy to xyz.com and dashboard branch will deploy to dashboard.xyz.com. However the dashboard and master branch are very different expect for a few visual elements.

I’m trying to figure out a clean way to structure the repo

Repo - A
(master branch)
   src/app
   package.json
   webpack.config.js


Repo - A
(dashboard branch)
   src/app
   package.json
   webpack.config.js

The problem with this approach is I’d have to change my webpack, package and src files extensively. I believe switching back and forth between branches will generate a lot of junk in the dist/ folder too.

What’s the best repo structure to make this work? Are there tools to make life simpler for this use case?

Another approach -

Create a Release Repo that has release branches like master and dashboard.

master commits to Repo A which pushes build to master branch of Release repo
master commits to Repo B which pushes build to dashboard branch of Release repo

Is this a cleaner approach compared to first one? Any suggestions?

1 Answers

This feature seems to be more for staging/development/production(master) when you are using them to track changes for review and doing pull requests to each sub-domain branch through the workflow. I don't use this feature, because it is easy to track workflow by creating branch deploys anyway. Where I think this would really come in handy is when tracking versions of my site at subdomains for different versions.

When using a sub-domain for a totally different project, you should consider moving them to their own repositories and managing the project as it's own site at the sub-domain. Then entering a CNAME sub-domain entry into DNS to point to the my-dashboard-site-name.netlify.com enter image description here

Mono-repo

You could have them in the same mono-repo if you don't want to make them their own repo, you would still separate the sites deploy. This is a little bit more complex than their own repository, but tools like Lerna are there if you want to maintain it that way. It does make for a nice way to maintain projects that re-use the same libraries that are not published to a package manager, but in the same mono-repo.

Related