whiskey_disk 0.0.5 → 0.0.6

data/README

@@ -1,11 +1,42 @@
 Whiskey Disk -- embarrassingly fast deployments.
 
   A very opinionated deployment tool, designed to be as fast as technologically
-  possible.
+  possible.  (For more background, read the WHY.txt file)
 
   Should work with any project which is git hosted, not just Ruby / Ruby on Rails projects.
   Allows for local deploys as well as remote.
 
+  Selling points:
+
+  - If you share the same opinions there's almost no code involved, almost no dependencies, 
+    and it uses stock *nix tools (ssh, bash, rsync) to get everything done.
+
+  - Written completely spec-first for 100% coverage.  We even did that for the rake tasks, 
+    the init.rb and the plugin install.rb if you swing that way.
+
+  - 1 ssh connection per rake task -- so everything needed to do a full setup is done in
+    one shot.  Everything needed to do a full deployment is done in one shot.  Having 8 
+    minute deploys failing because I was on cdma wireless on a train in india where the 
+    connection won't stay up for more than 2-3 minutes is not where I want to be.
+
+  - You can do *local* deployments, by this I mean you can use whiskey_disk to manage your
+    local checkout with localized (aka non-production) configurations trivially.  This turns
+    out to be surprisingly handy (well, I was surprised).
+
+  - You can have per-developer configurations for environments (especially useful for
+    "local" or "development" enviroments).  Use .gitignore and everyone can have their own
+    local setup that just works.
+
+  - Deployment configuration is specified as YAML data, not as code.  Operations to perform
+    after setup or deployment are specified as rake tasks.
+
+  - There's no before_after_before_after hooks.  You've got plenty of flexibility with just
+    a handful of rake hook points to grab onto.
+ 
+  - rake deploy:setup and rake deploy:now are really all that are needed, best I can tell.
+
+
+
   Dependencies:  rake, ssh, git, rsync on the deployment target server (affectionately
                  referred to as the "g-node" by vinbarnes), bash-ish shell on deployment
                  server.
@@ -58,8 +89,39 @@ Whiskey Disk -- embarrassingly fast deployments.
   - rake deploy:setup to=<environment>   (e.g., "staging", "production", etc.)
   - rake deploy:now   to=<environment>
 
+  More Examples:
+
+  - We are using this to manage larry.  See:
+
+    http://github.com/rick/larry/blob/master/config/deploy.yml
+    http://github.com/rick/larry/blob/master/config/deploy-local.yml.example
+    http://github.com/rick/larry/blob/master/lib/tasks/deploy.rake
+
+  - We are using it on a private project with lots of config files, but here's
+    a gist showing a bit more interesting deploy.rake file for post_setup and
+    post_deploy work:
+
+    https://gist.github.com/47e23f2980943531beeb
+
+
+
+  On the radar for an upcoming release are:
+
+  - common post_* recipes being specifiable by symbol names in deploy.yml ?
+  - making the config repo stuff optional if you don't need that at all
+  - bringing in a very simplified version of mislav/git-deploy post-{receive,reset}
+    hooks, and a little sugar so you can say:
+
+    task :post_deploy do
+      if has_changes?('db/migrate') or has_changes?('config/database.yml')
+        Rake::Task['db:migrate'].invoke
+      end
+    end
+
 
   Resources:
     - http://github.com/blog/470-deployment-script-spring-cleaning
     - http://github.com/mislav/git-deploy
     - http://toroid.org/ams/git-website-howto
+
+

data/VERSION

@@ -1 +1 @@
-0.0.5
+0.0.6

data/WHY.txt

@@ -0,0 +1,45 @@
+
+Why?
+----
+
+The idea here is inspired by github's cleaned up deployment scripts, and mislav's git-deploy project.  Only, we gave up on capistrano a long time ago, and after a few years of doing deployments on a few dozen projects, we realized that we really have very little variation on how we do things.  That is, we can afford to have a very opinionated tool to do our deployments.
+
+Here are the features/constraints we're envisioning:
+
+ - We need some sort of very basic "run this on a remote server" functionality.  We've been using vlad for years now and this would suffice:  it does what we're looking for and is much much smaller than capistrano.  If we don't load the included recipes it's basically a fancy ruby ssh wrapper.
+ 
+ - Setup should mostly just do a very fast remote git checkout in the right place.  Deployment should very quickly update that checkout.
+ 
+ - We have been considering a move towards tracking configuration data across our projects as a separate concern.  So, if we can have a private repo that stores per-project and per-environment (here I mean staging vs. production, etc.) configuration files, and have our deployments overlay those files quickly, that would be ideal.  I'm talking about hoptoad configs, database.yml files, AWS cert files, GeoKit API keys, etc., etc., etc.
+
+ - We should be able to use the same "setup == clone" + "deploy == reset" technique to manage the per-project/per-environment config files.
+ 
+ - Using rsync on the remote to those overlay config files on the deployed project would be a fast way to get them in place.
+ 
+ - Get rid of a bunch of annoying symlinks and symlink-hoops-to-jump-through.
+ 
+ - Get rid of a bunch of space (yeah yeah disk is cheap, but copying isn't) on the disk devoted to umpteen "releases".
+ 
+ - Obviously reduce deployment time by doing less, ssh-ing less, and taking less time to do whatever.
+ 
+ - should be rake based, and should provide a bare minimum of tasks -- like deploy:setup, deploy:now, and maybe a deploy:refresh_config_files.
+ 
+ - While a very basic task or few would run after setup or after deployment (e.g., rake db:migrate if migrations were changed, or touch tmp/restart.txt if the web server needs a restart; see git-deploy for more examples), we should be able to declare optional rake tasks (e.g., "deploy:staging:post_deploy") and have them run on this project if they are declared.
+ 
+ - Should work with projects that aren't remotely ruby.
+ 
+ - Should be loadable as a gem, meaning that it doesn't need to live in your project's space.  (see also non-ruby projects)
+ 
+ - Should be able to use a non-ruby config, preferably yaml, for information for all environments.  That could be stored in <project>/config/deploy.yml and saved with the project.  Even if this is just shoved into vlad 'set' commands, it's still an improvement:  we don't need ruby in the config file because we're opinionated.
+ 
+ - should be able to override settings for an environment locally by declaring a <project>/config/deploy-<environment>.yml.  Ideal for testing out deployments to different servers (or deploying locally).  This also makes it possible to .gitignore your local settings, so everyone can have their config repos in different places.
+ 
+ - should make it easier to do local development (e.g., on a laptop) by being able to overlay config files using the same rake tasks as used for remote deployments, just not running the functionality remotely.
+ 
+ - dropping in a project Rakefile can add post-deploy / post-setup hooks transparently.
+ 
+ - actually have meaningful error messages, unlike anything that ever seems to happen with cap or vlad.  :-/
+
+ - build this spec-first (whenever possible) so that there's a useful test suite.
+ 
+ - M$ windows hasn't been a priority for me for over a decade, not starting now.

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification 
 name: whiskey_disk
 version: !ruby/object:Gem::Version 
-  version: 0.0.5
+  version: 0.0.6
 platform: ruby
 authors: 
 - Rick Bradley
@@ -37,6 +37,7 @@ files:
 - Rakefile
 - TODO.txt
 - VERSION
+- WHY.txt
 - examples/deploy-staging.yml
 - examples/deploy.rake
 - examples/deploy.yml