I’m using a render.yaml blueprint in a single repo containing a Rails application. I’m aiming to have staging and production environments, loosely mimicking a Heroku Pipeline. Our development process is fairly simple - a
main branch into which feature branches are merged.
main is automatically released to staging. Then we manually release to production (“promote”).
There is a single render.yaml in the repo containing the rails app, postgres db, redis & worker
In render there is a staging blueprint instance based on this render.yaml
- this is setup to automatically sync
- the services in here are set to auto deploy
For production, I intend to do this again but…
- choose not to automatically sync the blueprint
- turn off auto deploy for the services
A few questions:
Does this sound reasonable? We won’t have as nice of a process like we currently do using Heroku Pipelines, but at least staging will be kept in sync. It will require some manual work to setup and there is room for human error.
How can we get the staging auto deploy to run after our CI has run in Github Actions?
There is nothing environment specific in our blueprint etc. So our services are created with the same name. This can cause confusion when reviewing services and logs. I’d rather have services created by the staging blueprint instance have a “-staging” appended etc. Is the best way to achieve this to manually rename the services after they have been created by the blueprint’s sync?
I’ve read a few hints that there’s work being done in this area. I suspect the Heroku Pipeline features is often asked for. Any updates? Is the approach we’re taking here compatible with what is planned, or are there tweaks we can make now that will make migration to a future pipeline-like solution smooth?