They have different use cases.
They have different use cases. Environments are more for when you want to have isolated deployments with different bindings etc. (e.g. staging and production). What is it you want to achieve?
4 Replies
for my specific use case, yeah I want to have a staging and production environment. Right now, I just deploy all non-default branches to the staging environment version of the worker. That works fine cuz I am mostly working by myself on this project, but if there were many developers, having only a single staging worker would cause problems.
It seems like worker versions address that use case, where you can have a version per branch. This is what I do for my static asset worker. I can't do that for my main backend worker because it binds to a DO
to be clear, even in the branching scenario, I think I would be fine to have shared bindings for the non-production versions
I see. I think environments is generally better suited to what you're describing. You could have a
preview environment that you deploy changes to and then deploy them to production when they are merged into your main branch.and long term, is the the idea that both will coexist?
or is the idea for one to slowly accumulate all the functionality of the other
They will both coexist as versions can be used with environments e.g. for gradual deployments and rollbacks. I think there is a long term plan to support ephemeral environments so that you can have an environment that is created per PR. That would probably help improve your workflow.