capify-ec2 1.4.3.pre7 → 1.4.3

data/Changelog.md

@@ -1,3 +1,25 @@
+## 1.4.3 (Apr 19, 2013)
+
+Summary of the changes merged from the 'rolling_deploy' branch, from v1.4.0.pre1 to v1.4.3.pre7.
+
+Features:
+
+  - New rolling deployment mode, allows you to deploy to your instances in serial, rather than in parallel, with an option to perform a healthcheck before proceeding to the next instance. For more information on this feature, check out the [documentation](readme.md#rolling-deployments).
+  - Allowed the expected result for the rolling deployment healthcheck to be specified as a regex or an array in addition to a string.
+  - Added the ability to automatically deregister and reregister an instance from its associated Elastic Load Balancer when using the rolling deployment feature.
+  - Added the ability to run multiple healthchecks per role by specifying an array of them when defining the role.
+  - Minimum Capistrano version required set to v2.14 or greater. This fixes several issues, including an exception being thrown when a task was limited to certain roles, which weren't specified during deployment. For example, a task limited to ':roles => [:web]' would raise an exception if you tried to run 'cap db deploy', as no roles would match.
+  - The documentation has been rewritten to make it clearer how to use Capify-EC2 and what the available options are.
+
+Bugfixes:
+
+  - Instance options are now properly retained when performing a rolling deployment.
+  - Fixed a range of errors in the documentation.
+  - Error handling improved when working with the 'ec2:ssh' command.
+  - Fixed an issue which was preventing the main deployment task from being executed during a rolling deployment.
+  - Fixed an issue with healthcheck expected response output.
+  - Exit with status 1 when encountering rolling deployment errors, afer displaying the deployment status overview.
+ 
 ## 1.4.3.pre7 (Apr 11, 2013)
 
 Bugfixes:

data/LICENSE

@@ -17,4 +17,4 @@ 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.
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/lib/capify-ec2/version.rb

@@ -1,6 +1,6 @@
 module Capify
   module Ec2
-    VERSION = "1.4.3.pre7"
+    VERSION = "1.4.3"
   end
 end
 

data/readme.md

@@ -2,9 +2,6 @@
 
 Capify-EC2 is used to generate Capistrano namespaces and tasks from Amazon EC2 instance tags, dynamically building the list of servers to be deployed to.
 
-### Pre-release
-
-This pre-release version of Capify-EC2 is currently in public testing, please open a Github issue if you are experiencing difficulties.
 
 
 ### Installation
@@ -226,15 +223,34 @@ end
 As mentioned in the 'EC2 Tags' section, creating an 'Options' tag on your EC2 instances will define those options as 'true' for the associated instance. This allows you to refine your capistrano tasks.
 For example, if we had the following group of instances in EC2:
 
-    server-A Tags: Name => "server-A", Roles => "web"
-    server-B Tags: Name => "server-B", Roles => "web"
-    server-C Tags: Name => "server-C", Roles => "web", Options => "worker"
+<table>
+  <tr>
+    <td>'Name' Tag</td>
+    <td>'Roles' Tag</td>
+    <td>'Options' Tag</td>
+  </tr>
+  <tr>
+    <td>server-A</td>
+    <td>web</td>
+    <td></td>
+  </tr>
+  <tr>
+    <td>server-B</td>
+    <td>web</td>
+    <td></td>
+  </tr>
+  <tr>
+    <td>server-C</td>
+    <td>web</td>
+    <td>worker</td>
+  </tr>
+</table>
 
 You could then create a task in your 'deploy.rb' that will only be executed on the worker machine, like so:
 
 ```ruby
-task :reload_workers => :web, :only=>{:worker} do
-  # Do something to a server with cron on it
+task :reload_workers => :web, :only=>{:worker=>true} do
+  # Do something to a specific server with the 'worker' option in it's EC2 tags.
 end
 ```
 
@@ -246,7 +262,13 @@ As well as defining Options at an instance level via EC2 tags, you can define an
 ec2_roles {:name=>"web", :options=>{:worker=>"server-C"}}
 ```
 
-In this case, you set the value of ':worker' equal to the instance name you want to be a worker.
+In this case, you set the value of ':worker' equal to the instance name you want to be a worker. The task definition remains the same:
+
+```ruby
+task :reload_workers => :web, :only=>{:worker=>true} do
+  # Do something to a specific server whose instance name is equal to the 'worker' option in the role definition.
+end
+```
 
 
 
@@ -553,4 +575,4 @@ Report Issues/Feature requests on [GitHub Issues](http://github.com/forward/capi
 
 ### Copyright
 
-Copyright (c) 2011, 2012, 2013 Forward. See [LICENSE](https://github.com/forward/capify-ec2/blob/master/LICENSE) for details.
+Copyright (c) 2011, 2012, 2013 Forward. See [LICENSE](https://github.com/forward/capify-ec2/blob/master/LICENSE) for details.

metadata

@@ -1,15 +1,13 @@
 --- !ruby/object:Gem::Specification 
 name: capify-ec2
 version: !ruby/object:Gem::Version 
-  hash: -3784201798
-  prerelease: 6
+  hash: 1
+  prerelease: 
   segments: 
   - 1
   - 4
   - 3
-  - pre
-  - 7
-  version: 1.4.3.pre7
+  version: 1.4.3
 platform: ruby
 authors: 
 - Noah Cantor
@@ -20,7 +18,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2013-04-11 00:00:00 Z
+date: 2013-04-19 00:00:00 Z
 dependencies: 
 - !ruby/object:Gem::Dependency 
   name: fog
@@ -109,14 +107,12 @@ required_ruby_version: !ruby/object:Gem::Requirement
 required_rubygems_version: !ruby/object:Gem::Requirement 
   none: false
   requirements: 
-  - - ">"
+  - - ">="
     - !ruby/object:Gem::Version 
-      hash: 25
+      hash: 3
       segments: 
-      - 1
-      - 3
-      - 1
-      version: 1.3.1
+      - 0
+      version: "0"
 requirements: []
 
 rubyforge_project: capify-ec2