Hey guys, what’s your deployment strategies with cloud apps and how you prefer to publish them?
I’m struggling a bit with this topic.
What i have in mind is that i can make some kind of blue/green deployment, creating marketplace listing providing link to for example my.app-green.com publishing it to market, then when i update something that needs approval or just want to create new version i provide new version with new url, something like my.app-blue.com. Wait for everyone to update to new version if there’s need in manual update due to descriptor changes and then shutdown green leaving blue to work as my prod server, and swap them when new update that needs approval. But with that approach idk what to do with database? Should i use 1 DB for both green and blue or 2 different DB’s and how to sync them (replication won’t work as i think).
What’s your approach for deploying and publishing apps that needs approval from marketplace staff and manual approval from admins of each instance of a product?
1 Like
Hi,
For my part, I use Heroku for my PaaS provider. They have a feature called pre-boot which switches incoming requests to the new web processes while keeping the current requests running therefore providing a zero downtime deployment mechanism, Both operate on the same DB (Postgres) which is automatically backed up daily and kept for 7 days. They also have the concept of pipelines where you can easily promote the same load from development to staging to production in one single click.
If I need to update the DB, I set the Heroku maintenance mode on which redirects the traffic to a static maintenance page (either provided by Heroku or your own page hosted on Amazon AWS). My add-on therefore displays the maintenance page and I do a quick migration of the DB and 5 min later the add-on is back online.
When I have new features that would break if the customer is using the old connect descriptor, I use feature toggle in the URL. E.g. I once added a new dialog which was triggered by a menu. The menu item showing the dialog was conditional to the feature toggle being active. So, people which were not yet updated to the new descriptor would not see the menu item while the others could.
The trick is to be conscious of the changes you make to the connect descriptor and act accordingly.
I know that Heroku may sound expensive at first but you can get by with roughly $75/month and not have to deal with these deployment mechanism. Especially at first when you need to focus on growing your add-on to achieve market fit. Later on, you can spend the time and energy in moving to a different platform if it becomes too expensive.
Cheers
2 Likes
Hi,
Thanks for your reply, that’s really helpful 
Sadly (or not) we’ve got some server powers so we can host our app ourselves, but we lack on experience a bit 
Told my boss about heroku months ago, but he insisted on giving a try to our servers. Now we’re struggling a bit 
I will set that as solution for now, but i’m looking for other solutions, maybe someone got different experience and come up with his own idea
For management, it’s usually a matter of money. He may think that because he has the servers, everything will be cheaper but you should build him a small use case. Make it a business case over 6 months. Calculate the number of hours it will take you to build a zero downtime deployment (including the already used hours), auto-scalling/load balancing to support higher demands, re-routing for maintenance and all the possible hardware it may take. Cloud add-ons require a solid infrastructure. After that, compare this with $450. The choice is not hard to make, especially if you want to learn the market potential. You may find out after 6 months that barely no one is using your add-on and that it’s not worth it pursuing. Losing $450 is much better than losing several thousands.
Good luck!