Would it be possible to have one branch do multiple deploys?
For example: Netlify is linked to a Github repo. All code is merged into the master branch of that repo. The Netlify config for that repo has two different URLs - example.com and either staging.example.com or just use a consistent netlify url for staging.
The deploys to the main site can be locked just like normal, but the deploys to the staging branch are continuous.
Why?
All code is merged to master, reducing merge conflicts and reducing the need for a persistent staging branch (which usually then has to get merged into master later on to deploy)
The staging branch+website is always the latest code, greatly simplifying QAsâ jobs by not having n number of different netlify deploys to go look at, and devsâ jobs by integrating sooner with other devâs code
Deploys to prod website can be manual (by unlocking the deploy and then locking again)
Thoughts?
[edit] from a very naive perspective, it seems that netlify maybe already has the core functionality to enable this, it would just be rearranging it in a different way. But software is hardly ever that easy
But this would be a huge boon to devs/companies that do trunk-based development, which currently with netlify is a pain and a blocker in many ways. Weâve considered moving off of netlify because of the difficulty of trying to get a good trunk-based development workflow going.
We try not to judge folksâ workflows; I trust you have a reason for wanting what you want
Trunk-based development isnât some strange idea, itâs quite popular and common.
Itâs a workflow that Netlify just doesnât really support that well, and Iâm hoping that my suggested changes make the support a lot better.
I think what trunk-based devs are doing currently is just building elsewhere and then using the Netlify CLI to upload to various sites. Again, not ideal, and it could be so much better if Netlify supported this workflow directly.
You can link as many sites as you like to the same repo, put different names and different configs on them, even if you build the same branch.
Thanks, Iâll try this for the moment. Itâs just not ideal to have two different places that I have to manage website config/settings.
An issue Iâm running into implementing this workaroud, though, is that the deploy context for both sites is production but thatâs not what I want it to be for my staging website. (E.g. weâre using a netlify.toml file with different contexts to determine which API backend to hit. But if both the âstagingâ website and the âproductionâ website have the production context, theyâre both hitting production APIs.)
Is there a way to change the context, or is it always just determined by the main branch? I wasnât able to find anything concrete in the docs. But I could have missed something?
If not, then I think my next best bet is to just pull deploys out of Netlify and do them somewhere else (e.g. CircleCI) and then upload the built files to separate Netlify websites? (alternatively, I can change those to run-time variables as well)
Trunk-based development isnât some strange idea, itâs quite popular and common.
Sure, I wasnât trying to say it was weird, just that we donât judge and try to enable you.
On second reading of your initial request, as far as I can tell, what you have asked for is the default:
locked deploys prevent production content from changing
but have no impact on branch deploys.
Were you seeing something different?
I had initially thought you wanted to lock the staging branch deploy was why I gave you that advice, but I am no longer confident in either read after going over it a few times.
Iâm not sure if weâre on the same page; let me try to explain in a different way what I would like to achieve:
I probably wouldnât use branch deploys - branches are short lived (e.g. hours or a couple days at most) so it probably isnât worth it
All code is merged directly to master branch.
Master branch deploys to two (or more? I would probably only use 2 to start, but I have used 3 at various places) different sites:
a âstageâ website. This website is always deployed/updated when code is merged to master
a âprodâ website. This website deployment is âlockedâ, and then can be âunlockedâ when weâre ready to âdeploy to prodâ. We can then lock it again afterwards
Both the stage and prod website are managed in a single website config, since really itâs the same repo and even same branch - the only difference is which specific commit has been deployed.
This workflow better matches how trunk-based development generally works, and would improve trunk-based workflows significantly.
Does this help? Let me know if it still doesnât make sense. Thanks!
I guess I am not understanding what is not possible in that workflow with our existing tooling:
you configure your repo with a netlify.toml that will apply for the 2 sites you link it to. It sets things like environment variables, build command, etc.
on the stage site, you have us build every commit automatically. You can see work in progress at reliable URLâs like feat-1234âmystagesite.netlify.app, and you can see the production build at its URL which you could either set a sitename like âbeta.yourdomain.comâ for, or use the netlify site directly (https://yourstagingsite.netlify.app).
on the prod site, you have deploys either turned off completely or instead use the locked deploy feature to prevent unwanted publishes. Youâd also have builds for all non-production branches turned off, since you donât need to see a second copy of those builds on the short lived branches on this second site.
Does that sound feasible, and if not, what feels bad about it?
I would love the documentation for Functions to be clearer, especially for those who are new to the concept. Thereâs a smattering of information on the internet, but itâs hard to tell what is outdated and what doesnât work. I still donât know whether to use netlify-build or the build process or what the real difference is. Simple examples would really help - using CRA, using Express, accessing files within a lambda function, etc.
not having the ability to change settings for both websites at the same time
the netlify.toml sees both websites as âproductionâ so itâs difficult to have different settings/environment variables since theyâre both considered âproductionâ
I think 1) isnât a big deal, but would be an improvement, but 2) is a big deal and will require me to reconfigure quite a bit to get things to work in this setup. I think it can be done, itâs just not easy nor ideal.
Ah, thanks for clarifying! I donât have a good workaround for #2 except doing something conditionally in your build script based on site name or site ID, not exactly an easy pattern, since youâd also have to create something for local dev to work. If you only had different branchnames, (staging used a staging branch), you could set branch-specific contexts like [context.master] and [context.staging]. But then we also wouldnât be talking
I donât understand what settings you are making per website, outside of netlify.toml that you need to make in two places - could you elaborate? Perhaps it is possible to set them all there and at least remove the #1 problem.
I donât understand what settings you are making per website, outside of netlify.toml that you need to make in two places - could you elaborate? Perhaps it is possible to set them all there and at least remove the #1 problem.
Just pretty much anything that is configured through the Netlify website itself, e.g. environment variables, notifications, etc. Nothing major though.
environment variables can be configured in netlify.toml (probably only useful if not sensitive; I donât like committing e.g. my ssh key to the repo!):
I am currently using the build ignore feature with a monorepo quite heavily. I also happen to use slack webhooks to notify my team about successful and failed builds.
What I really wish for at this moment, is to differentiate between failed builds and cancelled builds.
I get reports of a failed build in slack every time a build is cancelled, though I see the cancelled tag in netlify itself. Iâd love for that to be reflected in the webhook message sent to slack as well.
Netlify already has great DNS support, and one makes it very easy to provision SSL certs.
My ask is to augment the Netlify DNS feature to allow us to define our DNS zone records (A, CNAME, ALIAS) as code in our repo. This would allow us to manage our DNS as code.
Related to this: Iâd love a distinct message type for cancelled builds that can subscribed to, so that we can opt in to notifications for cancelled builds the same way we currently can for successful or failed builds.
I played a bit with asset optimization and security headers/features. Iâve noticed assets optimized are missing subresource integrity. Iâd love to have SRI by default on optimized assets.
Hi Luke! Any chance you could publish an update regarding this âDeployable Naming Conventionâ feat? Itâs quite of an stopper for us right now. Thanks!!
Thanks for checking in!