Trunk-based development questions

Struggling to find a clear path to enable Trunk-based development.

The idea being, for my stable environments (dev, stage, prod) I want dedicated URLs.

BUT, I DO NOT want to use the GitFlow source control pattern (with branches representing my environments). Rather, I want to push everything to master and simply advance this code from one env to the next as desired.

For example, in my CI tool (eg Github Actions) I have multiple workflows:

  • Workflow 1: merges into master deploy to dev.site.com [CAN DO]

  • Workflow 2: once everything is tested on dev, trigger the next stage of my pipeline to deploy the dev.site.com code to stage.site.com [NOT SURE HOW TO DO THIS]

Maybe the question is How do I target a subdomain regardless of branch?

I currently have one site on Netlify with a primary and alias domains.

Any suggestions? Many thanks.

wondering if i need multiple sites to enable Trunk-based development as outlined above?

Site 1: dev.site.com
Site 2: stage.site.com
Site 3: site.com

Then because each site has its own AUTH_TOKEN and ID, I can target the deploy target.

Then the issue is maintaining the build artifact outside of Git (which isn’t too bad in my case).

As soon as the dev env is deployed to stage (from the code in master), I save this build artifact so it can be deployed to my prod site when necessary (using a GitHub Action in may case).

Hope that helps someone

Hi, @jega. It sounds like you are considering using a unique site for each “trunk”. I was going to recommend this myself.

If you are using different git branches then using our branch subdomain feature makes sense. You are not using different git branches so this won’t work for you.

The next best workaround is just to use different sites as you have suggested.

Also, I want to warn you about a “false workaround”. It is a possible solution some people have already tried and it doesn’t work. So, warning - warning, do not try this:

  • DO NOT use the netlify deploy --alias option to try to use the branch subdomain feature.

This option used to be called the --branch option (and still is although noted as deprecated). It doesn’t make a “true branch deploy” (hence the name change from --branch to --alias). You can get a predictable URL with that but it will not work like a “real” branch deploy. Meaning, branch subdomain features s will not apply to subdomains made using --alias or --branch.

Last but not least, people sometimes want to use branch subdomains and also want to change the subdomain. For example, the branch name may be “development” but they want the subdomain to be just “dev”. If so, the best workaround is the same: use a unique site for each branch and you can use whatever subdomain of you custom domain you want to use. With unique sites, the naming requirements of the branch subdomain feature are removed.

To summarize:

  • The branch subdomain feature is great if you want automatic subdomains based on the branch name.
  • The workaround I would recommend for most (all?) other cases is to use unique sites and handle the naming by hand.

If there are other questions or if you want to share your solution/experience, please reply here anytime.

P.S. I moved these post to a new topic for clarity.

OK, my final working solution which “approximates” a trunk-based workflow with multiple deployment environments (each with their own unique services).

First, I created a Netlify site for each domain.

Netlify Site 1: dev.site.com

  • deploys “master” branch
  • build command “SERVICES_ENV=dev yarn build”

Site 2: staging.site.com

  • deploys “staging” branch
  • build command “SERVICES_ENV=staging yarn build”

Site 3: site.com

  • deploys “production” branch
  • build command “SERVICES_ENV=production yarn build”

With this approach, I achieve three stable build environments each using the appropriate services.

For most of our engineering team, this mimics trunk-based development as we merge into master. Down stream however, we still do have release branches (GitFlow) which power the pre-prod environments.

Pretty workable and flexible for most use cases.

2 Likes

I’ve written an article about this here: https://www.cotyhamilton.com/netlify-deploy/

I also practice tbd and am always looking for ways to get out of the gitflow strategy every app service enforces or provides.

Essentially you install the netlify-cli and you can deploy how you wish.

1 Like

thanks for sharing this, @cotyhamilton!

thanks all, this has been helpful to follow. one question though - I follow creating a site per dev, stage, prod. however, how would you go about linking a context from the netlfiy.toml to each site? for example, I know I can set the env var in the UI for the site, but its the simplest example: if I want to set NODE_ENV = production for only prod, and NODE_ENV = development for dev and stage, how would I do that if there are 3 sites but they are all using the same netlify.toml file?

Hey @bryantbiggs,
I think you’d have to write a Build Plugin to do something like that, or you may be able to fork and adapt an existing one like this:

A Build Plugin would let you grab the current site name during the build process and write logic to say “if I’m running on site x, set my NODE_ENV to y; else if I’m running on site a, set my NODE_ENV to b”

Here are our docs on Build Plugins: Build Plugins | Netlify Docs - they’re surprisingly quick to start working with, please let us know if you have any questions if you go that route!