ol-whisk_deploy 0.6.25

Sign up to get free protection for your applications and to get access to all the features.
Files changed (177) hide show
  1. data/CHANGELOG +292 -0
  2. data/MIT-LICENSE +20 -0
  3. data/README.integration_specs +24 -0
  4. data/README.markdown +832 -0
  5. data/Rakefile +105 -0
  6. data/VERSION +1 -0
  7. data/WHY.txt +45 -0
  8. data/bin/wd +61 -0
  9. data/bin/wd_role +42 -0
  10. data/examples/deploy-configs.yml +13 -0
  11. data/examples/deploy-local.yml +4 -0
  12. data/examples/deploy-multiple-remotes.yml +26 -0
  13. data/examples/deploy-staging.yml +8 -0
  14. data/examples/deploy.rake +11 -0
  15. data/examples/deploy.yml +16 -0
  16. data/init.rb +1 -0
  17. data/install.rb +5 -0
  18. data/lib/whiskey_disk.rb +327 -0
  19. data/lib/whiskey_disk/config.rb +127 -0
  20. data/lib/whiskey_disk/config/abstract_filter.rb +19 -0
  21. data/lib/whiskey_disk/config/filter.rb +48 -0
  22. data/lib/whiskey_disk/config/filters/add_environment_name_filter.rb +11 -0
  23. data/lib/whiskey_disk/config/filters/add_project_name_filter.rb +11 -0
  24. data/lib/whiskey_disk/config/filters/check_for_duplicate_domains_filter.rb +21 -0
  25. data/lib/whiskey_disk/config/filters/convert_role_strings_to_list_filter.rb +20 -0
  26. data/lib/whiskey_disk/config/filters/default_config_target_filter.rb +12 -0
  27. data/lib/whiskey_disk/config/filters/default_domain_filter.rb +12 -0
  28. data/lib/whiskey_disk/config/filters/drop_empty_domain_roles_filter.rb +32 -0
  29. data/lib/whiskey_disk/config/filters/environment_scope_filter.rb +20 -0
  30. data/lib/whiskey_disk/config/filters/hashify_domain_entries_filter.rb +29 -0
  31. data/lib/whiskey_disk/config/filters/localize_domains_filter.rb +24 -0
  32. data/lib/whiskey_disk/config/filters/modules/scope_helper.rb +11 -0
  33. data/lib/whiskey_disk/config/filters/normalize_ssh_options_filter.rb +29 -0
  34. data/lib/whiskey_disk/config/filters/project_scope_filter.rb +34 -0
  35. data/lib/whiskey_disk/config/filters/select_project_and_environment_filter.rb +12 -0
  36. data/lib/whiskey_disk/config/filters/stringify_hash_keys_filter.rb +25 -0
  37. data/lib/whiskey_disk/helpers.rb +50 -0
  38. data/lib/whiskey_disk/rake.rb +47 -0
  39. data/scenarios/git_repositories/config.git/HEAD +1 -0
  40. data/scenarios/git_repositories/config.git/config +5 -0
  41. data/scenarios/git_repositories/config.git/description +1 -0
  42. data/scenarios/git_repositories/config.git/git-daemon-export-ok +0 -0
  43. data/scenarios/git_repositories/config.git/hooks/applypatch-msg.sample +15 -0
  44. data/scenarios/git_repositories/config.git/hooks/commit-msg.sample +24 -0
  45. data/scenarios/git_repositories/config.git/hooks/post-commit.sample +8 -0
  46. data/scenarios/git_repositories/config.git/hooks/post-receive.sample +15 -0
  47. data/scenarios/git_repositories/config.git/hooks/post-update.sample +8 -0
  48. data/scenarios/git_repositories/config.git/hooks/pre-applypatch.sample +14 -0
  49. data/scenarios/git_repositories/config.git/hooks/pre-commit.sample +46 -0
  50. data/scenarios/git_repositories/config.git/hooks/pre-rebase.sample +169 -0
  51. data/scenarios/git_repositories/config.git/hooks/prepare-commit-msg.sample +36 -0
  52. data/scenarios/git_repositories/config.git/hooks/update.sample +128 -0
  53. data/scenarios/git_repositories/config.git/info/exclude +6 -0
  54. data/scenarios/git_repositories/config.git/objects/0d/b14dd6ddc54017c0a11960dcda82ed802cde69 +0 -0
  55. data/scenarios/git_repositories/config.git/objects/0e/e781f5ce80d64db32a74a7aae7b5248dafe112 +3 -0
  56. data/scenarios/git_repositories/config.git/objects/17/6bf54cf17d1d1c24556dc059c4144a5df230e8 +0 -0
  57. data/scenarios/git_repositories/config.git/objects/20/e9ff3feaa8ede30f707e5f1b4356e3c02bb7ec +0 -0
  58. data/scenarios/git_repositories/config.git/objects/45/117b1c775f0de415478dbf08ed9d667ab17d13 +0 -0
  59. data/scenarios/git_repositories/config.git/objects/51/3954c9aca090e6ce40359f0e9fde30ea78eb8c +0 -0
  60. data/scenarios/git_repositories/config.git/objects/66/947a7a11a6f5d3d561fe95de284ced3010819a +0 -0
  61. data/scenarios/git_repositories/config.git/objects/6b/bc79311bfac47d3ed724aa82a4814e0dda4c67 +0 -0
  62. data/scenarios/git_repositories/config.git/objects/71/eb5df52676e8e6efba471050b46978173af110 +1 -0
  63. data/scenarios/git_repositories/config.git/objects/84/17d2fe3e8fcc0825249c517b29b0f9ea8b8b31 +2 -0
  64. data/scenarios/git_repositories/config.git/objects/8b/384fcfcf7c0dee7c3c1d5636bee9e645d9cf38 +0 -0
  65. data/scenarios/git_repositories/config.git/objects/bb/59da633ba74296b0c2f9ff70784ac155ddb599 +0 -0
  66. data/scenarios/git_repositories/config.git/objects/cc/b86b26189afbf45d8eb9165812ab86dbdfca63 +0 -0
  67. data/scenarios/git_repositories/config.git/objects/d1/0bcd51fec41f854001e4d61f99d9e282a695d3 +0 -0
  68. data/scenarios/git_repositories/config.git/objects/d8/a8b0f5b1fd66844efb141d9544965ea0065f2d +0 -0
  69. data/scenarios/git_repositories/config.git/objects/e6/b02c66ad632e6b8535c4630cb8fe07732a72fc +0 -0
  70. data/scenarios/git_repositories/config.git/objects/e8/b8bfeeba735c0a1a873082554cb4d7256ac125 +0 -0
  71. data/scenarios/git_repositories/config.git/objects/f9/0181466a1a60b793ca9cc9abd584c18d4e3887 +0 -0
  72. data/scenarios/git_repositories/config.git/objects/f9/49d5d8a4f12c91471e34d4e277239c35ebd10d +0 -0
  73. data/scenarios/git_repositories/config.git/refs/heads/master +1 -0
  74. data/scenarios/git_repositories/project.git/HEAD +1 -0
  75. data/scenarios/git_repositories/project.git/config +5 -0
  76. data/scenarios/git_repositories/project.git/description +1 -0
  77. data/scenarios/git_repositories/project.git/git-daemon-export-ok +0 -0
  78. data/scenarios/git_repositories/project.git/hooks/applypatch-msg.sample +15 -0
  79. data/scenarios/git_repositories/project.git/hooks/commit-msg.sample +24 -0
  80. data/scenarios/git_repositories/project.git/hooks/post-commit.sample +8 -0
  81. data/scenarios/git_repositories/project.git/hooks/post-receive.sample +15 -0
  82. data/scenarios/git_repositories/project.git/hooks/post-update.sample +8 -0
  83. data/scenarios/git_repositories/project.git/hooks/pre-applypatch.sample +14 -0
  84. data/scenarios/git_repositories/project.git/hooks/pre-commit.sample +46 -0
  85. data/scenarios/git_repositories/project.git/hooks/pre-rebase.sample +169 -0
  86. data/scenarios/git_repositories/project.git/hooks/prepare-commit-msg.sample +36 -0
  87. data/scenarios/git_repositories/project.git/hooks/update.sample +128 -0
  88. data/scenarios/git_repositories/project.git/info/exclude +6 -0
  89. data/scenarios/git_repositories/project.git/objects/04/26e152e66c8cd42974279bdcae09be9839c172 +0 -0
  90. data/scenarios/git_repositories/project.git/objects/04/f4de85eaf72ef1631dc6d7424045c0a749b757 +1 -0
  91. data/scenarios/git_repositories/project.git/objects/06/13fe277280cbcdb2856e1eefc70bdaff011b20 +0 -0
  92. data/scenarios/git_repositories/project.git/objects/06/7aca89b86265eee211387434c3e50f37ccf009 +0 -0
  93. data/scenarios/git_repositories/project.git/objects/09/445dacc4822722612d60833c9948219ecdd8f5 +0 -0
  94. data/scenarios/git_repositories/project.git/objects/11/c4ec64326de35462f4e79d0f4229bf8e26e0c5 +0 -0
  95. data/scenarios/git_repositories/project.git/objects/20/1c7641c2e42b0b904e5c1f793489d8b858e4da +2 -0
  96. data/scenarios/git_repositories/project.git/objects/23/979639da60d2d31e9744468df1c1221b101e64 +0 -0
  97. data/scenarios/git_repositories/project.git/objects/27/a3fff2c4c45ab5513a405f694c0a042cb5d417 +1 -0
  98. data/scenarios/git_repositories/project.git/objects/2c/0c33cfba8e1af15df88522c0db2b10a6a94138 +2 -0
  99. data/scenarios/git_repositories/project.git/objects/38/b574660305ecb5fec6b2daa7ee1e0dbf1b6003 +0 -0
  100. data/scenarios/git_repositories/project.git/objects/4a/57abb5e4e426cfc9101b3af22ac83ccbd8e2ad +0 -0
  101. data/scenarios/git_repositories/project.git/objects/4c/77ebdd985e57afe7988480720c5dc77ec525c9 +0 -0
  102. data/scenarios/git_repositories/project.git/objects/51/c94da6f1b8aa9d2346088d3d362475b60c7f32 +0 -0
  103. data/scenarios/git_repositories/project.git/objects/5b/a96acf9cc9b87babe37c032676f53bf1ba9ae7 +2 -0
  104. data/scenarios/git_repositories/project.git/objects/5d/f555601d60f1c2a84d2364af0ad640612c3ba5 +0 -0
  105. data/scenarios/git_repositories/project.git/objects/71/03b5ac94940d596c2160a5cfcd55ca4ccac41f +0 -0
  106. data/scenarios/git_repositories/project.git/objects/73/3fc331098b03523f414f3509b9ae6e637c6866 +0 -0
  107. data/scenarios/git_repositories/project.git/objects/80/26076649ceccbe96a6292f2432652f08483035 +0 -0
  108. data/scenarios/git_repositories/project.git/objects/86/d1ef0976be4567de562224e1b51fbf9820c53a +1 -0
  109. data/scenarios/git_repositories/project.git/objects/87/a9d8b09b3401d21b23d90253332d6b28b47db2 +0 -0
  110. data/scenarios/git_repositories/project.git/objects/8b/030ba688255c917d189ae3f87d7c5ccd226bc2 +0 -0
  111. data/scenarios/git_repositories/project.git/objects/95/c9d5ad9b1c90e4c805516783105fc2037dedeb +2 -0
  112. data/scenarios/git_repositories/project.git/objects/95/d82d043af35a80eabfd56c0d705abfa3488787 +2 -0
  113. data/scenarios/git_repositories/project.git/objects/96/0bf34bb0b46d0aeb0be87f688f4ef06a4b35e1 +0 -0
  114. data/scenarios/git_repositories/project.git/objects/a3/860106dc1d148c7831cd45ae38829b4ed47702 +2 -0
  115. data/scenarios/git_repositories/project.git/objects/a8/506d6439b71784a72ac72d284b2ad53088f573 +0 -0
  116. data/scenarios/git_repositories/project.git/objects/ad/22ea6c7563777936ecfbe50d8e2cf8120fd525 +0 -0
  117. data/scenarios/git_repositories/project.git/objects/ae/3900de54aff557c61c81146d00f9d38e55a265 +1 -0
  118. data/scenarios/git_repositories/project.git/objects/bf/5e3740d52b80abb0378b3f85f93a53b1294521 +1 -0
  119. data/scenarios/git_repositories/project.git/objects/bf/b59811cdbc069418dee14b171e6e7e979784b7 +0 -0
  120. data/scenarios/git_repositories/project.git/objects/cc/5ac0afb24e727d5de344cc26a425f4fb7fd17d +3 -0
  121. data/scenarios/git_repositories/project.git/objects/d1/091aa2dd76885108461110c639e6b33a297fce +0 -0
  122. data/scenarios/git_repositories/project.git/objects/d8/913f6650eb2b7bf2a633732d8452008ca23dcb +0 -0
  123. data/scenarios/git_repositories/project.git/objects/db/d1b9667f1b26b13331ac0c321dced8be1aeab0 +3 -0
  124. data/scenarios/git_repositories/project.git/objects/e4/3b9107e9b1908ce415025e64eb83a493d329b7 +0 -0
  125. data/scenarios/git_repositories/project.git/objects/ef/2a88894d5421920b9dfe67a9a4d8043830e62e +0 -0
  126. data/scenarios/git_repositories/project.git/objects/f4/0123a1ff20c65d8dc15a38a83222647908e6f7 +0 -0
  127. data/scenarios/git_repositories/project.git/objects/f5/0af315b75ca0b12c720dec6d916b76b968c319 +0 -0
  128. data/scenarios/git_repositories/project.git/objects/f6/0215709b7b23f3738e9cbaf634b1c86bbd376a +0 -0
  129. data/scenarios/git_repositories/project.git/refs/heads/bad_rakefile +1 -0
  130. data/scenarios/git_repositories/project.git/refs/heads/hook_with_changed +1 -0
  131. data/scenarios/git_repositories/project.git/refs/heads/master +1 -0
  132. data/scenarios/git_repositories/project.git/refs/heads/no_rake_hooks +1 -0
  133. data/scenarios/git_repositories/project.git/refs/heads/post_rake_tasks +1 -0
  134. data/scenarios/invalid/deploy.yml +1 -0
  135. data/scenarios/local/deploy.yml.erb +17 -0
  136. data/scenarios/remote/deploy.yml +119 -0
  137. data/scenarios/setup/vagrant/.gitignore +3 -0
  138. data/scenarios/setup/vagrant/Vagrantfile +10 -0
  139. data/scenarios/setup/vagrant/manifests/integration.pp +32 -0
  140. data/scenarios/setup/vagrant/pids/.gitignore +1 -0
  141. data/spec/.bacon +0 -0
  142. data/spec/init_spec.rb +9 -0
  143. data/spec/install_spec.rb +43 -0
  144. data/spec/integration/branch_switching_spec.rb +41 -0
  145. data/spec/integration/deployment_failures_spec.rb +106 -0
  146. data/spec/integration/helper_spec.rb +90 -0
  147. data/spec/integration/invalid_configuration_spec.rb +39 -0
  148. data/spec/integration/local_deployments_spec.rb +230 -0
  149. data/spec/integration/post_rake_tasks_spec.rb +226 -0
  150. data/spec/integration/post_scripts_spec.rb +246 -0
  151. data/spec/integration/remote_deployments_spec.rb +166 -0
  152. data/spec/integration/staleness_checks_spec.rb +72 -0
  153. data/spec/spec_helper.rb +117 -0
  154. data/spec/wd_command_spec.rb +986 -0
  155. data/spec/wd_role_command_spec.rb +49 -0
  156. data/spec/whiskey_disk/config/filter_spec.rb +77 -0
  157. data/spec/whiskey_disk/config/filters/add_environment_name_filter_spec.rb +20 -0
  158. data/spec/whiskey_disk/config/filters/add_project_name_filter_spec.rb +19 -0
  159. data/spec/whiskey_disk/config/filters/check_for_duplicate_domains_filter_spec.rb +29 -0
  160. data/spec/whiskey_disk/config/filters/convert_role_strings_to_list_filter_spec.rb +48 -0
  161. data/spec/whiskey_disk/config/filters/default_config_target_filter_spec.rb +19 -0
  162. data/spec/whiskey_disk/config/filters/default_domain_filter_spec.rb +18 -0
  163. data/spec/whiskey_disk/config/filters/drop_empty_domain_roles_filter_spec.rb +60 -0
  164. data/spec/whiskey_disk/config/filters/environment_scope_filter_spec.rb +32 -0
  165. data/spec/whiskey_disk/config/filters/hashify_domain_entries_filter_spec.rb +41 -0
  166. data/spec/whiskey_disk/config/filters/localize_domains_filter_spec.rb +30 -0
  167. data/spec/whiskey_disk/config/filters/normalize_ssh_options_filter_spec.rb +56 -0
  168. data/spec/whiskey_disk/config/filters/project_scope_filter_spec.rb +75 -0
  169. data/spec/whiskey_disk/config/filters/select_project_and_environment_filter_spec.rb +30 -0
  170. data/spec/whiskey_disk/config/filters/stringify_hash_keys_filter_spec.rb +40 -0
  171. data/spec/whiskey_disk/config_spec.rb +754 -0
  172. data/spec/whiskey_disk/helpers_spec.rb +443 -0
  173. data/spec/whiskey_disk/rake_spec.rb +261 -0
  174. data/spec/whiskey_disk_spec.rb +1224 -0
  175. data/tasks/deploy.rake +2 -0
  176. data/whisk_deploy.gemspec +215 -0
  177. metadata +242 -0
@@ -0,0 +1,292 @@
1
+
2
+ 0.6.24 / 2011-10-05
3
+ ==================
4
+
5
+ * fix hashify_domain_filter for ruby 1.9.2 (closes issue #29)
6
+
7
+ 0.6.23 / 2011-09-29
8
+ ==================
9
+
10
+ * Fix incompatibility with latest jeweler (Rakefile error messages) [James Cox (imajes)]
11
+ * We now use vagrant for integration specs.
12
+ * Make rsync_changes more robust
13
+ * Add ERB support to YAML files used in integration specs
14
+ * add per-domain ssh_options support to config files
15
+ * Big refactoring of config handling into a filter stream architecture
16
+
17
+ 0.6.22 / 2011-04-10
18
+ ==================
19
+
20
+ * support branch-switching on deployments
21
+ * added integration spec for "branch switching" behavior
22
+
23
+ 0.6.21 / 2011-04-06
24
+ ==================
25
+
26
+ * change rsync changes capturing mechanism to be more portable
27
+ * upgrade integration spec to test rsync/#changed?/config repo
28
+ * helpers spec now tests root path rsync changes
29
+ * deploy.yml to test rsync changes w/ config repo
30
+ * integration spec project and config changes to stored git repos
31
+
32
+ 0.6.20 / 2011-04-06
33
+ ==================
34
+
35
+ * Output the entire command before running it when debugging.
36
+ * more anal git checkouts on clones to support older gits
37
+ * abort instead of raising in wd
38
+ * Neuter commandline output in wd command spec
39
+ * Make #changes work on setup
40
+ * Allow enabling debugger in specs w/ non-empty ENV['debug']
41
+ * Fix setup #changed? integration specs
42
+ * Improve example text for deployment #changed? integration specs
43
+ * Factor out snapshotting of git revision from WD.initialize_git_changes
44
+ * Fix the direction of the setup #changed? integration spec test
45
+ * Fixing jump_to_initial_commit spec helper
46
+ * Helper integration spec should use the correct branch when setting up.
47
+ * adjust env testing in integration specs
48
+ * update some specs to work with updated checkout/setup helpers
49
+ * use branches in integration checks so full checkouts will work
50
+ * when initializing git changes data, work from deployment path
51
+ * allow integration spec checkouts to switch to a specific branch
52
+ * record git changes for later use by #changed?
53
+ * capture rsync changes for later #changed? analysis
54
+ * capture initial git HEAD ref for later #changes comparisons
55
+ * clean out any prior git/rsync changes data before refreshing repos
56
+ * Add specs for version command-line argument
57
+ * Change spec helper run_command method set pwd to bin/
58
+ * integration spec for #changed? in post_setup tasks
59
+ * adding #changed? helper (and friends) to whiskey_disk/helpers
60
+ * spec_helper method to rewind a git repo to the beginning
61
+ * git project scenario changes to support integration testing of #changes helper
62
+ * refactor: splitting up WD.summarize method
63
+ * README updates for #changed? helper functionality
64
+
65
+
66
+ 0.6.17 / 2011-03-25
67
+ ==================
68
+
69
+ * updating contributor info in README
70
+ * updating specs to pass under new --debug regime
71
+ * deployment status message shouldn't appear in spec run output
72
+ * Refactoring WhiskeyDisk.reset in whiskey_disk_spec.rb
73
+ * spec helper should keep debugging on for test runs
74
+ * Make deployment status message more readable
75
+ * Only run post deploy|setup script with -x in debug mode
76
+ * Only rake --trace in debug mode
77
+ * Suppressing git output unless debug mode
78
+ * Adding log mesage for rsync configuration
79
+ * Only show rsync verbose and progress if debug enabled
80
+ * Print out a log message to indicate which host is currently being deployed
81
+ * Only run set -x in debug mode, also don't use bash -c
82
+ * Refactor a spec to use build_command directly
83
+ * Fix spec description for ENV['debug']
84
+ * Only run ssh with -v if in debug mode
85
+ * Refactor run to use a #ssh command
86
+ * Add WhiskeyDisk::Config.debug?
87
+ * Add -d, --debug to bin/wd
88
+ * change raise to abort for cleaner help output when doing `wd -h`
89
+ * change raise to abort for cleaner help output
90
+ * add --version option to wd
91
+ * Add support section to README
92
+
93
+
94
+ 0.6.16 / 2011-03-08
95
+ ==================
96
+
97
+ * Turning off shallow clones for 'wd setup'
98
+ * minor refactoring of new checkout functionality
99
+ * check out the specified branch on setup
100
+ * adding integration specs to test setup + deploy at once
101
+ * tweaking a couple of old path specs
102
+
103
+ 0.6.15 / 2011-03-07
104
+ ==================
105
+
106
+ * integration specs for "git checkout #{branch}" functionality
107
+ * adding scenario to test git checkout on non-master branches
108
+ * Adding current_branch integration spec helper method
109
+ * Ensure specified branch is checked out before applying the refresh
110
+
111
+ 0.6.14 / 2011-02-23
112
+ ==================
113
+
114
+ * forcing bash as the execution shell
115
+
116
+ 0.6.13 / 2011-02-20
117
+ ==================
118
+
119
+ * pass rake_env settings to post_* scripts
120
+ * Finish basic integration specs for post_* scripts
121
+ * should fail when post_* scripts are specified but missing
122
+ * basic integration specs for post_* scripts
123
+ * updating integration spec git repo data
124
+
125
+ 0.6.12 / 2011-02-20
126
+ ==================
127
+
128
+ * bad Rakefile should cause deployment to fail
129
+ * post_* rake task specs
130
+ * new scenarios to use when testing post_* rake hooks
131
+ * adding a dump_log helper to use when developing integration specs
132
+
133
+ 0.6.11 / 2011-02-18
134
+ ==================
135
+
136
+ * Generate an error message when we can't find --to proj/env in a config
137
+ * Fixing typo in an integration spec's example text
138
+
139
+ 0.6.10 / 2011-02-08
140
+ ==================
141
+
142
+ * reorganizing integration specs
143
+ * adding a quick README on how to run integration specs
144
+ * adding a remote deployment integration spec
145
+ * working around permissioning issues to support "remote" integration specs
146
+ * integration specs for non-matching --only deployment
147
+ * make sure the integration test is actually testing the local library
148
+ * fixing 'unit@' --only local deployment WD.remote? bug
149
+ * Adding initial integration spec suite
150
+ * save +x chmod state to bin/wd
151
+ * adding --only support to wd binary
152
+ * an ENV['only'] domain should deploy locally
153
+ * adding support for ENV['none'] to WhiskeyDisk, ::Config
154
+ * WD.fetch now iterates over all domains, local or remote
155
+ * reorganizing specs
156
+ * make it an error for a domain to appear more than once in a given project/target
157
+ * changing internal :domain representation
158
+ * WhiskeyDisk.remote? now takes a domain argument
159
+ * can now specify path to deploy.yml info using an URL
160
+
161
+ 0.6.4 / 2011-01-26
162
+ ==================
163
+
164
+ * bugfix: cd to deploy_to path before running post_{setup,deploy}_script
165
+
166
+ 0.6.3 / 2011-01-13
167
+ ==================
168
+
169
+ * adding support for config_target in deploy.yml
170
+
171
+ 0.6.2 / 2010-12-23
172
+ ==================
173
+
174
+ * update multiple deployment example to use roles
175
+ * new wd_role command for checking membership in a role from shell scripts
176
+ * adding #role? method in whiskey_disk/helpers for role-based rake tasks
177
+ * pass domain roles along as env variables when running ssh commands
178
+ * domain data now includes role information when available
179
+ * internal representation of 'domain' is now a list of hashes
180
+ * refactoring of config domain normalization code
181
+ * adding domain examples for config specs
182
+ * removing unnecessary describe blocks from config spec
183
+ * reordering domain config spec setup data structure for readability
184
+
185
+
186
+ 0.6.0 / 2010-12-22
187
+ ==================
188
+
189
+ * adding a set of multi-domain examples
190
+ * adding a local deployment example
191
+ * updating output summary to be more readable
192
+ * rake exit statuses reflect overall deployment/setup success
193
+ * adding WhiskeyDisk.success? method
194
+ * We now summarize runs, both local and remote.
195
+ * record results for local runs as well as remote ones
196
+ * now run SSH commands on multiple domains, serially, synchronously
197
+ * propagating changes allowed by normalizing 'domain' in config data
198
+ * normalize 'domain' values pulled from config files
199
+ * refactor config file writing in config spec
200
+ * WD.remote? now understands arrays of 'domain' entries in the config
201
+
202
+ 0.5.4
203
+ ==================
204
+
205
+ * Removing Jeweler warning from Rakefile
206
+ * eliminating more stubbing specs from config_spec
207
+ * Removing more stub! calls from config specs
208
+ * removing YAML.load exception stub
209
+ * replacing some configuration_data stubs in config spec
210
+ * Remove CURRENT_FILE from config specs
211
+ * Removing CURRENT from config specs
212
+ * Removing more File.exists? stubs from config spec.
213
+ * Removing File.exists? stubs in config specs
214
+ * spec refactorings
215
+ * Removing has_config_repo? stubs from rake specs
216
+ * Using non-stubbed configuration in rake specs
217
+ * removing useless stub of :register_configuration
218
+ * And removing unneeded spec helper
219
+ * removing whiskey_disk config stubbing
220
+ * introducing use_config() spec helper
221
+
222
+ 0.5.3
223
+ ==================
224
+
225
+ * Cosmetic and naming change in new config method
226
+ * fixing spec example description
227
+ * Reworking the config to append project name overrides to the env, since everything else is dependent thereupon
228
+ * tidying up the spec
229
+ * Allowing a manually specified project name in the bare config hash to be used as the parent project in the absence of one specified from the 'to' env setting
230
+
231
+ 0.5.2
232
+ ==================
233
+
234
+ * Adding --check flag to wd command-line script
235
+ * Making shallow clones on initial setup
236
+
237
+ 0.5.0
238
+ ==================
239
+
240
+ * Make the rake test task do right by bacon
241
+ * Adding post_setup_script support
242
+ * Adding post_deploy_script support
243
+ * Reordering specs for post-setup/deployment tasks
244
+
245
+ 0.4.5
246
+ ==================
247
+
248
+ * ENV settings now available to rake when searching for tasks
249
+ * refactoring common code for rake tasks
250
+ * further refactoring of clone_repository
251
+ * refactoring update checkout methods
252
+ * renaming conditional_clone
253
+ * Refactoring rake task code
254
+
255
+ 0.4.4
256
+ ==================
257
+
258
+ * README updates
259
+
260
+ 0.4.3
261
+ ==================
262
+
263
+ * Smarter setups
264
+
265
+ 0.4.2
266
+ ==================
267
+
268
+ * Taking a different approach to rake task detection
269
+
270
+ 0.4.1
271
+ ==================
272
+
273
+ * Fixing post_* hook edge case
274
+
275
+ 0.4.0
276
+ ==================
277
+
278
+ * Make the staleness check actually work with bash.
279
+ * Adding "else" block to provide feedback when not stale
280
+ * More complete implementation of staleness checks
281
+ * Removing earlier abortive implementation of staleness checking
282
+ * Support for staleness checks
283
+ * Adding first pass at conditional staleness checks
284
+
285
+ 0.3.1
286
+ ==================
287
+
288
+ * No longer require a Rakefile when --path isn't used
289
+ * We no longer do per-target config file overrides
290
+ * Don't run post_{setup,deploy} rake tasks without a deployed Rakefile
291
+ * encoding < and >
292
+ * adding a check flag for use with staleness checks
@@ -0,0 +1,20 @@
1
+ Copyright (c) 2009, Flawed Logic, OG Consulting, Rick Bradley.
2
+
3
+ Permission is hereby granted, free of charge, to any person obtaining
4
+ a copy of this software and associated documentation files (the
5
+ "Software"), to deal in the Software without restriction, including
6
+ without limitation the rights to use, copy, modify, merge, publish,
7
+ distribute, sublicense, and/or sell copies of the Software, and to
8
+ permit persons to whom the Software is furnished to do so, subject to
9
+ the following conditions:
10
+
11
+ The above copyright notice and this permission notice shall be
12
+ included in all copies or substantial portions of the Software.
13
+
14
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
15
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
16
+ MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
17
+ NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
18
+ LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
19
+ OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
20
+ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
@@ -0,0 +1,24 @@
1
+ Running Integration Specs
2
+ -------------------------
3
+
4
+ To run the integration spec suite you need to be able to run a Vagrant virtual machine (see: http://vagrantup.com/), which means you will have to have VirtualBox installed. The Vagrant/VirtualBox setup is currently out of the scope of this document. By default, I have been using the lucid32 box as my "base" box.
5
+
6
+ Once you are set up to be able to run Vagrant, you can create and start up an integration environment by running the following rake task:
7
+
8
+ % rake integration:up
9
+
10
+ This will create a vagrant VM, and so may take a few minutes to complete.
11
+
12
+
13
+ To run the integration specs once the integration environment is up:
14
+
15
+ % export INTEGRATION=true
16
+ % rake
17
+
18
+ To shut down the integration VM and the integration git-daemon server:
19
+
20
+ % rake integration:down
21
+
22
+ To completely remove the integration spec VM (which can take up a good bit of space on disk), do:
23
+
24
+ % rake integration:destroy
@@ -0,0 +1,832 @@
1
+ ## Whisk Deploy -- embarrassingly fast deployments. ##
2
+
3
+ I am forking whiskey\_disk under this project in attempt to catch the project up. The author is 10-12 months behind the projects maintenance and I contacted him. He is unsure of when he will be able to put more time into the whiskey\_disk project. So for now, this is my attempt to keep the project going in his absence.
4
+
5
+ A very opinionated deployment tool, designed to be as fast as technologically possible. (For more background, read the [WHY.txt](http://github.com/jesseadams/whisk/raw/master/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.
6
+
7
+ You can right-arrow through a talk on the design process of whisk, given at the 2011 Madison Ruby Conference (as well as the Ruby Hoedown), entitled "Free Whiskey" by going to [http://madisonruby.rickbradley.com](http://madisonruby.rickbradley.com) (slide source available [here](http://github.com/rick/madison_free_whiskey)).
8
+
9
+ Or... right-arrow through a short whisk presentation at [http://wd2010.rickbradley.com/](http://wd2010.rickbradley.com) (slide source available [here](http://github.com/rick/whisk_presentation).), covering the 0.2.*-era functionality.
10
+
11
+ You can also right-arrow through a shorter but more up-to-date whisk "lightning talk" presentation (from the 2010 Ruby Hoedown) at [http://wdlightning.rickbradley.com/](http://wdlightning.rickbradley.com) (slide source available [here](http://github.com/rick/whisk_presentation/tree/lightning).), covering the 0.4.*-era functionality.
12
+
13
+ ### tl;dr ###
14
+
15
+ First:
16
+
17
+ % gem install whisk_deploy
18
+
19
+
20
+ Then make a deploy.yml file (in config/ if you're doing a Rails project):
21
+
22
+ staging:
23
+ domain: "deployment_user@staging.mydomain.com"
24
+ deploy_to: "/path/to/where/i/deploy/staging.mydomain.com"
25
+ repository: "https://github.com/username/project.git"
26
+ branch: "staging"
27
+ rake_env:
28
+ RAILS_ENV: 'production'
29
+
30
+ then:
31
+
32
+ % wd setup --to=staging
33
+
34
+ then:
35
+
36
+ % wd deploy --to=staging
37
+
38
+
39
+ ### Selling points ###
40
+
41
+ - If you share the same opinions as we do there's almost no code involved, almost no
42
+ dependencies, and it uses stock *nix tools (ssh, bash, rsync) to get
43
+ everything done.
44
+
45
+ - Written completely spec-first for 100% coverage. We even did that for the
46
+ rake tasks, the init.rb and the plugin install.rb (if you swing that way).
47
+
48
+ - 1 ssh connection per run -- so everything needed to do a full setup
49
+ is done in one shot. Everything needed to do a full deployment is done in
50
+ one shot. (Having 8 minute deploys failing because I was on CDMA wireless on a
51
+ train in India where the connection won't stay up for more than 2-3 minutes is
52
+ not where I want to be any more.)
53
+
54
+ - Deployment configuration is specified as YAML data, not as code.
55
+ Operations to perform after setup or deployment are specified as rake
56
+ tasks.
57
+
58
+ - You can do *local* deployments, by this I mean you can use whisk\_deploy to
59
+ deploy fully running instances of your application to the same machine
60
+ you're developing on. This turns out to be surprisingly handy (well, I was
61
+ surprised). *NOTE*: be sure to set your deploy_to to a place other than the
62
+ current local checkout.
63
+
64
+ - You can do multi-project deployments, specifying deployment data in a single
65
+ deploy.yml config file, or keep an entire directory of project deployment config files.
66
+
67
+ - You can separate per-deployment application configuration information (e.g., passwords,
68
+ database configs, hoptoad/AWS/email config data, etc.) in separate repositories from
69
+ the application, and whisk\_deploy will merge the correct data onto the deployed
70
+ application at deployment time. You can even share sets of configuration files among
71
+ deployment targets that behave alike.
72
+
73
+ - You can have per-developer configurations for targets (especially
74
+ useful for "local" or "development" targets). Use .gitignore, or
75
+ specify a config_branch and everyone can have their own local setup that just
76
+ works.
77
+
78
+ - There's no before\_after\_before_after hooks. You can use a well-defined rake hook and/or a
79
+ bash script to run additional tasks.
80
+
81
+ - You can enable "staleness checks" so that deployments only happen if
82
+ either the main repo, or the config repo (if you're using one) has
83
+ changes that are newer than what is currently deployed.
84
+
85
+ - Put whisk\_deploy in a cron, with staleness checks enabled, and you can
86
+ do hands-free automated deployments whenever code is pushed to your
87
+ deployment branch of choice!
88
+
89
+ - You can deploy to multiple remote targets at once. Currently this is limited
90
+ to one-after-the-other synchronous deployments, but we're thinking about
91
+ doing them in parallel once we're happy with the stability of this feature.
92
+
93
+ - Assign hosts to roles (e.g., "web", "db", "app") and vary the shell or rake
94
+ post-setup/post-deploy actions you run based on those roles.
95
+
96
+ - Limit the actions you run after deployment based on whether files of interest
97
+ *actually changed*.
98
+
99
+ ### Assumptions ###
100
+
101
+ - your project is managed via git
102
+ - you are deploying over ssh, or deploying locally and have a bash-compatible shell
103
+ - you are comfortable defining (optional) post-setup and post-deployment actions with rake
104
+ - you have an optional second git repository for per-application/per-target configuration files
105
+ - you have an optional Rakefile in the top directory of your project's checkout
106
+
107
+ ### Dependencies ###
108
+
109
+ On the server from which the whisk\_deploy process will be kicked off:
110
+
111
+ - ruby
112
+ - rake
113
+ - whisk\_deploy
114
+ - ssh (if doing a remote deployment).
115
+
116
+ On the deployment target server (which may be the same as the first server):
117
+
118
+ - a bash-compatible shell
119
+ - rsync (only if using a configuration repository)
120
+ - ruby, rake, whisk\_deploy (only if running post\_setup or post\_deploy hooks)
121
+
122
+ If you're running on OS X or Linux you probably have all of these installed already. Note that the deployment target system doesn't even have to have ruby installed unless post\_* rake hooks are being run.
123
+
124
+ ### Installation ###
125
+
126
+ As a gem:
127
+
128
+ % gem install whisk\_deploy
129
+
130
+ ### Configuration ###
131
+
132
+ - look in the examples/ directory for sample configuration files
133
+ - main configuration is in &lt;app_root&gt;/config/deploy.yml
134
+ - config files are YAML, with a section for each target.
135
+
136
+ Known config file settings (if you're familiar with capistrano and vlad these should seem eerily familiar):
137
+
138
+ domain: host or list of hosts on which to deploy (these are ssh connect strings)
139
+ can also optionally include role information for each host
140
+ deploy_to: path to which to deploy main application
141
+ repository: git repo path for main application
142
+ branch: git branch to deploy from main application git repo (default: master)
143
+ deploy_config_to: where to deploy the configuration repository
144
+ config_repository: git repository for configuration files
145
+ config_branch: git branch to deploy from configuration git repo (default: master)
146
+ config_target: configuration repository target path to use
147
+ project: project name (used to compute path in configuration checkout)
148
+ post_deploy_script: path to a shell script to run after deployment
149
+ post_setup_script: path to a shell script to run after setup
150
+ rake_env: hash of environment variables to set when running post_setup and post_deploy rake tasks
151
+ rake_command: command to invoke rake with (default: rake)
152
+
153
+
154
+ A simple config/deploy.yml might look like:
155
+
156
+ qa:
157
+ domain: "ogc@qa.ogtastic.com"
158
+ deploy_to: "/var/www/www.ogtastic.com"
159
+ repository: "git@ogtastic.com:www.ogtastic.com.git"
160
+ branch: "stable"
161
+ rake_env:
162
+ RAILS_ENV: 'production'
163
+
164
+ - defining a deploy:&lt;target&gt;:post_setup rake task (e.g., in lib/tasks/
165
+ or in your project's Rakefile) will cause that task to be run at the end
166
+ of deploy:setup
167
+
168
+ - defining a deploy:&lt;target&gt;:post_deploy rake task (e.g., in
169
+ lib/tasks/ or in your project's Rakefile) will cause that task to be run
170
+ at the end of deploy:now
171
+
172
+ It's easy to specify a local deployment. The simplest way is to just not specify a "domain":
173
+
174
+ local:
175
+ deploy_to: "/var/www/www.ogtastic.com"
176
+ repository: "git@ogtastic.com:www.ogtastic.com.git"
177
+ branch: "stable"
178
+ rake_env:
179
+ RAILS_ENV: 'production'
180
+
181
+
182
+ Or, just specify the string 'local' as the domain:
183
+
184
+ local:
185
+ domain: "local"
186
+ deploy_to: "/var/www/www.ogtastic.com"
187
+ repository: "git@ogtastic.com:www.ogtastic.com.git"
188
+ branch: "stable"
189
+ rake_env:
190
+ RAILS_ENV: 'production'
191
+
192
+
193
+ For deploying to multiple hosts, the config/deploy.yml might look like:
194
+
195
+ qa:
196
+ domain:
197
+ - "ogc@qa1.ogtastic.com"
198
+ - "ogc@qa2.ogtastic.com""
199
+ deploy_to: "/var/www/www.ogtastic.com"
200
+ repository: "git@ogtastic.com:www.ogtastic.com.git"
201
+ branch: "stable"
202
+ rake_env:
203
+ RAILS_ENV: 'production'
204
+
205
+
206
+ You can even include a local deployment along with remote deployments, simply use the 'local' name:
207
+
208
+ qa:
209
+ domain:
210
+ - "local"
211
+ - "ogc@qa2.ogtastic.com""
212
+ deploy_to: "/var/www/www.ogtastic.com"
213
+ repository: "git@ogtastic.com:www.ogtastic.com.git"
214
+ branch: "stable"
215
+ rake_env:
216
+ RAILS_ENV: 'production'
217
+
218
+
219
+ If you need special flags passed to ssh for a given domain, specify an array of `ssh_options` flags:
220
+
221
+ qa:
222
+ domain:
223
+ - name: "ogc@qa.ogtastic.com"
224
+ ssh_options:
225
+ - "-t"
226
+ - "-vv"
227
+ - "-p 443"
228
+ deploy_to: "/var/www/www.ogtastic.com"
229
+ repository: "git@ogtastic.com:www.ogtastic.com.git"
230
+
231
+ ### Specifying domains, with or without roles ###
232
+
233
+ There are a number of ways to specify domains (the ssh connection strings denoting the hosts
234
+ where your code will be deployed). Here are just a few examples:
235
+
236
+ Just a single domain:
237
+
238
+ staging:
239
+ domain: "foo@staging.example.com"
240
+
241
+ Just a single domain, but specified as a one-item list:
242
+
243
+ qa:
244
+ domain:
245
+ - "foo@qa.example.com"
246
+
247
+ A list of multiple domains:
248
+
249
+ production:
250
+ domain:
251
+ - "foo@appserver1.example.com"
252
+ - "foo@appserver2.example.com"
253
+ - "foo@www.example.com"
254
+
255
+ Using the "name" label for the domain names (if using roles, as described below, the "name" label is required,
256
+ otherwise it's optional and superfluous):
257
+
258
+ ci:
259
+ domain:
260
+ - name: "build@ci.example.com"
261
+
262
+ It's also possible to assign various "roles" to the domains to which you deploy. Some common usages would be
263
+ "www", which might need a post\_deploy task which notifies some web server software (apache, nginx, passenger,
264
+ unicorn, etc.) that it should refresh the contents being served; or perhaps "db", which might need some set of
265
+ post-deployment database migrations run (and which shouldn't be run from multiple servers).
266
+
267
+ The role names are simply strings and you can create whichever roles you wish. See the section below entitled
268
+ "Taking actions based on roles" to see how to use roles to control actions when setting up or deploying to a
269
+ target.
270
+
271
+ Roles are described in the domain: section of the configuration file. There are, of course, a few different
272
+ valid ways to specify roles. Note that the domain name must now be labeled when roles are being specified
273
+ for the domain.
274
+
275
+ A single role for a domain can be specified inline:
276
+
277
+ production:
278
+ domain:
279
+ - name: "foo@appserver1.example.com"
280
+ roles: "web"
281
+
282
+ While multiple roles for a domain must be specified as a list:
283
+
284
+ production:
285
+ domain:
286
+ - name: "foo@appserver1.example.com"
287
+ roles:
288
+ - "web"
289
+ - "app"
290
+ - "db"
291
+
292
+ But domains with roles can be specified alongside simple domains as well:
293
+
294
+ production:
295
+ domain:
296
+ - name: "bar@demo.example.com"
297
+ - "user@otherhost.domain.com"
298
+ - name: "foo@appserver1.example.com"
299
+ roles:
300
+ - "web"
301
+ - "app"
302
+ - "db"
303
+
304
+
305
+ And, if you need to assign roles for a local deployment, you can do that as well:
306
+
307
+ local:
308
+ domain:
309
+ - name: "local"
310
+ roles:
311
+ - "web"
312
+ - "app"
313
+ - "db"
314
+
315
+
316
+ All that said, it's often simpler to refrain from carving up hosts into roles. But who's going to listen to reason?
317
+
318
+
319
+
320
+ ### post\_deploy\_script and post\_setup\_script ###
321
+
322
+ whisk\_deploy provides rake task hooks (deploy:post\_setup and deploy:post\_deploy) to allow running custom
323
+ code after setup or deployment. There are situations where it is desirable to run some commands prior to
324
+ running those rake tasks (e.g., if using bundler and needing to do a 'bundle install' before running rake).
325
+ It may also be the case that the target system doesn't have rake (and/or ruby) installed, but some post-setup
326
+ or post-deploy operations need to happen. For these reasons, whisk\_deploy allows specifying a (bash-compatible)
327
+ shell script to run after setup and/or deployment via the post\_deploy\_script and post\_setup\_script settings
328
+ in the configuration file. These scripts, when specified, are run immediately before running the deploy:post\_setup
329
+ or deploy:post\_deploy rake tasks, if they are present.
330
+
331
+ The paths provided to post\_deploy\_script and post\_setup\_script can be either absolute or relative. A path
332
+ starting with a '/' is an absolute path, and the script specified should be at that exact location on the
333
+ target filesystem. A path which does not start with a '/' is a relative path, and the script specified should
334
+ be located at the specified path under the deployed application path. This implies that it's possible to
335
+ manage post\_setup and post\_deploy scripts out of a configuration repository.
336
+
337
+ A config/deploy.yml using post\_deploy\_script and post\_setup\_script might look like this:
338
+
339
+ production:
340
+ domain: "ogc@www.ogtastic.com"
341
+ deploy_to: "/var/www/www.ogtastic.com"
342
+ repository: "git@ogtastic.com:www.ogtastic.com.git"
343
+ branch: "stable"
344
+ post_setup_script: "/home/ogc/horrible_place_for_this/prod-setup.sh"
345
+ post_deploy_script: "bin/post-deploy.sh"
346
+ rake_env:
347
+ RAILS_ENV: 'production'
348
+
349
+ The post\_deploy\_script will be run from /var/www/www.ogtastic.com/bin/post-deploy.sh on the
350
+ target system.
351
+
352
+
353
+ ### Taking actions based on roles ###
354
+
355
+ #### When running rake tasks or other ruby scripts ####
356
+
357
+ whisk\_deploy includes a helper library for use in rake tasks and other ruby scripts. In that library you'll
358
+ find a ruby function 'role?' which returns true if you're currently being deployed to a domain with the given
359
+ role. For example:
360
+
361
+ require 'whisk/helpers'
362
+
363
+ namespace :deploy do
364
+ task :create_rails_directories do
365
+ if role? :www
366
+ puts "creating log/ and tmp/ directories"
367
+ Dir.chdir(RAILS_ROOT)
368
+ system("mkdir -p log tmp")
369
+ end
370
+ end
371
+
372
+ task :db_migrate_if_necessary do
373
+ Rake::Task['db:migrate'] if role? :db
374
+ end
375
+
376
+ # whytf is this even necessary? Come on. This should be built into ts:restart.
377
+ task :thinking_sphinx_restart => [:environment] do
378
+ if role? :app
379
+ Rake::Task['ts:stop'].invoke rescue nil
380
+ Rake::Task['ts:index'].invoke
381
+ Rake::Task['ts:start'].invoke
382
+ end
383
+ end
384
+
385
+ task :bounce_passenger do
386
+ if role? :www
387
+ puts "restarting Passenger web server"
388
+ Dir.chdir(RAILS_ROOT)
389
+ system("touch tmp/restart.txt")
390
+ end
391
+ end
392
+
393
+ # etc...
394
+
395
+ task :post_setup => [ :create_rails_directories ]
396
+ task :post_deploy => [ :db_migrate_if_necessary, :thinking_sphinx_restart, :bounce_passenger ]
397
+ end
398
+
399
+
400
+ #### When working with the shell ####
401
+
402
+ Installing the whisk\_deploy gem also installs another binary, called wd_role. It's job is really simple,
403
+ given a role, determine if we're currently in a deployment that matches that role. If so, exit with a success
404
+ exit status, otherwise, exit with an error exit status. This allows programs running in the shell to conditionally
405
+ execute code based on domain roles. This is particularly applicable to post\_setup\_script and post\_deploy\_script
406
+ code.
407
+
408
+ Here's an off-the-cuff example of how one might use wd\_role. We have the rockhands gem installed (obviously), and
409
+ are in an environment where the 'app' role is active but the 'web' role is not:
410
+
411
+
412
+ $ wd_role web && rock || shocker
413
+ .-.
414
+ .-.U|
415
+ |U| | .-.
416
+ | | |_|U|
417
+ | | | | |
418
+ /| ` |
419
+ | | |
420
+ | |
421
+ \ /
422
+ | |
423
+ | |
424
+
425
+ $ wd_role app && rock || shocker
426
+ .-.
427
+ |U|
428
+ | | .-.
429
+ | |-._|U|
430
+ | | | | |
431
+ /| ` |
432
+ | | |
433
+ | |
434
+ /
435
+ | |
436
+ | |
437
+
438
+
439
+
440
+
441
+ ### Running whisk\_deploy from the command-line ###
442
+
443
+ % wd setup --to=<target>
444
+ % wd setup --to=<project>:<target>
445
+ % wd setup --to=foo:qa --path=/etc/whisk\_deploy/deploy.yml
446
+ % wd setup --to=foo:qa --path=https://github.com/username/project/raw/master/path/to/configs/deploy.yml
447
+ % wd setup --to=foo:qa --only=myhost.example.com
448
+
449
+ % wd deploy --to=<target>
450
+ % wd deploy --to=<project>:<target>
451
+ % wd deploy --to=foo:qa --path=/etc/whisk\_deploy/deploy.yml
452
+ % wd deploy --to=foo:qa --path=https://github.com/username/project/raw/master/path/to/configs/deploy.yml
453
+ % wd deploy --to=foo:qa --only=myhost.example.com
454
+
455
+ % wd --help
456
+ % wd --version
457
+
458
+
459
+
460
+ Also, `--debug` can be used to enable verbose output when running `wd setup` or `wd deploy`.
461
+
462
+ Note that the wd command (unlike rake, which requires a Rakefile in the current directory) can be run from anywhere, so you can deploy any project, working from any path, and can even specify where to find the deployment YAML configuration file.
463
+
464
+ The --path argument can take either a file or a directory. When given a file it will use that file as the configuration file. When given a directory it will look in that directory for deploy/&lt;project&gt;/&lt;target&gt;.yml, then deploy/&lt;project&gt;.yml, then deploy/&lt;target&gt;.yml, then &lt;target&gt;.yml, and finally, deploy.yml.
465
+
466
+ To make things even better, you can provide an URL as the --path argument and have a central location from which to pull deployment YAML data. This means that you can centrally administer the definitive deployment information for the various projects and targets you manage. This could be as simple as keeping them in a text file hosted on a web server, checking them into git and using github or gitweb to serve up the file contents on HEAD, or it could be a programmatically managed configuration management system returning dynamically-generated results.
467
+
468
+ All this means you can manage a large number of project deployments (local or remote) and have a single scripted deployment manager that keeps them up to date. Configurations can live in a centralized location, and developers don't have to be actively involved in ensuring code gets shipped up to a server. Win.
469
+
470
+ When doing scripted deployments for a group of nodes who appear in the same 'domain' list, it's possible to specify the --only setting so that you can identify which domain entries belong to a specific node. For example, given this configuration:
471
+
472
+
473
+ production:
474
+ domain:
475
+ - foo.example.com
476
+ - bar.example.com
477
+ repository: git@github.com:foo.git
478
+
479
+
480
+ We would like to be able to set up the following scripted runs on foo.example.com and bar.example.com:
481
+
482
+
483
+ foo% wd deploy --to=app:production --path=http://automation.example.com/wd/deploy.yml
484
+ bar% wd deploy --to=app:production --path=http://automation.example.com/wd/deploy.yml
485
+
486
+
487
+ But without specifying --only we end up with undesired results. When foo.example.com runs it will see that it needs to make sure deployment happens on 'foo.example.com' and 'bar.example.com'. So, wd will ssh from foo.example.com to foo.example.com (less than ideal), deploy, and then ... it will ssh from foo.example.com to bar.example.com and do a deployment. When bar.example.com runs, however, it will also ssh to bar.example.com, and also to foo.example.com. So each host will be deployed twice.
488
+
489
+ The --only setting is used to tell a node what its name is, and to tell it not to bother trying to deploy other nodes that it finds in the target's "domain" listing. In other words, deployment is being managed from afar, and it's best to just manage ourselves and forego managing other nodes.
490
+
491
+
492
+ ### A note about post\_{setup,deploy} Rake tasks
493
+
494
+ If you want actions to run on the deployment target after you do a whisk\_deploy setup or whisk\_deploy deploy,
495
+ you will need to make sure that whisk\_deploy is available on the target system (either by gem installation,
496
+ as a rails plugin in the Rails application to be deployed, or as a vendored library in the application to be
497
+ deployed). whisk\_deploy provides the basic deploy:post\_setup and deploy:post\_deploy hooks which get called.
498
+ You can also define these tasks yourself if you want to eliminate the dependency on whisk\_deploy on the
499
+ deployment target system.
500
+
501
+
502
+ ### Doing things when files of interest change ###
503
+
504
+ Do you want to run database migrations when no migrations have been added? Why bother compressing front-end assets when none of them have changed? Why restart your application server if only the project README changed? whisk\_deploy provides a `changed?` ruby helper method to allow you to decide whether to run expensive post deployment tasks, based on what files changed in the deployment. Typically this would happen in your rake tasks, but it could happen from regular ruby code as well.
505
+
506
+
507
+ require 'whisk/helpers'
508
+
509
+ namespace :deploy do
510
+
511
+ task :run_migrations do
512
+ if role?(:db) and changed?('db/migrate')
513
+ puts "Running database migrations..."
514
+ Rake::Task['db:migrate'].invoke
515
+ end
516
+ end
517
+
518
+ task :compress_assets do
519
+ if changed?('public/stylesheets') or changed?('public/javascripts')
520
+ puts "Getting my asset munge on..."
521
+ # do some expensive asset compression stuff
522
+ end
523
+ end
524
+
525
+ task :post_deploy => [ :run_migrations, :compress_assets ]
526
+ end
527
+
528
+
529
+
530
+ ### Running via rake ###
531
+
532
+ You can use rake tasks to do everything possible with whisk\_deploy (the `wd` command is just a front-end to the whisk\_deploy rake tasks). In your Rakefile:
533
+
534
+ require 'whisk/rake'
535
+
536
+ Then, from the command-line:
537
+
538
+ % rake deploy:setup to=<target> (e.g., "qa", "staging", "production", etc.)
539
+ % rake deploy:now to=<target>
540
+
541
+ or, specifying the project name:
542
+
543
+ % rake deploy:setup to=<project>:<target> (e.g., "foo:qa", "bar:production", etc.)
544
+ % rake deploy:now to=<project>:<target>
545
+
546
+ enabling staleness checking (see below):
547
+
548
+ % rake deploy:setup to=<project>:<target> check=yes
549
+ % rake deploy:now to=<project>:<target> check=yes
550
+
551
+ maybe even specifying the path to the configuration file:
552
+
553
+ % rake deploy:setup to=<project>:<target> path=/etc/deploy.yml
554
+ % rake deploy:now to=<project>:<target> path=/etc/deploy.yml
555
+
556
+ how about specifying the configuration file via URL:
557
+
558
+ % rake deploy:setup to=<project>:<target> path=https://github.com/username/project/raw/master/path/to/configs/deploy.yml
559
+ % rake deploy:now to=<project>:<target> path=https://github.com/username/project/raw/master/path/to/configs/deploy.yml
560
+
561
+ Finally, it's also possible to specify the 'only' variable to limit 'domain' entries of interest:
562
+
563
+ % rake deploy:setup to=<project>:<target> only=myhost.example.com
564
+ % rake deploy:now to=<project>:<target> only=myhost.example.com
565
+
566
+ (see the discussion of --only above in "Running whisk\_deploy from the command-line" for more information)
567
+
568
+
569
+ ### Staleness checks ###
570
+
571
+ Enabling staleness checking will cause whisk\_deploy to check whether the deployed checkout of the repository
572
+ is out of date ("stale") with respect to the upstream version in git. If there is a configuration repository
573
+ in use, whisk\_deploy will check the deployed checkout of the configuration repository for staleness as well.
574
+ If the checkouts are already up-to-date the deployment process will print an up-to-date message and stop rather
575
+ than proceeding with any of the deployment actions. This makes it easy to simply run whisk\_deploy out of cron
576
+ so that it will automatically perform a deployment whenever changes are pushed to the upstream git repositories.
577
+
578
+ To turn on staleness checking, simply specify the '--check' flag when deploying (or the shorter '-c')
579
+
580
+ wd deploy --check --to=foobar:production
581
+
582
+ If running whisk\_deploy purely via rake, you can also enable staleness checking. This works by setting the 'check'
583
+ environment variable to the string 'true' or 'yes':
584
+
585
+ % check='true' to='whisk\_deploy:testing' rake deploy:now
586
+
587
+
588
+ ### Configuration Repository ###
589
+
590
+ #### What's all this about a second repository for configuration stuff? ####
591
+
592
+ This is completely optional, but we really are digging this, so maybe
593
+ you should try it. Basically it goes like this...
594
+
595
+ We have a number of web applications that we manage. Usually there's a
596
+ customer, there might be third-party developers, or the customer might have
597
+ access to the git repo, or their designer might, etc. We also tend to run a
598
+ few instances of any given app, for any given customer. So, we'll run a
599
+ "production" site, which is the public- facing, world-accessible main site.
600
+ We'll usually also run a "staging" site, which is roughly the same code, maybe
601
+ the same data, running on a different URL, which the customer can look at to
602
+ see if the functionality there is suitable for deploying out to production. We
603
+ sometimes run a "development" site which is even less likely to be the same
604
+ code as production, etc., but gives visibility into what might end up in
605
+ production one day soon.
606
+
607
+ So we'll store the code for all of these versions of a site in the same git
608
+ repo, typically using a different remote branch for each target
609
+ ("qa", "production", "staging", "development").
610
+
611
+ One thing that comes up pretty quickly is that there are various files
612
+ associated with the application which have more to do with configuration of a
613
+ running instance than they have to do with the application in general. In the
614
+ rails world these files are probably in config, or config/initializers/. Think
615
+ database connection information, search engine settings, exception notification
616
+ plugin data, email configuration, Amazon S3 credentials, e-commerce back-end
617
+ configuration, etc.
618
+
619
+ We don't want the production site using the same database as the
620
+ development site. We don't want staging using (and re-indexing, re-starting,
621
+ etc.) production's search engine server. We don't want any site other than
622
+ production to send account reset emails, or to push orders out to fulfillment,
623
+ etc.
624
+
625
+ For some reason, the answer to this with cap and/or vlad has been to have
626
+ recipes which reference various files up in a shared area on the server, do
627
+ copying or symlinking, etc. Where did those files come from? How did they get
628
+ there? How are they managed over time? If they got there via a configuration
629
+ tool, why (a) are they not in the right place, or (b) do we have to do work to
630
+ get them into the right place?
631
+
632
+ So, we decided that we'd change how we deal with the issue. Instead of
633
+ moving files around or symlinking every time we deploy, we will manage the
634
+ configuration data just like we manage other files required by our projects --
635
+ with git.
636
+
637
+ So, each project we deploy is associated with a config repo in our git
638
+ repository. Usually many projects are in the same repo, because we're the only
639
+ people to see the data and there's no confidentiality issue. But, if a
640
+ customer has access to their git information then we'll make a separate config
641
+ repo for all that customers' projects. (This is easier to manage than it
642
+ sounds if you're using gitosis, btw.)
643
+
644
+ Anyway, a config repo is just a git repo. In it are directories for every
645
+ project whose configuration information is managed in that repo. For example,
646
+ there's a "larry" directory in our main config repo, because we're deploying
647
+ the [larry project](http://github.com/flogic/larry) to manage our high-level
648
+ configuration data.
649
+
650
+ Note, if you set the 'project' setting in deploy.yml, that determines the
651
+ name of the top-level project directory whisk\_deploy will hunt for in your
652
+ config repo. If you don't it uses the 'repository' setting (i.e., the git URL)
653
+ to try to guess what the project name might be. So if the URL ends in
654
+ foo/bar.git, or foo:bar.git, or /bar, or :bar, whisk\_deploy is going to guess
655
+ "bar". If it's all bitched up, just set 'project' manually in deploy.yml.
656
+
657
+ Inside the project directory is a directory named for each target we
658
+ might deploy to. Frankly, we've been using "production", "staging",
659
+ "development", and "local" on just about everything.
660
+
661
+ Inside the target directory is a tree of files. So, e.g., there's
662
+ config/, which has initializers/ and database.yml in it.
663
+
664
+ Long story short, load up whatever configuration files you're using into
665
+ the repo as described, and come deployment time exactly those files will be
666
+ overlaid on top of the most recent checkout of the project. Snap.
667
+
668
+ project-config/
669
+ |
670
+ +---larry/
671
+ |
672
+ +---production/
673
+ | |
674
+ | +---config/
675
+ | |
676
+ | +---initializers/
677
+ | |
678
+ | +---database.yml
679
+ |
680
+ +---staging/
681
+ | |
682
+ | |
683
+ | +---config/
684
+ | |
685
+ | ....
686
+ |
687
+ +---development/
688
+ | |
689
+ | +---config/
690
+ | |
691
+ | ....
692
+ |
693
+ +---local/
694
+ |
695
+ +---config/
696
+ |
697
+ ....
698
+
699
+
700
+ #### Sharing a set of configuration files among multiple targets ####
701
+
702
+ Developers on applications with many deployment targets can find that configuration repositories can become a burden to maintain, especially when a number of environments share essentially the same configurations. For example, for an application where deployments for user acceptance testing, QA, staging, and feature branch demoing are all essentially the same (though differing from production configurations and developer configurations), it's probably easiest to store a configuration for development, a configuration for production, a configuration for staging and then use the staging configuration for all the other environments: user acceptance testing, QA, staging, demo1, demo2, etc. Using the config\_target setting, a deploy.yml might look like this:
703
+
704
+
705
+ production:
706
+ domain: "www.ogtastic.com"
707
+ deploy_to: "/var/www/www.ogtastic.com"
708
+ repository: "git@ogtastic.com:www.ogtastic.com.git"
709
+ branch: "production"
710
+ config_repository: "git@ogtastic.com:ogc-production-config.git"
711
+ development:
712
+ deploy_to: '/var/www/devel.ogtastic.com'
713
+ repository: "git@ogtastic.com:www.ogtastic.com.git"
714
+ branch: "develop"
715
+ config_repository: "git@ogtastic.com:ogc-config.git"
716
+ staging:
717
+ [...]
718
+ config_repository: "git@ogtastic.com:ogc-config.git"
719
+ uat:
720
+ [....]
721
+ config_repository: "git@ogtastic.com:ogc-config.git"
722
+ config_target: "staging"
723
+ qa:
724
+ [....]
725
+ config_repository: "git@ogtastic.com:ogc-config.git"
726
+ config_target: "staging"
727
+
728
+
729
+ So here we have the 'staging', 'uat', and 'qa' deployment targets all sharing the 'staging' configuration repo information. The non-production configuration repo can then look like:
730
+
731
+
732
+ project-config/
733
+ |
734
+ +---ogtastic/
735
+ |
736
+ +---staging/
737
+ | |
738
+ | |
739
+ | +---config/
740
+ | |
741
+ | ....
742
+ |
743
+ +---development/
744
+ |
745
+ +---config/
746
+ |
747
+ ....
748
+
749
+
750
+ Notice that there are no separate trees for 'uat' and 'qa' targets.
751
+
752
+ ### More Examples: ###
753
+
754
+ - We are using whisk\_deploy to manage larry. See [https://github.com/flogic/larry/blob/master/config/deploy-local.yml.example](https://github.com/flogic/larry/blob/master/config/deploy-local.yml.example) and [http://github.com/flogic/larry/blob/master/lib/tasks/deploy.rake](http://github.com/flogic/larry/blob/master/lib/tasks/deploy.rake)
755
+
756
+ - Here is a sample of a lib/tasks/deploy.rake from a Rails application we deployed once upon a time:
757
+
758
+
759
+
760
+ RAILS_ENV=ENV['RAILS_ENV'] if ENV['RAILS_ENV'] and '' != ENV['RAILS_ENV']
761
+ Rake::Task['environment'].invoke
762
+
763
+ require 'asset_cache_sweeper'
764
+
765
+ namespace :deploy do
766
+ task :create_rails_directories do
767
+ puts "creating log/ and tmp/ directories"
768
+ Dir.chdir(RAILS_ROOT)
769
+ system("mkdir -p log tmp")
770
+ end
771
+
772
+ # note that the plpgsql language needs to be installed by the db admin at initial database creation :-/
773
+ task :setup_postgres_for_thinking_sphinx => [ :environment ] do
774
+ ThinkingSphinx::PostgreSQLAdapter.new(Product).setup
775
+ end
776
+
777
+ # whytf is this even necessary? Come on. This should be built into ts:restart.
778
+ task :thinking_sphinx_restart => [:environment] do
779
+ Rake::Task['ts:stop'].invoke rescue nil
780
+ Rake::Task['ts:index'].invoke
781
+ Rake::Task['ts:start'].invoke
782
+ end
783
+
784
+ task :bounce_passenger do
785
+ puts "restarting Passenger web server"
786
+ Dir.chdir(RAILS_ROOT)
787
+ system("touch tmp/restart.txt")
788
+ end
789
+
790
+ task :clear_asset_cache => [:environment] do
791
+ STDERR.puts "Expiring cached Assets for domains [#{AssetCacheSweeper.domains.join(", ")}]"
792
+ AssetCacheSweeper.expire
793
+ end
794
+
795
+ task :post_setup => [ :create_rails_directories, :setup_postgres_for_thinking_sphinx ]
796
+ task :post_deploy => [ 'db:migrate', 'ts:config', :thinking_sphinx_restart, :bounce_passenger, :clear_asset_cache ]
797
+ end
798
+
799
+ ### Future Directions ###
800
+
801
+ Check out the [Pivotal Tracker project](https://www.pivotaltracker.com/projects/202125)
802
+ to see what the original author had in mind for the near future.
803
+
804
+ ### Resources ###
805
+
806
+ - [http://github.com/blog/470-deployment-script-spring-cleaning](http://github.com/blog/470-deployment-script-spring-cleaning)
807
+ - [http://github.com/mislav/git-deploy](http://github.com/mislav/git-deploy)
808
+ - [http://toroid.org/ams/git-website-howto](http://toroid.org/ams/git-website-howto)
809
+
810
+ ### Support ###
811
+
812
+ The [bug tracker](https://github.com/jesseadams/whisk/issues)
813
+ is available here:
814
+
815
+ - [https://github.com/jesseadams/whisk/issues](https://github.com/jesseadams/whisk/issues)
816
+
817
+ ### Contributors ###
818
+
819
+ - [Rick Bradley](https://github.com/rick): author
820
+ - [James Cox](https://github.com/imajes): bugfixes, prototyping, design help, code, feedback
821
+ - [Rein Henrichs](https://github.com/reinh): design help, code
822
+ - [Jeremy Holland](https://github.com/awebneck): code
823
+ - [Kevin Barnes](https://github.com/vinbarnes): design help, code
824
+ - [Alex Sharp](https://github.com/ajsharp): issues, real-world usage cases, design help
825
+ - [Yossef Mendelssohn](https://github.com/ymendel): design help, proofreading
826
+ - [Aaron Kalin](https://github.com/martinisoft): bug hunting
827
+ - [Brandon Valentine](https://github.com/brandonvalentine): help with bug fixing
828
+ - [Josh Moore](https://github.com/joshsmoore): bug hunting
829
+ - [Rolf Timmermans](https://github.com/rolftimmermans): enhancements
830
+ - [Jesse R. Adams](HTTPS://github.com/jesseadams): whisk\_deploy fork manager
831
+
832
+ - Documentation/feedback: [Cristi Balan](https://github.com/evilchelu), [Hedgehog](http://github.com/hedgehog)