I was browsing the Getting started with Django documentation until something picked my curiosity: the
build.sh script contains a
python manage.py migrate command.
Should I understand that in Render, there is no release phase, like explained in 12 factors page here? If so, can someone explain this architectural decision?
In my opinion, having a distinct release phase is a great advantage, allowing to use a single and same build (a “slug” in Heroku voc), to deploy in several environments (like staging and production).
This ensures having the exact same build between your envs without any doubt. And this makes thing like prod deployment instantaneous if you already deployed to another env before.
This is a great question, it comes up a lot actually and something that we definitely to improve on - there’s been a feature request for this at https://feedback.render.com/features/p/release-phase-script which I’d encourage you to upvote and follow for future improvements we make.
The linked feature request seems to be only about running custom actions before release.
What we would like to see (and what the OP also mentions), is the possibility to build once, deploy several times. We would like to deploy Staging automatically, do some automated and manual testing there, and when satisfied, promote the build to production. For us this would have 2 benefits: #1 it would make sure, that we run exactly the same thing in prod, than what was tested; and #2 it would make the actual release action significantly faster.
PS, we are currently looking for a replacement for Heroku. I’m really liking what I have seen so far of Render. The choice would probably have been made already, if Render would support this.
Yes exactly. To be more specific, I’d say that one feature is a requirement of the other.
- We need to get a
release not tied the building phase.
- We need to get a pipeline-like working. A short explanation:
a group of apps that share the same codebase. Each app in a pipeline represents one of the following stages in a continuous delivery workflow.
It looks like this in the Heroku Dashboard:
@John_B do you think this requires 2 distincts feature requests?
PS: I’m surprised hosting services like Render and many others pretending to replace Heroku in a better way, don’t actually implement this killer feature from day 1.
Definitely agree with both points here and I’m pretty sure both will be addressed as this short fall has been raised quite often.
ps. 7 years ex Heroku here - built all the Heroku support tooling, intimate with those screens
That’s great to hear. Anything you could share about the potential implementation timeline @John_B ? (Assuming not, but hoping for the best )
No timelines, but it’s definitely our focus!