Env separation
How do you do staging / production with durable objects? Do you have to have two classes e.g. ExampleClassStaging & ExampleClassProduction?
10 Replies
I setup 1 branch is 1 cloudflare pages project
main branch is production
non-main branches are preview environments
Each one of them is 1 single cloudflare pages project itself and their kv/do/R2 bindings are all separated
I build my own deployment tool that uses wrangler to provide vercel like preview environments, which preview environments are destroyed when the corresponding branch is closed/merged (the script is run by GitHub actions)
I have that already for my Pages Project. But I'm wondering how I upload a production version of my Durable Object and a Staging version of Durable Object, similar to how Pages is able to distinguish between deployments. It seems that cloudflare does not distinguish between the two. So I'm thinking you actually have to have two separate objects.
U can associate the do to each cloudflare pages project right?
I'm doing it via wrangler pages publish CLI on GitHub actions, but I think u can do it on dashboard
ok .. so that's the answer then, you have to have two different durable objects, one for staging & one for production and associate each separately to your pages environments
Yeah, you wouldn't connect Ur staging env to production mysql or postgresql right?
If yes, durable objects should also been seen as such infra
yep .. main problem however is that I have to figure out how to not have two separate copies of the code. It would have been nice to push the same class from different branches of GitHub (in my case main branch=staging, production branch=production), but have Cloudflare rename it for you, just like it does for Worker's scripts setup in Wrangler environments.
I bet u r not running deployment script urself on GitHub action, hence you have this limitation where cloudflare build won't allow u to customise the behaviour
I am gonna release this cli tool in the next few weeks, which would allow you the setup 1 cloudflare pages project for 1 branch along with do/kv/R2 as an isolated environment, like how vercel preview looks like, and these pages projects get destroyed upon Ur pull requests closed/merged
The only caveat is it spends Ur GitHub action minutes which is like super fast (within 2 mins)
Thanks for the response, Cayter. Your effort seems great but I don't think it addresses the question I have since I never delete my staging branch (it's the main branch). I'm actually trying to use the CI/CI built-in with Pages project and have so far managed to get everything working.
yeah in that case, u can keep a staging branch opened and not deleted
main branch - production
staging branch - staging
As long as the branch is there, the cloudflare pages project will stay
in your case, it seems like u wanna use main branch for both staging and production
it can still be done, it's just that the script need to take in a config like
production branch = main
staging branch = main
Every time when there is a push to main, there will be 2 pipelines running
1 to staging cloudflare pages project
1 to production cloudflare pages project
No Main branch is for staging only
Product branch is for production
I push from main to production when I want to do a production releases
There are multiple articles written on why it makes sense to organize in this manner
OK .. actually, this was all because I was new. Cloudflare assigns a unique name to my staging instance where:
Name of Durable Object = <Name of Worker Script>_<Name of Durable Object Class>
So if I have defined staging & production scripts in my wrangler.toml, then everything works.
I was new to this so did not understand.
Thanks for the help Cayter .. really appreciate it.