== gitpusshuten deploy button

This is a Proof of Concept service to support easily deploying basic rails applications via a website.

The 'success' state is when a button exists on http://www.xrono.org that says 'Launch You a Xrono!' Upon clicking this button, it will ask you for the following information:

• server_ip
• root_password
• domain_name

After entering this information, it will then set up your server to host the application on that domain. To verify that it's working, you can modify your hosts file to point that domain to the appropriate IP address (or actually buy the domain and point it). Upon visiting the domain, the app should be up and running in the base state defined by the seeds.rb file.

== Short-term plam - or, how is this proof of concept architected?

Routes: GET /projects/:project_name/deploys/new - ask for the information necessary for a new deploy POST /projects/:project_name/deploys - create a new deploy of :project_name

Models: Deploy: server_ip:string, root_password:string, domain_name:string, project_id:integer, guid:string. After create, a deploy will kick off the gitpusshuten commands to actually deploy the Project: name:string, git_repo:string. Initially these will have no GUI and will just be created in the console.

Libraries: ProjectDeploymentHandler: Given a git repo, a guid, and appropriate server/domain information, will handle the gitpusshuten commands to deploy it remotely. Will store files in /tmp/#{guid}

== Long-term plans

Long-term, the goal is to get off of gitpusshuten for the service I intend to build. This is just the easiest way I know to build the proof of concept. But who knows, maybe gitpusshuten will actually work fine long-term.

InfrastructureRecipe: This will be a file or repository containing instructions that, at a high level, look like: provision 2 haproxy servers with failover, 2 mysql servers (one master, one slave) with failover, and 3 app servers. The app servers should have redis and memcached installed. I believe that there will ultimately be a market for these recipes, from which will emerge 5-10 'winning' strategies outlining specific architectures for apps.

CloudProvider: some cloud provider (likely rackspace / openstack initially) on which to provision the servers, and models to ease provisioning on them.

ConfigurationSchema: some DSL or yml schema to support building interfaces to configure a given InfrastructureRecipe. For instance, a recipe that included haproxy might build out an interface to support building URL-based traffic redirects - so a rule where someone can say that any traffic matching /api/ would be routed to a particular group of app servers, and any traffic matching /reports/ would be routed to another.