There appears to be more vendor lock in with this one requiring heroku specific files...
I'm a bit behind on best practices with Heroku so the heroku.yml[1] config is new to me and it says it doesn't replace app.json. This is where I feel like Cloud Run supporting "plain" docker files or build packs is great. I wonder if Heroku will follow suit and make it a bit easier to deploy "just a container"?
Cloud Run doesn't recognize app.json natively. However this project (Cloud Run Button) accepts an app.json that lets the developer configure env variables to prompt to the user.
Just last saturday, I tried to take an application which prominently featured a "Run on Heroku" button and test a bug locally.
For the life of me, I could not figure out to go from the button-based(apparently automatically inferred by Heroku?) deployment to a local Procfile-based deployment.
It was faster to rely on the alternatively provided Dockerfile to start a local deployment and hope that it was as up-to-date as the Heroku setup.
I find the idea of one-click deployments really appealing, but Heroku's vendor-lock-in-based implementation really turned me off their service.
All of the Heroku button stuff is configured in an `app.json` file in the root of the repository. There's also still a Procfile used. The `app.json` just helps with the initial configuration such as environment variables that need to be set, scripts to run, etc.
I'm not sure how much you know about Heroku, but their runtime environment is based around so-called buildpacks, which provide the required executables, packages, configuration, etc. for various languages (ruby, php, js, ...). Once you push code to Heroku's git remote it will analyze your code and select the proper buildpack to run the code on.
So you are absolutely right that you can't simply go from an app.json file to a local development system in one step, as you (very likely) don't have the required infrastructure on your system.
I see - so the idea behind checking in a Procfile is that you can run this locally using "heroku local", but the idea behind a app.json is that you explicitly can't?
The Procfile describing your application given some base installation (e.g. PHP 7.3), the app.json describing in this case nothing in particular?
Any application requires both a base environment and instructions for application deployment. And that is how the Dockerfile for rss-bridge is constructed, too.
So what besides vendor lock-in is the advantage of Heroku's approach?
Heroku's buildpacks make some default assumptions regarding an app's startup. For a Ruby on Rails app, for example, it would simply start the web server using `bundle exec rails s` unless you define something else in the Procfile. I'd assume there is a similar procedure for PHP apps, probably starting an nginx instance and pointing it at the app's index.php or something like that.
The way I understood it, app.json is there to customize the environment for the application to run in – providing ENV variables, required addons (think databases, memcache, etc.) and pre/post deploy scripts. A sort of configuration-as-code if you will. It is explicitely not used to define the actual processes that should be started when the app is deployed, that's what the Procfile is for, as long as you're running in an environment that supports Procfiles.
I'm not really sure what to tell you regarding vendor lock-in. Apart from the app.json the repo itself looks completely vendor-unaware, as it is simply a PHP application. It doesn't seem to make many assumptions regarding your (local) infrastructure but rather assumes you know how to get a PHP application to run on your server/computer. The presence of the app.json file is just an affordance to those who would want to try out the app without having to configure anything themselves.
On the contrary, now that I think of it. I always found Heroku to be rather non-locking, as you can just take your code and run it somewhere else. You need to provide some additional tooling around your deployments yourself in those cases, but that's true for all PaaS providers, isn't it? Heroku Addons are nice features, but usually simply services provided by third parties that are made available using automatically generated ENV variables, which you could simply copy over to wherever else your app is running.
There are a couple of options for making a "deploy to Azure" button. Both rely on ARM templates (declarative, parameterized deployments powered by JSON files):
1. Follow the steps at https://deploy.azure.com. This one greases the wheels for linking from a GitHub repo README for code that can be deployed straight to an Azure web app - you can just link to the site and it gets the repo URL from the referer header and uses a premade template to deploy it. You can also provide your own templates with custom parameters.
