What the most awesome app deployment app looks like

by Michiel on October 15, 2009

Today was another day of the first day of the first release of a new web application. After prototyping the new project for a few days, the time had come that we’d finally show the first part to the rest of the team members and the client. Currently, it’s the least thing I like about releasing new apps: deploying. It always involves setting up the Git repository on Github, adding domain configuration on the web server (or even worse, setting up a load balanced environment), launch ec2 instances and write or configure the (web|cap)istrano scripts. It takes hours and multiple things fail you’ve already done a thousand time on other deployments. Here’s a list of what the most awesome deployment app would have:

  • It should be a web app, hosted, pre-installed, no fuzz, clean-interface, Basecamp-like subscription payed shizzle.
  • It MUST support with deploying from various SCM’s like Git, SVN, Bzr and maybe even still CVS. (Git with submodules, svn with externals, you do the math)
  • It MUST constrain the user to some broadly supported standard deployment strategies. For instance Ruby on Rails applications with Apache/NGINX and Phusion Passenger (aka Mod Rails). The user should not have to worry about the background of the deployment and should not have the power to break stuff.
  • It MUST have a philosophy of projects/applications over servers. Your app runs “in the cloud”. The architecture behind it is secondary. Instead of installing an application clone on a new server and configure the load balancer, you add a server – or better an instance – to your application and the application makes sure the new instance of itself gets picked up.
  • It SHOULD take over all the configuration of the application. From generating passwords to setting up databases and migrations to configuring new servers in a load balancer. The deployment app knows best.
  • The user should only have to add their deployment keys or maybe a local deployment password everything else (like deployment locations and stuff) should be convention over configuration. Everything the user want’s to add should be available through nice gradient-like big buttons with smilies on them and the user MUST be greeted with “Yo, dude”.
  • Everything should be as sexy as your girl or boyfriend.

And no worries guys, we are buiding this right now.

P.S.: If you don’t have a girl or boyfriend, pick your dog or cat. If you don’t have those either. You’re not allowed into the beta.

More of my posts on this topic:

  1. Best practice for account settings
  2. Use AWS to boot from EBS to start testing your web app

Leave a Comment

Previous post:

Next post: