cf_deployer 1.2.8

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 2678998aaac0ea19f9aa0694359f9a54b92331a5
+  data.tar.gz: 62266fe192f394c3f1abc15c0002742a09add738
+SHA512:
+  metadata.gz: 65bc63a0d516b1aa7a77c94d8cb4269a1231f81c062ea0716c5d737e703eed7cd862c6b04a9dd9a51b38fda39552886161a194602a83defe7436ad9e5e7edd02
+  data.tar.gz: 0150e15aa2782cb98d65d7da9439c63724224810eb8eb8b186dbff765157b717b6bd750bceb6a3d18f933f862d5bcec2c0f13fabfb3f01fbf9a38be3d61a0a42

data/.gitignore

@@ -0,0 +1,29 @@
+*.gem
+*.rbc
+.bundle
+.config
+.yardoc
+InstalledFiles
+_yardoc
+coverage
+doc/
+lib/bundler/man
+pkg
+rdoc
+spec/reports
+test/tmp
+test/version_tmp
+/.rvmrc
+_site
+/TAGS
+/.aws
+*.swp
+temp/*
+tmp/*
+spec_result.html
+vendor
+config/
+*.swo
+tags
+.rbenv-version
+.ruby-version

data/ChangeLog.md

@@ -0,0 +1,16 @@
+version 1.2.4:
+  - Changed the default behavior of Blue/Green deployment strategy to keep previous stack after a new deployment.
+  Now the previous deployed stack will be not deleted unless you set keep-previous-stack to false.
+
+version 1.2.5:
+  - Throw errors when options cannot be recognised in cf_deployer.yml in order to help users to find configure errors early.
+  - Added setting raise-error-for-unused-inputs in cf_deployer.yml, which is false by default. When this setting is set to true, errors will be thrown if any inputs defined in cf_deployer.yml or given via command line -i parameters have no co-responding parameters in CloudFormation json templates.
+
+version 1.2.6
+  - Fixed broken command status and -d (dry-run) options.
+
+version 1.2.7
+  - Fixed broken option 'capabilities' under components.
+
+version 1.2.8
+  - Removed configure option validion at root level. Now users can have their own options at the root level in cf_deployer.yml file.

data/DETAILS.md

@@ -0,0 +1,268 @@
+##### [README](README.md) - [QUICKSTART](QUICKSTART.md) - [DETAILS](DETAILS.md) - [FAQ](FAQ.md)
+
+CFDeployer - Usage Details
+==============
+
+```shell
+Commands:
+  cf_deploy config [ENVIRONMENT]                     # Show parsed config
+  cf_deploy deploy [ENVIRONMENT] [COMPONENT]         # Deploy the specified components
+  cf_deploy destroy [ENVIRONMENT] [COMPONENT]        # Destroy the specified environment/component
+  cf_deploy help [COMMAND]                           # Describe available commands or one specific command
+  cf_deploy json [ENVIRONMENT] [COMPONENT]           # Show parsed CloudFormation JSON for the target component
+  cf_deploy kill_inactive [ENVIRONMENT] [COMPONENT]  # Destroy the inactive stack for a given component/environment
+  cf_deploy status [ENVIRONMENT] [COMPONENT]         # Show the status of the specified Cloud Formation components specified in your yml
+  cf_deploy switch [ENVIRONMENT] [COMPONENT]         # Switch active and inactive stacks
+
+Options:
+  -f, [--config-file=CONFIG-FILE]  # cf_deployer config file
+                                   # Default: config/cf_deployer.yml
+  -l, [--log-level=LOG-LEVEL]      # logging level
+                                   # Default: info
+                                   # Possible values: info, debug, aws-debug
+  -d, [--dry-run]                  # Say what we would do but don't actually make changes to anything
+  -s, [--settings=key:value]       # key:value pair to overwrite setting in config
+  -i, [--inputs=key:value]         # key:value pair to overwrite in template inputs
+  -r, [--region=REGION]            # Amazon region
+                                   # Default: us-east-1
+
+```
+
+================
+#### Defaults
+
+By default cf_deployer looks at the config/cf_deployer.yml
+ * This can be overridden by using the -f flag
+```shell
+cf_deployer -f samples/my_config.yml
+```
+
+By default cf_deployer will try and deploy all components listed in
+your config file
+
+When using Cname Swap it looks for the ELB Name as an output referenced
+by the key 'ELBName'
+When using Auto Scaling Group Swap it looks for the Auto Scaling Group
+name as an output referenced by the key 'AutoScalingGroupName'
+
+Default user hook timeout is 10 minutes, this can be overridden as shown
+in the examples below
+
+For Blue/Green deployments keep-previous-stack is defaulted to true.
+This means that after a deployment, the previous deployed stack will be kept.
+For non-production environment, you may set it to false to delete the previous stack 
+after a deployment for saving cost.
+
+If the CloudFormation template has the output named 'AutoScalingGroupName'
+or the cf_deployer.yml has the setting 'auto-scaling-group-name-output',
+CfDeployer knows that auto-scaling groups need to deploy and will warm up
+the auto-scaling groups by checking associated ELB instance status if applicable.
+
+===================
+### Deployment Strategies
+
+There are 3 strategies for deploying with cf_deployer:
+* create_or_update
+  * **Non-Blue-Green** - Updates the CloudFormation directly
+* cname_swap
+  * **Blue-Green** - Deploy to the inactive stack, then swap the CNAME entry to point to the
+    ElbName output from your CloudFormation template.
+* auto_scaling_group_swap
+  * **Blue-Green** - Deploy to the inactive stack, then warm up the new auto scaling
+    group to the same size as old. Then cool down (set instances to 0) the old auto scaling group.
+
+==================
+### Settings vs Inputs
+
+##### Settings:
+Used by the gem for blue/green deployments and naming conventions
+
+  * **For all deploys - These are the settings you can use**
+    * application
+    * component
+    * environment
+    * dns-driver (defaults to CfDeployer::Driver::Route53)
+    * keep-previous-stack (True/False: for Cname-Swap and Auto Scaling Group Swap, previous stack will be kept after new stack is created by default. Set it to false to delete the previous stack)
+    * raise-error-for-unused-inputs (True/False: it is false by default. If it is set to true, errors will be thrown if there are any inputs which are not used as parameters of CloudFormation json templates. If it is set to false or the setting does not exist, warnings will be printed in the console if there are un-used inputs.)
+    * auto-scaling-group-swap-name-output
+  * **For Components Using the Cname-Swap Deployment Strategy**
+    * dns-fqdn
+    * dns-zone
+    * elb-name-output
+
+##### Inputs:
+Used by CloudFormation in the JSON template (Note: Settings can be used as inputs, but inputs are not used as settings).  These can be almost anything.  They are defined in the **Parameters** block in the CF template.
+
+
+==================
+### How Termination Works
+
+Blue/Green deployments keep at most 2 different stacks up (Blue and
+  Green).  If both are deployed and Green is active, Blue will be deleted
+before being deployed with the newest version.
+
+Components may be deleted several different ways:
+
+* By default with Blue/Green deployments, after deploying a color (Green)
+  stack, the opposite color (Blue) will be kept.
+  * This can be overridden with the keep-previous-stack setting set as
+    false.
+* You can use the destroy command and it will delete any versions
+  (blue/green) of the specified component that exist (BE CAREFUL!!)
+* You can use the kill_inactive command to delete the 'inactive stack'
+  * For cname-swap this is the stack that DNS is _not_ pointing to
+  * For asg_swap this is the stack that has an autoscaling group with 0
+    instances
+
+
+=================
+### Tagging Your Stacks
+
+Tags for cf_deployer:application, cf_deployer:environment, and cf_deployer:component are automatically added to the CF stack by cf_deployer. To add your own tags:
+
+```
+components:
+  web:
+    capabilities:
+      - CAPABILITY_IAM
+    tags:
+      Team:  Team Awesome
+      OwnerEmail: awesome@domain.com
+
+```
+
+==============
+### Hooks
+
+There are 3 places currently where a user-provided script can be run
+before continuing with the deploy process. (Specified in the cf_deployer.yml)  Information about how to add new hooks is at the bottom of this document.
+
+* **before-destroy**
+  * This runs before a stack is spun down (This happens on delete, as
+    well as when spinning down the stack so a new version may be
+deployed)
+* **after-create**
+  * CnameSwap: Before the cname is switched to the new version (Smoke
+    Test)
+  * AutoScalingGroupSwap: Before warming up the new stack and cooling
+    down the old
+* **after-swap**
+  * CnameSwap: After the cname is switched (Wait Script to ensure DNS
+    Switch happened)
+  * AutoScalingGroupSwap: After the warming up the new stack, and
+    cooling down the old stack
+
+#### Examples:
+
+##### Ruby Code:
+    components:
+      web:
+        after-create: raise 'Server is down' unless system('curl -f http://mydomain.com/status')
+
+##### Ruby Code with Timeout:
+    components:
+      web:
+        after-create:
+          code: raise 'Server is down' unless system('curl -f http://mydomain.com/status')
+          timeout: 1500
+
+##### Ruby Code in a Separate File:
+    components:
+      web:
+        after-create:
+          file: smoke_test.rb
+
+
+
+================
+### ERB Like a Pro
+
+CFDeployer runs its YAML config file and all CF JSON templates through ERB to allow sophisticated templating.
+
+#### ERB in cf_deployer.yml
+
+##### ERB Templating in your cf_deployer.yml:
+```
+<% app_name = 'my_app' %>
+
+application: <%= app_name %>
+
+settings:
+  inputs:
+    S3BucketName: <%= app_name %>-<%= environment %>-artifacts
+```
+* Note that  'environment' is exposed to the template.  Other settings and inputs are not available yet because the parsing hasn't happened yet.
+
+
+##### This also allows the use of helper classes to abstract organization-specific boilerplate settings:
+```
+<%
+require 'my_cfd_helper'
+helper = MyCfdHelper::SettingsHelper.new
+%>
+
+settings:
+  inputs:
+    InstanceSubnets: <%= helper.instance_subnets %>
+    SecurityGrouops: <%= helper.default_security_groups %>
+    ElasticIP:       <%= helper.next_available_elastic_ip %>
+```
+
+
+#### ERB in component_cf.json
+
+##### Similarly to the cf_deployer.yml example above, ERB can be used with a helper class to abstract boilerplate JSON.  This example might be used stand up a basic, ElasticBeanstalk-like web stack:
+
+```
+<%
+require 'my_cfd_helper'
+helper = MyCfdHelper::TemplateHelper.new config
+component_name  = config[:settings][:component].capitalize
+%>
+{
+  "AWSTemplateFormatVersion": "2010-09-09",
+  "Description": "<%= config[:settings][:application] %> Web Stack",
+  "Parameters": {
+     <%= template_helper.standard_params %>
+    ,<%= template_helper.asg_params %>
+    ,<%= template_helper.elb_params %>
+  },
+  "Resources": {
+     <%= template_helper.component_role :component_name => component_name %>
+    ,<%= template_helper.web_elb :component_name => component_name %>
+    ,<%= template_helper.asg :component_name => component_name,
+                             :elb_name => "#{component_name}ServerELB",
+     %>
+  },
+  "Outputs": {
+     <%= template_helper.asg_outputs :component_name => component_name %>
+    ,<%= template_helper.elb_outputs :component_name => component_name %>
+  }
+}
+
+```
+* Note that the component-specific settings and inputs parsed from the cf_deployer.yml are made available via the 'config' Hash.
+DNS Providers are pluggable based on the dns-driver setting.  To supply a new driver, you'll need to implement the find_alias_target and set_alias_target methods. See lib/cf_deployer/dns/ for examples.
+
+
+================
+### Extending CFDeployer
+
+#### Adding New Hooks
+
+Hooks should be relatively simple to extend.  The Hook class should be initialized with the hook information pulled from the config file,
+not hard-coded ruby.  Convention is the YAML contains a key with the
+name of the hook as the key.  The value can be:
+* Ruby Code
+* A hash containing the :file key (Takes a file relative to the config
+  file directory)
+* A hash containing the :code key
+
+The instantiated object can then be #run This takes any one parameter (generally a hash, currently a hash with all your settings/inputs/JSON Template information) which
+will then be available in the user defined script/code (Currently the
+hash may be referenced by accessing the 'context' variable that is
+available due to passing the binding to eval in CfDeployer::Hook#execute)
+
+#### Adding New DNS Providers
+
+DNS Providers are pluggable based on the dns-driver setting.  To supply a new driver, you'll need to implement the find_alias_target and set_alias_target methods. See lib/cf_deployer/driver/ for examples.

data/FAQ.md

@@ -0,0 +1,61 @@
+##### [README](README.md) - [QUICKSTART](QUICKSTART.md) - [DETAILS](DETAILS.md) - [FAQ](FAQ.md)
+
+CFDeployer - FAQ
+=======================================
+
+**CFDeployer is *GREAT*!  How did you come up with the idea to write it?**
+
+We shamelessly stole the original idea from the smart guys at ThoughtWorks Studios who created a gem called [EB Deployer](http://getmingle.io/eb_deployer/) for doing easy, blue/green deployments with ElasticBeanstalk.  Thanks for the great work, guys!
+
+==========
+
+**If EbD is so great, why bother creating CFD?**
+
+EbD **IS** great but it only supports ElasticBeanstalk.  EB is fine for pretty simple applications, but if you're writing something complex, with multiple components (including some that aren't web services and don't use ELBs), then it's not really a great fit.  CloudFormation gives you a lot more flexibility and power (which is why EB uses it under the covers) but there wasn't an easy way to do blue/green deployments with it.
+
+==========
+
+**Ok, so how is CFD different?**
+
+* For starters, CFD **only** supports CloudFormation-based deployments, **not** ElasticBeanstalk.  If you want to use EB, just use EB Deployer.
+
+* CFD understands the concept that an application is often made up of multiple *components* that are deployed separately but are logically part of the same application.
+
+* CFD allows your to add business-specific tags to your CF stacks
+
+* CFD has a few options for user defined hook scripts: before-destroy, after-create, after-swap.  Which allows for more flexibility. (ie. Before destroying an S3 bucket, the user will need to empty it.)
+
+* Support for multiple deployment strategies: create-update, cname-swap (Blue/Green), auto-scaling-group-swap (Blue/Green)
+
+* CFD will pass your YAML file and CloudFormation JSON template through ERB to allow for more flexibility
+
+===========
+
+**So what parts of my application would be separate components?**
+
+Because CloudFormation allows you to deploy complex things like a stack with multiple AutoScalingGroups, for example, it can be a little hard to decide what parts of your application should be considered different components for CFD.  Generally, the question that really matters is, "What parts of my application must be deployed at the same time?"  If you want to be able to deploy your web service independently of your back-end data processing worker, you probably want them to be two different CFD components.
+
+===========
+
+**My *cf_deployer.yml* file is awfully repetitive.  How can I DRY that up?**
+
+Aside from using the usual YAML techniques to reuse common stuff, we pass the **cf_deployer.yml** file through Ruby's built-in templating system, ERB, to process inline Ruby code.  With ERB, you could do all kinds of things to clean up that file like pulling parts of it into other files or dynamically generating common values.  More info about ERB can found [here](http://www.stuartellis.eu/articles/erb/) and [here](http://www.startuprocket.com/blog/a-quick-introduction-to-embedded-ruby-erb-eruby).
+
+===========
+
+**My *CloudFormation JSON templates* are REALLY long.  What can I do about that?**
+
+The JSON templates are run through ERB too so you can do lots of things.  Here at [Manheim](http://www.manheim.com), we wrote a CFD Helper gem to help pull all of the boilerplate JSON out of our individual projects.  See the [DETAILS](DETAILS.md) page for an example of what this can look like.
+
+===========
+
+**How can I contribute to CFD?**
+
+First off, thanks for wanting to help out!
+
+0. Fork it on GitHub
+0. Create your feature branch:  `git checkout -b my-new-feature`
+0. Make your changes
+0. Commit your changes:  `git commit -am 'Added some feature'`
+0. Push the branch to GitHub:  `git push origin my-new-feature`
+0. Create a new Pull Request on GitHub

data/Gemfile

@@ -0,0 +1,10 @@
+source 'https://rubygems.org'
+
+# Specify your gem's dependencies in eb_deployer.gemspec
+gemspec
+
+gem 'yard'
+gem 'pry'
+gem 'rspec'
+gem 'rake'
+gem 'rainbow'

data/Gemfile.lock

@@ -0,0 +1,51 @@
+PATH
+  remote: .
+  specs:
+    cf_deployer (1.2.8)
+      aws-sdk
+      log4r
+      rainbow
+      thor
+
+GEM
+  remote: https://rubygems.org/
+  specs:
+    aws-sdk (1.41.0)
+      json (~> 1.4)
+      nokogiri (>= 1.4.4)
+    coderay (1.1.0)
+    diff-lcs (1.2.5)
+    json (1.8.1)
+    log4r (1.1.10)
+    method_source (0.8.2)
+    mini_portile (0.6.0)
+    nokogiri (1.6.2.1)
+      mini_portile (= 0.6.0)
+    pry (0.9.12.6)
+      coderay (~> 1.0)
+      method_source (~> 0.8)
+      slop (~> 3.4)
+    rainbow (2.0.0)
+    rake (10.3.0)
+    rspec (2.14.1)
+      rspec-core (~> 2.14.0)
+      rspec-expectations (~> 2.14.0)
+      rspec-mocks (~> 2.14.0)
+    rspec-core (2.14.8)
+    rspec-expectations (2.14.5)
+      diff-lcs (>= 1.1.3, < 2.0)
+    rspec-mocks (2.14.6)
+    slop (3.5.0)
+    thor (0.19.1)
+    yard (0.8.7.4)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  cf_deployer!
+  pry
+  rainbow
+  rake
+  rspec
+  yard

data/LICENSE

@@ -0,0 +1,22 @@
+Copyright (c) 2014 Manheim, Inc.
+
+MIT License
+
+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.

data/QUICKSTART.md

@@ -0,0 +1,96 @@
+##### [README](README.md) - [QUICKSTART](QUICKSTART.md) - [DETAILS](DETAILS.md) - [FAQ](FAQ.md)
+
+CFDeployer - Quickstart
+======================
+
+### To start using CFDeployer with your project, you need:
+
+* A working CloudFormation JSON template that is able to deploy a working instance of your application
+
+* A cf_deployer.yml file that describes the components of your application and how they are deployed
+
+This Quickstart will use the files in our [simple sample](samples/simple)
+
+==================
+### CloudFormation Templates
+
+JSON-based CF templates are how you describe to CloudFormation what AWS resources to deploy and how they are configured.  There are lots of good resources out there that explain how to write CF templates.  CF templates can get pretty complex, depending on what AWS resources your application needs and writing the templates themselves is outside the scope of this documentation.  Some good information about CF templates can be found here:
+
+* The official [AWS CloudFormation](http://aws.amazon.com/cloudformation/) page
+
+* [Getting Started with AWS CloudFormation](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
+
+* [Anatomy of an AWS CloudFormation template](http://www.techrepublic.com/blog/the-enterprise-cloud/anatomy-of-an-aws-cloudformation-template/6117/)
+
+* [Bootstrapping Applications via AWS CloudFormation](https://s3.amazonaws.com/cloudformation-examples/BoostrappingApplicationsWithAWSCloudFormation.pdf)
+
+* [Create Your AWS Stack From a Recipe](http://aws.typepad.com/aws/2011/02/cloudformation-create-your-aws-stack-from-a-recipe.html)
+
+* [Basic examples included with CFDeployer](samples/)
+
+* The **ERB Like a Pro** section of our [DETAILS](DETAILS.md) page can show you some techniques for pulling some boilerplate out of your CF templates.
+
+Note that you can use ERB and settings/inputs from the cf_deployer.yml file while developing your CloudFormation template by using CFD's **json** command and piping the output to a static CF template file.  The static file can then be fed to CF via the AWS console or commandline utilities.  Once you have a working CloudFormation template, you're ready to get started with CFDeployer.
+
+
+==================
+### Setting up your project to use CFDeployer
+
+* **CFDeployer is a Ruby gem so you'll need a working version of Ruby.**  CFDeployer should work with any 1.8.7 or 1.9.X Ruby interpreter.  CFDeployer uses the official AWS-published Ruby SDK under the covers which, in turn, uses Nokogiri.  We've heard that JRuby projects and Ruby 2.X projects have trouble getting Nokogiri installed so that might be an issue for your if you're using one of those Rubies.
+
+* **The use of the [Bundler](http://bundler.io/) gem is strongly encouraged.**  Put "gem 'cf_deployer'" into your Gemfile.
+
+* **Tell Bundler to install CFDeployer and its dependencies**
+```shell
+bundle install
+```
+
+* **Make a 'config' directory to store your CloudFormation template and cf_deployer.yml files in.**  The cf_deployer.yml file is assumed to be in the same directory as your CF templates.  The path to your cf_deployer.yml can be specified with the --config-file (-f) commandline option.
+```shell
+mkdir config
+```
+
+* **Put your CF templates and cf_deployer.yml file into the config directory**
+
+
+==================
+### Using CFDeployer
+
+The examples shown are specifying the 'qa' environment.  Our cf_deployer.yml doesn't specify any particular settings or inputs for that environment so CFD uses the defaults from the YAML file, just like it would for any other ad hoc environment.
+
+**Showing the parsed and ERBed settings that CFDeployer will use:**
+```shell
+bundle exec cf_deploy config qa
+```
+
+**Showing the parsed and ERBed CloudFormation template for the 'web' component:**
+```shell
+bundle exec cf_deploy json qa web
+```
+
+**Deploying a component:**
+```shell
+bundle exec cf_deploy deploy qa web
+```
+
+**Showing what CloudFormation stacks exist for an environment/component:**
+```shell
+bundle exec cf_deploy status qa
+```
+
+**Deploying a new version of your application in a blue/green fashion:**
+```shell
+bundle exec cf_deploy deploy qa web
+```
+Note that CFD will shut down the inactive stack, if it exists.  The new stack will then be made active and the old stack will be made inactive (or terminated, depending on your cf_deployer.yml settings).
+
+**Destroying all stacks for one component in an environment:**
+```shell
+bundle exec cf_deploy destroy qa web
+```
+
+**Destroying all stacks for ALL components in an environment:**
+```shell
+bundle exec cf_deploy destroy qa
+```
+

data/README.md

@@ -0,0 +1,36 @@
+##### [README](README.md) - [QUICKSTART](QUICKSTART.md) - [DETAILS](DETAILS.md) - [FAQ](FAQ.md)
+
+CFDeployer
+================
+
+## Installing
+
+```
+$ gem install cf_deployer
+```
+
+## Basic Help
+
+```shell
+Commands:
+  cf_deploy config [ENVIRONMENT]                     # Show parsed config
+  cf_deploy deploy [ENVIRONMENT] [COMPONENT]         # Deploy the specified components
+  cf_deploy destroy [ENVIRONMENT] [COMPONENT]        # Destroy the specified environment/component
+  cf_deploy help [COMMAND]                           # Describe available commands or one specific command
+  cf_deploy json [ENVIRONMENT] [COMPONENT]           # Show parsed CloudFormation JSON for the target component
+  cf_deploy kill_inactive [ENVIRONMENT] [COMPONENT]  # Destroy the inactive stack for a given component/environment
+  cf_deploy status [ENVIRONMENT] [COMPONENT]         # Show the status of the specified Cloud Formation components specified in your yml
+  cf_deploy switch [ENVIRONMENT] [COMPONENT]         # Switch active and inactive stacks
+
+Options:
+  -f, [--config-file=CONFIG-FILE]  # cf_deployer config file
+                                   # Default: config/cf_deployer.yml
+  -l, [--log-level=LOG-LEVEL]      # logging level
+                                   # Default: info
+                                   # Possible values: info, debug, aws-debug
+  -d, [--dry-run]                  # Say what we would do but don't actually make changes to anything
+  -s, [--settings=key:value]       # key:value pair to overwrite setting in config
+  -i, [--inputs=key:value]         # key:value pair to overwrite in template inputs
+  -r, [--region=REGION]            # Amazon region
+                                   # Default: us-east-1
+```

data/Rakefile

@@ -0,0 +1,32 @@
+require 'rubygems'
+require 'bundler/setup'
+require 'bundler/gem_tasks'
+
+require 'rspec/core/rake_task'
+
+namespace :spec do
+  RSPEC_OPTS = ["--format", "nested", "--format", "html", "--out", "spec_result.html", "--colour"]
+
+  RSpec::Core::RakeTask.new(:file) do |t|
+    t.rspec_opts = RSPEC_OPTS
+    t.pattern = ENV['SPEC_FILE']
+  end
+
+  RSpec::Core::RakeTask.new(:unit) do |t|
+    t.rspec_opts = RSPEC_OPTS
+    t.pattern = 'spec/unit/**/*_spec.rb'
+  end
+
+  RSpec::Core::RakeTask.new(:functional) do |t|
+    t.rspec_opts = RSPEC_OPTS
+    t.pattern = 'spec/functional/**/*_spec.rb'
+  end
+
+  task :all => [:unit, :functional]
+end
+
+task :default  => 'spec:all'
+
+task :clean do
+  system "rm -rf pkg/*"
+end

data/bin/cf_deploy

@@ -0,0 +1,10 @@
+#!/usr/bin/env ruby
+
+require_relative '../lib/cf_deployer'
+
+begin
+ CfDeployer::CLI.start(ARGV)
+rescue CfDeployer::ApplicationError => e
+  puts "Error: #{e.message}"
+  exit(1)
+end

data/cf_deployer.gemspec

@@ -0,0 +1,23 @@
+# -*- encoding: utf-8 -*-
+require File.expand_path('../lib/cf_deployer/version', __FILE__)
+
+Gem::Specification.new do |gem|
+  gem.authors       = ["Jame Brechtel", "Peter Zhao", "Patrick McFadden", "Rob Sweet"]
+  gem.email         = ["jbrechtel@gmail.com", "peter.qs.zhao@gmail.com", "pemcfadden@gmail.com", "rob@ldg.net"]
+  gem.description   = %q{For automatic blue green deployment flow on CloudFormation.}
+  gem.summary       = %q{Support multiple components deployment using CloudFormation templates with multiple blue green strategies.}
+  gem.homepage      = "http://github.com/manheim/cf_deployer"
+  gem.license = 'MIT'
+
+  gem.add_runtime_dependency 'aws-sdk'
+  gem.add_runtime_dependency 'log4r'
+  gem.add_runtime_dependency 'thor'
+  gem.add_runtime_dependency 'rainbow'
+
+  gem.files         = `git ls-files`.split($\).reject {|f| f =~ /^samples\// }
+  gem.executables   = gem.files.grep(%r{^bin/}).map{ |f| File.basename(f) }
+  gem.test_files    = gem.files.grep(%r{^(test|spec|features)/})
+  gem.name          = "cf_deployer"
+  gem.require_paths = ["lib"]
+  gem.version       = CfDeployer::VERSION
+end