Example usage:
old_accounts = Account.where("created_at < ?", 1.month.ago)
old_abandoned_trials = AbandonedTrialQuery.new(old_accounts)
old_abandoned_trials.find_each do |account|
account.send_offer_for_support
require 'fileutils' | |
# Warning: The following deploy task will completely overwrite whatever is currently deployed to Heroku. | |
# The deploy branch is rebased onto master, so the push needs to be forced. | |
desc "Deploy app to Heroku after precompiling assets" | |
task :deploy do | |
deploy_branch = 'heroku' | |
remote = 'heroku' | |
deploy_repo_dir = "tmp/heroku_deploy" |
ref: http://nathanhoad.net/deploy-from-a-git-tag-with-capistrano | |
Deploy from a Git tag with Capistrano | |
Are you using Capistrano and Git and want to easily deploy from Git tags? It couldn't be simpler | |
Using Git, tag a new release: | |
git tag -a 09.10.02.01 -m "Tagging a release" | |
You can use git tag to list your tags: |
Below are the actual files we use in one of our latest production applications at Agora Games to achieve zero downtime deploys with unicorn. You've probably already read the GitHub blog post on Unicorn and would like to try zero downtime deploys for your application. I hope these files and notes help. I am happy to update these files or these notes if there are comments/questions. YMMV (of course).
Other application notes:
Salient points for each file:
class people::jfryman { | |
# Applications | |
include chrome::stable | |
include onepassword | |
include dropbox | |
include alfred | |
include macvim | |
include zsh | |
include homebrew | |
include fitbit |
There are many different provisioning tools out there, the most popular of which are Chef and Puppet. Chef uses Ruby, Puppet uses a DSL (Domain Specific Language), there are others that use simple bash too, but today we're going to focus on Chef Solo.
To get Chef working properly on your local machine you need a few things.
Make sure you use Ruby 1.9.x and not Ruby 2.x as you will get errors with the json 1.6.1 gem on 2.x. Use rbenv or RVM to manage several different Rubies on the one machine.
#!/usr/bin/env ruby | |
require 'rubygems' | |
require 'gollum/app' | |
gollum_path = File.expand_path(File.join(File.dirname(__FILE__), 'database.git')) # CHANGE THIS TO POINT TO YOUR OWN WIKI REPO | |
Precious::App.set(:gollum_path, gollum_path) | |
Precious::App.set(:default_markup, :markdown) # set your favorite markup language | |
Precious::App.set(:wiki_options, {:live_preview => false, :universal_toc => false, :user_icons => 'gravatar'}) | |
module Precious | |
class App < Sinatra::Base | |
# Creates a simple authentication layer |
I use Namecheap.com as a registrar, and they resale SSL Certs from a number of other companies, including Comodo.
These are the steps I went through to set up an SSL cert.
@holman got a request about our deployment system, heaven
I know it's not a high priority, but has there been any activity on open-sourcing the core Heaven gem?
There is. I've been working on extracting the non-GitHub specific parts into two gems. This first is a CLI portion called hades. The second is an HTTP API portion called heaven.
When you open source something previously used as in internal tool like Heaven, Hubot, Boxen, etc., how do you manage and hook in the parts that need to stay internal?
Normally I focus around four questions:
###Deploy SSH key to ansible inventory### | |
for server in $(ansible --list-hosts all); do ssh-copy-id -i ~/.ssh/id_rsa.pub $server; done |