Do you know render.com? It's a PaaS aiming to replace Heroku, taking advantage of its decline. You get plenty of new welcomed features like free static sites on CDN, attached disks, infrastructure as code, HTTP2, a fast dashboard, a clean and up-to-date documentation, lower pricing at scale, and so on.
In a word, a better Heroku? Not so fast.
If you already played with Heroku, you're probably aware of their pipeline feature. Simply speaking, it's a way to group apps sharing the same codebase, in which each pipeline represents a stage, in a delivery workflow (for example : development → staging → production).
What's brillant here is not just the idea of organising and representing apps by stage, but the workflow itself: you build your code once, and as soon as you're happy with your code at stage N, you promote it at stage N+1. A promotion does not re-build the code, which gives you some advantages. For example, promoting your app between a staging and production environments:
Now let's dive a little bit deeper to understand whats makes this workflow possible. Back in the days, Heroku team published a 12factors app methodology for building SaaS apps, in which the 5th rule is about a strict separation between the following 3 stages:
rake db:migratein Rails,
python manage.py migratein Django, etc.). And this makes perfect sense: if you're aiming to use the same build for each environment, you need to run everything's tied to the environment itself, in a specific stage. For pipelines, promoting an app to stage N+1 will not rebuild the app but will run the release phase.
However, the release phase is absent from Render architecture (and probably many other PaaS). Why? Honestly, I don't know. However, for Render.com hosting services, I already noticed two pain points (and there may have more):
1) As just explained, pipeline workflow is almost impossible without a release phase. You could technically organise apps in pipelines, but having to rebuild for each promotion would make this feature a cosmetic one rather than a true workflow improvement.
2) Unlike Heroku, Render.com gives access to mounted disks, which allows an app to use SQLite as a database. But disks are not available at build stage, which is understandable. But wait… when am I supposed to run migrations sthen? I have no choice, I have to run my migrations at runtime!!! And I see two problems with that:
Some would argue that these are not crucial issues. But I'd answer that a clean architecture and a clean deployment process require simplicity, clarity, sense, and consistency, and that human errors often come from workarounds and inconsistencies like these.
In the meantime, adding a release phase is considered like an upvotable feature in Render community. I'm not sure I see it this way. Having a release phase is more an architectural decision which allows more features to exist (pipelines) and make the whole deployments more robust.
Once Render.com implements the release phase, I think I'll be able to say to the world:
We got our new Heroku!