Personally, I love the idea of Heroku. Modern dev-ops can be a chore, and as a jack of all trades, adding Docker, Cloudformation, etc., into the mix is a bit daunting. It's a lot of work and for a small project, a lot to ask on top of everything. Heroku to the rescue! Sorta. Sometimes.
I'm pretty early on in a new project and I went with my trusty 'ole stead, create-react-app. By default yarn start or npm start kicks off the dev build, watches for changes, launches the browser, and enables hot reloading. I very much agree with this approach... you start the project by telling it to... start. But Heroku wants to use yarn start or npm start by default, so it's become common to setup a yarn dev or npm dev command. It's against my code design principles, whatever you write should be as easy for the consumer to use as possible, with as little need to dig into the code as possible. It's a small annoyance, really, but needless cognitive overhead, when most devs think to run start. There is a way to change what Heroku executes, but that's even more work. It seems almost hypocritical to what Heroku is designed for.
The test runners, oh the test runners. Come to find out there are two parts to the whoas here:
They have a nice little feature to release a test version of your app, with every pull request, so someone can go check it out and see if it works as expected, but by default, it's going to use your staging secrets. This means things like migrations will be run against your staging database. Bad Heroku! Bad! Creating a one off test environment has a lot of nuance to it, so I'd rather they don't offer the feature at all if they don't have an easy way to also provide a data layer that is specific to that instance. It just causes problems more than anything.
I thought I fixed that issue by creating a key value service, and pulling in config values dynamically, checking either NODE_ENV or HEROKU_TEST_RUN_BRANCH, but we ran into a problem with database migrations... again. Heroku uses a webhook inside of Github to watch for changes – pretty standard stuff. But the Heroku hook nor Github have the ability to filter which branches are applied. So when I pushed up some [Work in Progress] code, the incomplete-at-the-time migration ran. I didn't realize it of course, and the column I later added never made it into staging. Bugs!
These are just a few things I've fought with along the way, so far, but it might speak more to these types of platforms than anything. It's very difficult to get them right and I do give Heroku props. Personally though, I'd rather not have the functionality at all if it's going to lead to confusion, and even worse: bugs. Well, at least on a platform like this, something more generic and far reaching like AWS wouldn't have this problem, but the lift is a lot heavier.
Personally, I do like their work. But I hope they continue to iterate before bringing in new features. I really want an easy platform I can trust and know as little about as possible. I wouldn't complain if some serious competition popped up, either.
