I’d like to be able to handle deploying multiple “services” from the same repo after a proper release phase.
For example, lets say I have a single repo called “backend” that knows how to start up in either API mode or QUEUE mode. The two modes share a bunch of code, including database models and migrations.
In heroku’s world, this was pretty straightforward. I’d have my single repo with a procfile that looked something like this:
When I push a new commit to the repo and a deploy is triggered, it builds the new image, gets multiple instances ready, runs the release command on one, and waits until it succeeds to fully start up the new api and worker (and then handle rolling deploys if there are many instances running).
In render’s world, I’d have to create a new “web service” to run in API mode and a “background worker” to run my work queue with both linked to the same repo. When I push a new commit, aside from the fact that a proper release hook isn’t available at all, they both start deploying independently, so I can’t coordinate it release of both together. This is important both in terms of timing, but also so that I can stop the release of both if something goes wrong with my migrations.
Would love to know what you think are best practices in a situation like this and if these kind of features may be on the roadmap.
Hi @theo you’re certainly right in that we are aware of the need better support monorepo support. We have an open issue around this here which you can upvote to receive updates on.
While we don’t offer specific lifecycle hooks like release hooks, some users have been able to get around this by adding it to their build scripts. We also have one-off jobs that can be run for a service for things like migrations. These can be triggered via the API. You might also consider using deploy hooks if you need to conditionally control the deployment of your services, rather than relying on autodeploy.
Thanks for pointing me to that related issue. In my case I don’t actually have things set up as a monorepo, but rather I’m launching the same app in multiple configurations. Please I would ask that as you design these features to keep this use case in mind and not couple things too tightly to the tooling around monorepos.
As for using one-off jobs, deploy hooks, and your API - I could certainly set up my own little build pipeline using these features, but I’m using render to avoid having to build custom code around deployment logic.
Would love to see this kind of setup supported ASAP, or I may have to switch back to heroku until it is - which I really don’t want to do!
I could have sworn I had written something already but was searching through these forums rather than the roadmap… Would be nice if that search was unified!