Permalink
Browse files

dropping outdated whiskey_disk plugin install

  • Loading branch information...
1 parent da93dfe commit 7a7073185d8ec0f422443d54b5394385076f57b4 @rick committed Jul 23, 2010
@@ -1,20 +0,0 @@
-Copyright (c) 2009, Flawed Logic, OG Consulting, Rick Bradley.
-
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-"Software"), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-
-The above copyright notice and this permission notice shall be
-included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
-LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
-OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
-WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
@@ -1,239 +0,0 @@
-Whiskey Disk -- embarrassingly fast deployments.
-
- A very opinionated deployment tool, designed to be as fast as technologically
- 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.
-
- Assumptions:
-
- - you have a Rakefile in the top directory of your project's checkout
- - you are deploying over ssh
- - your project is managed via git
- - you have a second git repository for per-application/per-environment configuration files
- - you are comfortable defining post-setup and post-deployment actions with rake
-
- Installation:
-
- As a gem:
-
- % gem install whiskey_disk
-
- As a rails plugin:
-
- % script/plugin install git://github.com/flogic/whiskey_disk.git
-
- Configuration:
-
- - look in the examples/ directory for sample configuration files
- - main configuration is in <app_root>/config/deploy.yml
- - per-environment configurations can be stored in <app_root>/config/deploy-<environment>.yml
- - config files are YAML, with a section for each environment.
-
- Known config file settings (if you're familiar with capistrano and vlad these
- should seem eerily familiar)::
-
- - domain: host on which to deploy (this is an ssh connect string)
- - deploy_to: path to which to deploy main application
- - repository: git repo path for main application
- - branch: git branch to deploy from main application git repo
- - deploy_config_to: where to deploy the configuration repository
- - config_repository: git repository for configuration files
- - project: project name (used to compute path in configuration checkout)
- - rake_env: hash of environment variables to set when running post_setup and post_deploy rake tasks
-
- - defining a deploy:<environment>:post_setup rake task (e.g., in lib/tasks/ or in
- your project's Rakefile) will cause that task to be run at the end of deploy:setup
-
- - defining a deploy:<environment>:post_deploy rake task (e.g., in lib/tasks/ or in
- your project's Rakefile) will cause that task to be run at the end of deploy:now
-
- Running:
-
- - rake deploy:setup to=<environment> (e.g., "staging", "production", etc.)
- - rake deploy:now to=<environment>
-
-
- Configuration Repository
-
- What's all this about a second repository for configuration stuff?
-
- Well, we're going to make it optional probably in another release, but we really
- are digging this, so maybe you should try it. Basically it goes like this...
-
- We have a number of web applications that we manage. Usually there's a customer,
- there might be third-party developers, or the customer might have access to the git
- repo, or their designer might, etc. We also tend to run a few instances of any given
- app, for any given customer. So, we'll run a "production" site, which is the public-
- facing, world-accessible main site. We'll usually also run a "staging" site, which is
- roughly the same code, maybe the same data, running on a different URL, which the customer
- can look at to see if the functionality there is suitable for deploying out to production.
- We sometimes run a "development" site which is even less likely to be the same code as
- production, etc., but gives visibility into what might end up in production one day soon.
-
- So we'll store the code for all of these versions of a site in the same git repo, typically
- using a different remote branch for each environment ("production", "staging", "development").
-
- One thing that comes up pretty quickly is that there are various files associated with
- the application which have more to do with configuration of a running instance than they
- have to do with the application in general. In the rails world these files are probably
- in config, or config/initializers/. Think database connection information, search engine
- settings, exception notification plugin data, email configuration, Amazon S3 credentials,
- e-commerce back-end configuration, etc.
-
- We don't want the production site using the same database as the development site. We don't
- want staging using (and re-indexing, re-starting, etc.) production's search engine server.
- We don't want any site other than production to send account reset emails, or to push orders
- out to fulfillment, etc.
-
- For some reason, the answer to this with cap and/or vlad has been to have recipes which
- reference various files up in a shared area on the server, do copying or symlinking, etc.
- Where did those files come from? How did they get there? How are they managed over time?
- If they got there via a configuration tool, why (a) are they not in the right place, or
- (b) do we have to do work to get them into the right place?
-
- So, we decided that we'd change how we deal with the issue. Instead of moving files around
- or symlinking every time we deploy, we will manage the configuration data just like we
- manage other files required by our projects -- with git.
-
- So, each project we deploy is associated with a config repo in our git repository. Usually
- many projects are in the same repo, because we're the only people to see the data and
- there's no confidentiality issue. But, if a customer has access to their git information
- then we'll make a separate config repo for all that customers' projects. (This is easier
- to manage than it sounds if you're using gitosis, btw.)
-
- Anyway, a config repo is just a git repo. In it are directories for every project
- whose configuration information is managed in that repo. For example, there's a "larry"
- directory in our main config repo, because we're deploying the larry project
- (http://github.com/rick/larry) to manage our high-level configuration data.
-
- Note, if you set the 'project' setting in deploy.yml, that determines the name of the
- top-level project directory whiskey_disk will hunt for in your config repo. If you don't
- it uses the 'repository' setting (i.e., the git URL) to try to guess what the project
- name might be. So if the URL ends in foo/bar.git, or foo:bar.git, or /bar, or :bar,
- whiskey_disk is going to guess "bar". If it's all bitched up, just set 'project' manually
- in deploy.yml.
-
- Inside the project directory is a directory named for each environment we might
- deploy to. Frankly, we've been using "production", "staging", "development", and "local"
- on just about everything.
-
- Inside the environment directory is a tree of files. So, e.g., there's config/, which
- has initializers/ and database.yml in it.
-
- Long story short, load up whatever configuration files you're using into the repo
- as described, and come deployment time exactly those files will be overlaid on top of
- the most recent checkout of the project. Snap.
-
- project-config/
- |
- +---larry/
- |
- +---production/
- | |
- | +---config/
- | |
- | +---initializers/
- | |
- | +---database.yml
- |
- +---staging/
- | |
- | |
- | +---config/
- | |
- | ....
- |
- +---development/
- | |
- | +---config/
- | |
- | ....
- |
- +---local/
- |
- +---config/
- |
- ....
-
-
-
- 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/lib/tasks/deploy.rake
-
- Note that you can also provide per-environment config settings,
- outside of deploy.yml. This is most useful for handling per-developer
- local deployments, though you could use it to override some settings
- if that makes sense in some context. Here's a simple example of that:
-
- http://github.com/rick/larry/blob/master/config/deploy-local.yml.example
-
-
- - 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
-
-
@@ -1,29 +0,0 @@
-require 'rake'
-require 'rake/testtask'
-
-desc 'Default: run unit tests.'
-task :default => :test
-
-desc 'Test RubyCloud'
-Rake::TestTask.new(:test) do |t|
- t.libs << 'lib'
- t.pattern = 'spec/**/*_spec.rb'
- t.verbose = true
-end
-
-begin
- require 'jeweler'
- Jeweler::Tasks.new do |gemspec|
- gemspec.name = "whiskey_disk"
- gemspec.summary = "embarrassingly fast deployments."
- gemspec.description = "Opinionated gem for doing fast git-based server deployments."
- gemspec.email = "rick@rickbradley.com"
- gemspec.homepage = "http://github.com/flogic/whiskey_disk"
- gemspec.authors = ["Rick Bradley"]
- gemspec.add_dependency('rake')
- end
- Jeweler::GemcutterTasks.new
-rescue LoadError
- puts "Jeweler not available. Install it with: sudo gem install jeweler -s http://gemcutter.org"
-end
-
@@ -1,16 +0,0 @@
- - common post-deploy tasks (including db:migrate, server bounce)
- - some sort of simple API for hooks to check which files have changed (either via git rev differences or rsync output), so then the rake task would just do something like:
-
- require 'whiskey_disk/rake'
-
- namespace :deploy do
- task :post_deploy do
- if changed_in?('db/migrate') or changed?('config/database.yml')
- Rake::Task['db:migrate'].invoke
- end
- # etc. ...
- end
- end
-
- - install hooks (look at maybe git-deploy for good examples)
- - make sure the config repo stuff is optional
@@ -1 +0,0 @@
-0.0.7
@@ -1,45 +0,0 @@
-
-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.
@@ -1,8 +0,0 @@
-staging:
- domain: "user@www.example.com"
- deploy_to: "/var/www/suparsite.com/"
- repository: "git://github.com/clarkkent/suparsite.git"
- config_repository: "git@github.com:clarkkent/suparconfig.git"
- deploy_config_to: "/var/cache/git/suparconfig"
- rake_env:
- RAILS_ENV: 'development'
@@ -1,11 +0,0 @@
-namespace :deploy do
- namespace :staging do
- task :post_setup do
- puts "This is my local post_setup hook."
- end
-
- task :post_deploy do
- puts "This is my local post_deploy hook."
- end
- end
-end
@@ -1,16 +0,0 @@
-staging:
- domain: "user@www.example.com"
- deploy_to: "/var/www/suparsite.com/"
- repository: "git://github.com/clarkkent/suparsite.git"
- config_repository: "git@github.com:clarkkent/suparconfig.git"
- deploy_config_to: "/var/cache/git/suparconfig"
- branch: "production"
- rake_env:
- RAILS_ENV: "production"
-local:
- repository: "git://github.com/clarkkent/suparsite.git"
- config_repository: "git@github.com:clarkkent/suparconfig.git"
- deploy_to: "/Users/clark/git/suparsite"
- deploy_config_to: "/Users/clark/git/suparconfig"
- rake_env:
- RAILS_ENV: "production"
@@ -1 +0,0 @@
-require File.expand_path(File.join(File.dirname(__FILE__), 'lib', 'whiskey_disk'))
Oops, something went wrong.

0 comments on commit 7a70731

Please sign in to comment.