augustash / capistrano-ash

August Ash recipes for Capistrano

Installation

gem install capistrano-ash

Overview

Run the following commands in the command line from the project’s root directory

  
    capify .
    rm -Rf config/deploy.rb; mkdir -p config/deploy
    touch config/deploy/staging.rb config/deploy/production.rb
  

After you have edited your Capfile and staging.rb and production.rb files, you will need to run the following command only once per environment:

  
    cap staging deploy:setup
    cap production deploy:setup
  

Deploying Magento

Check the Wiki for detailed installation instructions.

Deploying WordPress

Check the Wiki for detailed installation instructions.

WordPress on shared hosting
WordPress on virtual or dedicated servers

Deploying Drupal example

The capistrano/ash/drupal library takes a hash of Drupal multisites in the following format.

set :multisites, {"default" => "mysite.com", "another" => "another.mysite.com"}

where each key is a folder in your sites directory and each value is the URL of the multisite. If you are not using multisites, just exclude the :multisites variable definition.

Check the Wiki for detailed configuration instructions.
Drupal on virtual or dedicated servers
Drupal on shared hosting

Deploying Zend or Zend/Doctrine example

Capfile

  
    # Capfile
    load 'deploy' if respond_to?(:namespace) # cap2 differentiator

    # --------------------------------------------
    # :application HAS TO BE DEFINED BEFORE
    # REQUIRING 'ash/zend_doctrine' LIBRARY
    # --------------------------------------------
    set :application, "BEST_APP_EVER"

    # --------------------------------------------
    # Define required Gems/libraries
    # --------------------------------------------
    require 'ash/zend_doctrine'

    # --------------------------------------------
    # Setting defaults
    # --------------------------------------------
    # IP-address or host's servername
    role :app, "bestappever.com"
    role :web, "bestappever.com"
    role :db,  "bestappever.com", :primary => true

    # VCS information.
    set :repository, "https://svn.example.com/REPO/trunk"
    set :scm_username, "SVN_USER"
    set :scm_password, proc{Capistrano::CLI.password_prompt("Subversion password for '#{scm_username}':")}

    # SSH login credentials
    set :user, "SSH_USER"
    set :password, proc{Capistrano::CLI.password_prompt("SSH password for '#{user}':")}
    
    # Deploy to file path
    set(:deploy_to)  { "/var/www/#{application}/#{stage}" }

    # Database credentials
    set :dbuser, "DB_USER_NAME"

    # Define which files or directories you want to exclude from being backed up
    set(:backup_exclude) { [ "var/" ] }
    

    # --------------------------------------------
    # Calling our Methods
    # --------------------------------------------
    before "deploy:update_code", "deploy:setup_backup"
    after "deploy:setup_backup", "backup"
    after "deploy:setup_shared", "app:setup_shared"
    after "zend:symlink", "app:symlink"

    # --------------------------------------------
    # Application Specific Custom Methods
    # --------------------------------------------
    namespace :app do
      desc "Setup shared directories and permissions specific to the application"
      task :setup_shared, :roles => :web, :except => { :no_release => true } do
        run "mkdir -p #{shared_path}/media"
        sudo "chmod -R 777 #{shared_path}/*"
      end

      desc "Symlink shared directories specific to the application"
      task :symlink, :except => { :no_release => true } do
        run "ln -nfs #{shared_path}/media #{current_release}/public/media"
      end
    end
  

config/deploy/staging.rb

  
    # config/deploy/staging.rb

    # Deploy site using Capistrano
    #
    # Usage:
    # cap staging deploy:setup
    # cap staging deploy

    # Database Name
    set :dbname, "DB_NAME"

    # Backups Path (/var/www/#{application}/staging/backups)
    set :backups_path,  "#{deploy_to}/backups"
  

config/deploy/production.rb

  
    # config/deploy/production.rb
    
    # Deploy site using Capistrano
    #
    # Usage:
    # cap production deploy:setup
    # cap production deploy

    # Database Name
    set :dbname, "DB_NAME"

    # Backups Path (/var/www/#{application}/production/backups)
    set :backups_path,  "#{deploy_to}/backups"
  

capistrano-ash's Issues

enable submodules by default in ash/base.rb

set :git_enable_submodules, 1

zend_symlink is ran multiple times instead of once in ash/zend_doctrine

change

after "deploy", "zend:symlink"

to

after "deploy:create_symlink", "zend:symlink"

Add compass clean to wipe out previously compiled stylesheets

The compass:compile task is not actually re-compiling the stylesheets because it believes they are unchanged from the development versions, so need to add a compass clean before compass compile to work as expected.

permissions aren't fixed for releases when doing a deploy:cleanup task

# This fails because 'directories' is a string not an array at this point
directories.each do |dir|
  set_perms_dirs(dir)
  set_perms_files(dir)
end

create task to fix permissions for directories created by deploy:setup on shared hosting environments

The directories created by cap <ENV> deploy:setup should have 755 permissions instead of 775. It's not necessary to do a recursive permission setting, so only focus on:

• /path/to/<ENV>
• /path/to/<ENV>/releases
• /path/to/<ENV>/shared
• /path/to/<ENV>/backups

deploy:setup_shared chokes on permissions in the Drupal Shared Hosting recipe

I had to modify the last line of deploy:setup_shared so that it doesn't use the set_perms_dir wouldn't use the sudo helper as it does in set_perms_dir and set_perms_files

See:

• https://github.com/augustash/capistrano-ash/blob/develop/lib/ash/drupal_shared_hosting.rb#L31
• https://github.com/augustash/capistrano-ash/blob/develop/lib/ash/common.rb#L45-L53

namespace :deploy do
  desc "Setup shared application directories and permissions after initial setup"
  task :setup_shared do
    # remove Capistrano specific directories
    run "rm -Rf #{shared_path}/log"
    run "rm -Rf #{shared_path}/pids"
    run "rm -Rf #{shared_path}/system"

    # create shared directories
    multisites.each_pair do |folder, url|
      run "mkdir -p #{shared_path}/#{url}/files"
    end

    # set correct permissions
    run "chmod -R 755 #{shared_path}/*"
  end
end

Deploy cleanup fixpermf

Josh,
please, please, please, fix the permfs

thank yous,
joe

new code in deploy:setup_backup breaks deployments

should rescue from exceptions during backup:web

The backup:web was failing to remove the copied release directory from the tmp folder located in the backups directory. Also had to change permissions to 755 to make sure the ssh user could actually remove everything.

# overrides backup:web in ash/base.rb
namespace :backup do
  desc <<-DESC
    Requires the rsync package to be installed.

    Performs a file-level backup of the application and any assets \
    from the shared directory that have been symlinked into the \
    applications root or sub-directories.

    You can specify which files or directories to exclude from being \
    backed up (i.e., log files, sessions, cache) by setting the \
    :backup_exclude variable
    set(:backup_exclude) { [ "var/", "tmp/", logs/debug.log ] }
  DESC
  task :web, :roles => :web do
    if previous_release
      puts "Backing up web files (user uploaded content and previous release)"

      if !backup_exclude.nil? && !backup_exclude.empty?
        logger.debug "processing backup exclusions..."
        backup_exclude.each do |pattern|
          exclude_string << "--exclude '#{pattern}' "
        end
        logger.debug "Exclude string = #{exclude_string}"
      end

      # Copy the previous release to the /tmp directory
      logger.debug "Copying previous release to the #{tmp_backups_path}/#{release_name} directory"
      run "rsync -avzrtpL #{exclude_string} #{current_path}/ #{tmp_backups_path}/#{release_name}/"

      begin
        # --------------------------
        # SET/RESET PERMISSIONS
        # --------------------------
        set_perms_dirs("#{tmp_backups_path}/#{release_name}", 755)
        set_perms_files("#{tmp_backups_path}/#{release_name}", 755)

        # create the tarball of the previous release
        set :archive_name, "release_B4_#{release_name}.tar.gz"
        logger.debug "Creating a Tarball of the previous release in #{backups_path}/#{archive_name}"
        run "cd #{tmp_backups_path} && tar -cvpf - ./#{release_name}/ | gzip -c --best > #{backups_path}/#{archive_name}"

        # remove the the temporary copy
        logger.debug "Removing the tempory copy"
        run "rm -rf #{tmp_backups_path}/#{release_name}"
      rescue Exception => e
        logger.debug e.message
        logger.info "caught an excpetion but keep on truckin..."
      end
    else
      logger.important "no previous release to backup; backup of files skipped"
    end
  end
end

Is it possible to deploy Magento with git?

I can't seem to override the scm in the config. It just keeps prompting for SVN user.

backup:db and backup:web fail to fire

Using the ash/drupal_shared_hosting recipe the following output is seen

    triggering after callbacks for `deploy:setup_backup'
  * == Currently executing `backup'
  * == Currently executing `backup:db'
  * executing "ls -x /home/XXXX/domains/XXXX/code/staging/releases"
    servers: ["XXXX"]
    [XXXX] executing command
    command finished in 90ms
*** no previous release to backup; backup of database skipped
  * == Currently executing `backup:web'
*** no previous release to backup; backup of files skipped

Possibly the caused by the conditional if previous_release statement within the ash/drupal.rb or ash/base.rb backup tasks?

add methods for fixing permissions on files and directories

move the innards of the ash:fixperms to their own separate methods for fixing permissions on files and directories

so instead of this:

# in lib/ash/base.rb
namespace :ash do
  desc "Set standard permissions for Ash servers"
  task :fixperms, :roles => :web, :except => { :no_release => true } do
    # chmod the files and directories.
    try_sudo "find #{latest_release} -type d -exec chmod 755 {} \\;"
    try_sudo "find #{latest_release} -type f -exec chmod 644 {} \\;"
  end
end

we could do something like this:

# in lib/ash/base.rb
namespace :ash do
  desc "Set standard permissions for Ash servers"
  task :fixperms, :roles => :web, :except => { :no_release => true } do
    # chmod the files and directories.
    fix_perms_files("#{latest_release}")
    fix_perms_dirs("#{latest_release}")
  end
end

# in lib/ash/common.rb

# recursively fix file permissions
# defaults to the the current working directory 
# and normal file permissions of 644
def fix_perms_files(path_to_directory = ".", permissions = 644)
  try_sudo "find #{path_to_directory} -type f -exec chmod #{permissions} {} \\;"
end

# recursively fix directory permissions
# defaults to the the current working directory 
# and normal directory permissions of 755
def fix_perms_dirs(path_to_directory = ".", permissions = 755)
  try_sudo "find #{path_to_directory} -type d -exec chmod #{permissions} {} \\;"
end

zend:symlink should be using `latest_release` variable instead of `current_release`

should change the zend:symlink task in lib/ash/zend_doctrine.rb to look like this:

namespace :zend do
  desc "Symlink shared directories"
  task :symlink, :roles => :web, :except => { :no_release => true } do
    run "ln -nfs #{shared_path}/var #{latest_release}/var"
    run "ln -nfs #{shared_path}/system #{latest_release}/public/system"
    run "mv #{latest_release}/application/configs/application.ini.dist #{latest_release}/application/configs/application.ini"
    run "ln -nfs #{latest_release}/application/Application.#{stage}.php #{latest_release}/application/Application.php"
    run "mv #{latest_release}/public/htaccess.#{stage} #{latest_release}/public/.htaccess"
    run "cp #{latest_release}/scripts/doctrine-cli.#{stage} #{latest_release}/scripts/doctrine-cli"


    try_sudo "chmod +x #{latest_release}/scripts/doctrine-cli"

    # remove the example or other environment example files
    run "rm -f #{latest_release}/scripts/doctrine-cli.dist"
    run "rm -f #{latest_release}/scripts/doctrine-cli.staging"
    run "rm -f #{latest_release}/scripts/doctrine-cli.production"
    run "rm -f #{latest_release}/application/Application.example.php"
  end
end

namespace :doctrine do
  desc "Run Doctrine Migrations"
  task :migrate, :roles => :web, :except => { :no_release => true } do
    puts "Running Doctrine Migrations..."
    run "cd #{latest_release} && ./scripts/doctrine-cli migrate"
  end
end

Add tasks to run a drush make script

fix spelling of :default_stage in lib/ash/base.rb

missing the 'a' in 'stage'

cannot combine ash/hosted_magento with capistrano-multiconfig

recipes: https://github.com/railsware/capistrano-multiconfig + https://github.com/augustash/capistrano-ash/wiki/Shared-Hosting-Magento-Example

I try to deploy a magento shop to different servers.
The only difference is a theme in an other language and the database.
The codebase is the same.
I want to deploy something like:

but if i issue:
$ cap -T
the task `staging' does not exist

can you give me a hint how to solve this ?

Greets and thnx :)

multisite drupal errors out when SVN site name and live site name are the same

The issue is with this line, I believe:
https://github.com/augustash/capistrano-ash/blob/develop/lib/ash/drupal.rb#L57

For example, with this in production.rb:

# --------------------------------------------
# Drupal
# --------------------------------------------
set :multisites, {
  'default'                           => 'www.intellectualtakeout.org',
  'know-y.intellectualtakeout.org'    => 'know-y.intellectualtakeout.org',
  'momthink.intellectualtakeout.org'  => 'momthink.intellectualtakeout.org',
}

The last two settings will return an error on at least some Linux servers.

Here's the error log:

  * executing "mv /home/augash/intellectualtakeout.org/production/releases/20110914153126/sites/know-y.intellectualtakeout.org /home/augash/intellectualtakeout.org/production/releases/20110914153126/sites/know-y.intellectualtakeout.org"
    servers: ["intellectvds2.mn2.visi.com"]
    [intellectvds2.mn2.visi.com] executing command
 ** [out :: intellectvds2.mn2.visi.com] mv:
 ** [out :: intellectvds2.mn2.visi.com] cannot move `/home/augash/intellectualtakeout.org/production/releases/20110914153126/sites/know-y.intellectualtakeout.org' to a subdirectory of itself, `/home/augash/intellectualtakeout.org/production/releases/20110914153126/sites/know-y.intellectualtakeout.org/know-y.intellectualtakeout.org'
 ** [out :: intellectvds2.mn2.visi.com] 
    command finished in 395ms
*** [deploy:update_code] rolling back
  * executing "rm -rf /home/augash/intellectualtakeout.org/production/releases/20110914153126; true"

In other words, moving the folder to itself doesn't work.

My proposed solution to make this not error out is to just add an if statement around the move command that would just skip the move command if the "folder" key and "url" values are the same.

add a method to run mysql statements in a consistent manner

Just an idea, but maybe something like this would help DRY up some of the manual MySQL commands we use for updating database configuration settings. I'd like to be able to do something more along the lines of run where I can pass in the statement (e.g., mysql.execute "UPDATE ...") directly instead of having to overwrite the sql_statement parameter within each task.

---

For comparison, here's the old/current way this is being handled

run "mysql -u #{wp_db_user} --password=#{wp_db_pass} -e 'UPDATE #{wp_db_name}.#{wp_db_prefix}options SET option_value = \"#{wp_base_url}\" WHERE option_name = \"siteurl\" OR option_name = \"home\"'"

DRY(?) method of running mysql statements

# example task that would override any previously set :sql_statement value 
# and utilize the `mysql.execute` task
namespace :wordpress do
  desc "Set WordPress Base URL in database"
  task :updatedb, :roles => :db, :except => { :no_release => true } do
    wp_blogs.each do |blog|
      wp_blog_directory   = blog[:directory]
      wp_db_prefix        = blog[:db_prefix]
      wp_base_url_prefix  = blog[:base_url]["#{stage}".to_sym]
      wp_base_url         = "#{wp_base_url_prefix}/#{wp_blog_directory}"

      set :sql_statement, "UPDATE #{wp_db_name}.#{wp_db_prefix}options SET option_value = \"#{wp_base_url}\" WHERE option_name = \"siteurl\" OR option_name = \"home\""

      # executes the above :sql_statement
      mysql.execute
    end
  end
end

# --------------------------------------------
# MySQL commands
# --------------------------------------------
namespace :mysql do
  desc <<-DESC
    [internal] Runs mysql commands in a more reliable pattern.

    This would essentially be similar to our backup:db task but with some additional \ 
    assumptions that you need to define the :sql_statement parameter within your task \ 
    to override any previously defined value and that you use the same values for \ 
    username and password as your :dbuser and :dbpass
  DESC
  task :execute, :roles => :db do
    full_sql_statement = "mysql -u #{dbuser} -p -e '#{sql_statement}'"
    run "#{full_sql_statement}" do |ch, stream, out|
      ch.send_data "#{dbpass}\n" if out =~ /^Enter password:/
    end
  end
end

add support for different htaccess file per environment

something like this may work:

# --------------------------------------------
# Overridden Tasks
# --------------------------------------------
namespace :ash do
    desc 'Copy distribution htaccess file'
    task :htaccess, :roles => :web do
        htaccess_env_file = "htacces.#{stage}.dist"
        if remote_file_exists?("#{latest_release}/#{htaccess_env_file}")
            run "mv #{latest_release}/#{htaccess_env_file} #{latest_release}/.htaccess"
        else 
            run "mv #{latest_release}/htaccess.dist #{latest_release}/.htaccess" if remote_file_exists?("#{latest_release}/htaccess.dist")
        end
  end
end

Wordpress symlink task symlinks to old release rather than the latest version

Wordpress symlink task symlinks folders to previous release (current_release) rather than the latest release. Simply change current_release to latest_release in the following block of code

namespace :wordpress do
  desc "Links the correct settings file"
  task :symlink, :roles => :web, :except => { :no_release => true } do
    run "ln -nfs #{shared_path}/uploads #{current_release}/#{uploads_path}"
    run "ln -nfs #{shared_path}/cache #{current_release}/wp-content/cache"
    symlink_confg
  end

 # ... more code ...

end

DRUPAL - htaccess on production deploy

For productions sites we need to have a solution to specify if a site should be forced to the 'www' sub-domain or with the 'non-www' option. In the default Drupal htaccess file there are a couple lines that simply need to be un-commented to allow for the 'www' or 'non-www' redirect.

change owner ship of directories/files in `deploy:cleanup` to avoid permission denied errors

Drupal shared server deployments are still having issues with removing old releases giving a Permission Denied error when trying to remove anything in the sites directories

namespace :deploy do

  #... blah blah blah
  namespace :cleanup do
    # ... blah blah blah
    directories.split(" ").each do |dir|
      # adding a chown -R method to fix permissions on the little jerk
      try_sudo "chown -R #{user}:#{user} #{dir}"

      set_perms_dirs(dir)
      set_perms_files(dir)
    end
  end
end

change the location of where backups are temporarily being copied to before being tarballed

Right now the backup process dumps the database into the file structure and then all files (including symlinks) are copied to the /tmp directory before being tarballed and copied back to the backups directory. This works well for applications within a virtual or dedicated server, but shared hosting accounts usually don't have privileges to remove these copied directories from the /tmp directory.

Backup Cleanup

Would be nice to make the capistrano-ash keep the last 3 backups, but with a range of at least 24 hours of the last one, and trash all the new ones automatically. This way we could deploy many times and be sure that at least 3 old good backups are always safe.

change the finalize_update in ash/drupal to rsync files

Files located in the repository should be rsynced to the shared/files directory so local development files are included with the uploaded files from the server

Magento recipe is choking on deploy:finalize_update using try_sudo

We'll be rolling back #46 shortly and refactoring the use of try_sudo because it has been very problematic in some situations because it doesn't really prompt you for the sudo password and instead passes an empty string; it's probably assuming the ssh user has been setup with the necessary permissions to run sudo without a password.

Right now the workaround has been to use the old code (at least for our related projects):

# --------------------------------------------
# HEY!!!!
# This chunk below was put in place to address an error cause from the 'try_sudo' command that was recently put in place
# See: https://github.com/augustash/capistrano-ash/commit/3dc10df6be20fca054e41e0a6de574ea3e77a36f
# --------------------------------------------
namespace :deploy do
  task :finalize_update, :roles => :web, :except => { :no_release => true } do
    run "#{sudo} rsync -rltDvzog #{latest_release}/media/ #{shared_path}/media/"
    run "#{sudo} chmod -R 777 #{shared_path}/media/"

    # remove directories that will be shared
    run "#{sudo} rm -Rf #{latest_release}/includes"
    run "#{sudo} rm -Rf #{latest_release}/media"
    run "#{sudo} rm -Rf #{latest_release}/sitemap"
    run "#{sudo} rm -Rf #{latest_release}/var"

    # set the file and directory permissions
    ash.fixperms
    run "chmod 400 #{latest_release}/pear" if remote_file_exists?("#{latest_release}/pear")
    run "chmod 400 #{latest_release}/mage" if remote_file_exists?("#{latest_release}/mage")
    run "chmod o+w #{latest_release}/app/etc"
  end
end

add some basic ubercart methods to the drupal receipe

possible methods to include:

• securing downloadable products
• securing ubercart's encryption keys

missing method? "local_file_exists"

I was perusing the db:to_local task and it's children tasks (specifically the db:local_import task)which seem to rely upon checking if a directory/file exists via the local_file_exists? method. I was expecting to find it in the ash/common file with the sibling remote_file_exists method but didn't find it there or in the rest of the ash/base.

issues with drupal recipe and capistrano 2.13.3

deployment goes through deploy:cleanup and fails when trying to do a drupal:clearcache. Seems to be an issue with the drupal recipe skipping some steps related to symlinking settings.php files

below is the final steps/output from the deployment:

 * 18:46:50 == Currently executing `drupal:clearcache'
  * executing "drush -l aaiama.victor.aaidev.net -r /home/aaiama/domains/avemariaacademy.com/code/staging/current cache-clear all"
    servers: ["victor.aaiserver.net"]
    [victor.aaiserver.net] executing command
 ** [out :: victor.aaiserver.net] Command cache-clear needs a higher bootstrap level to run - you will [error]
 ** [out :: victor.aaiserver.net] need invoke drush from a more functional Drupal environment to run
 ** [out :: victor.aaiserver.net] this command.
 ** [out :: victor.aaiserver.net] The drush command 'cache-clear all' could not be executed.           [error]
 ** [out :: victor.aaiserver.net] Drush was not able to start (bootstrap) the Drupal database.         [error]
 ** [out :: victor.aaiserver.net] Hint: This error often occurs when Drush is trying to bootstrap a
 ** [out :: victor.aaiserver.net] site that has not been installed or does not have a configured
 ** [out :: victor.aaiserver.net] database.
 ** [out :: victor.aaiserver.net] 
 ** [out :: victor.aaiserver.net] Drush was attempting to connect to :
 ** [out :: victor.aaiserver.net] Drupal version    : 7.14
 ** [out :: victor.aaiserver.net] Site URI          : aaiama.victor.aaidev.net
 ** [out :: victor.aaiserver.net] Database driver   : mysql
 ** [out :: victor.aaiserver.net] Database hostname : 192.168.16.116
 ** [out :: victor.aaiserver.net] Database username : developer
 ** [out :: victor.aaiserver.net] Database name     : ama_dev_drupal
 ** [out :: victor.aaiserver.net] Default theme     : garland
 ** [out :: victor.aaiserver.net] Administration theme: garland
 ** [out :: victor.aaiserver.net] PHP configuration : /usr/local/etc/php5/cgi/php.ini
 ** [out :: victor.aaiserver.net] Drush version     : 4.5
 ** [out :: victor.aaiserver.net] Drush configuration:
 ** [out :: victor.aaiserver.net] Drush alias files :
 ** [out :: victor.aaiserver.net] Drupal root       :
 ** [out :: victor.aaiserver.net] /home/aaiama/domains/avemariaacademy.com/code/staging/current
 ** [out :: victor.aaiserver.net] Site path         : sites/aaiama.victor.aaidev.net
 ** [out :: victor.aaiserver.net] Modules path      : sites/all/modules
 ** [out :: victor.aaiserver.net] Themes path       : sites/aaiama.victor.aaidev.net/themes
 ** [out :: victor.aaiserver.net] File directory path: sites/aaiama.victor.aaidev.net/files
 ** [out :: victor.aaiserver.net] %paths            : Array
 ** [out :: victor.aaiserver.net] 
 ** [out :: victor.aaiserver.net] You can select another site with a working database setup by
 ** [out :: victor.aaiserver.net] specifying the URI to use with the --uri parameter on the command
 ** [out :: victor.aaiserver.net] line or $options['uri'] in your drushrc.php file.
    command finished in 3415ms
failed: "sh -c 'drush -l aaiama.victor.aaidev.net -r /home/aaiama/domains/avemariaacademy.com/code/staging/current cache-clear all'" on victor.aaiserver.net

Drupal Shared Hosting Setup and Deploy breaks on set_perms_dir.

Trying to setup or deploy to staging, the set_perms_dir command does not work. This error shows up:

failed: "sh -c 'find /home/aaidura/domains/durasupreme.com/staging/releases/20131105194229 -type d -print0 | xargs -0 sudo -p '\\''sudo password: '\\'' chmod 755'" on victor.aaiserver.net

The error is thus:

Sorry, user aaidura is not allowed to execute '/bin/chmod 755 lots_of_dir_paths  as root on victor.aaiserver.net.

Add default branches to "staging" and "production"?

Right now, any deploy using Git goes from the confusing "HEAD". It seems it should either be included in the Wiki documentation that you should set a branch (well, for that matter, to include some Git documentation in the Wiki at all), or even better, to provide "develop" and "master" as default branches for each environment.

Database Backup on Database Remote Deployment

Pete rocked our faces off by creating database deployment to_remote and to_local. A thought with deploying the database to the remote server, would be to create a backup copy of the database, and perhaps keep 2-5 of the most recent backups on hand on the server in case it was needed and something went wrong.

I see there is a task called 'backup:db' already. Perhaps this is already working, or part-way there. If so, this could be integrated in instead of writing a new task.

syntax error in lib/ash/drupal.rb

reports of either a missing or extra end syntax error since addition of drupal:ubercart tasks (issue #4) or possibly in the patch for issue #11.

Affects version 1.1.12

add drush as dependency for Drupal recipes

# --------------------------------------------
# Deployment dependencies
# --------------------------------------------
depend :remote, :command, 'drush'

Add exception handling to backup:cleanup task

I don't know if it was caused by deploying to multiple servers that had different number of releases or what but there was an error that was occurring when attempting to fix permissions on the files and directories before removing them.

I know our Drupal recipe complains about that quite a bit (mostly due to the chaos modules changing ownership of directories) but I can't think of any important reason why I a failure in a pruning/cleanup task should block a deployment.

namespace :backup do
  desc <<-DESC
    Clean up old backups. By default, the last 10 backups are kept on each \
    server (though you can change this with the keep_backups variable). All \
    other backups are removed from the servers. By default, this \
    will use sudo to clean up the old backups, but if sudo is not available \
    for your environment, set the :use_sudo variable to false instead.
  DESC
  task :cleanup, :except => { :no_release => true } do
    count = fetch(:keep_backups, 10).to_i
    if count >= backups.length
      logger.important "no old backups to clean up"
    else
      logger.info "keeping #{count} of #{backups.length} backups"

      begin
        archives = (backups - backups.last(count)).map { |backup|
          File.join(backups_path, backup) }.join(" ")

        # fix permissions on the the files and directories before removing them
        archives.split(" ").each do |backup|
          set_perms_dirs("#{backup}", 755)
          set_perms_files("#{backup}", 644)
        end

        try_sudo "rm -rf #{archives}"
      rescue Exception => e
        logger.important e.message
      end
    end
  end
end

add a method to test if a remote directory exists

similar functionality to the remote_file_exists method

compass upload_stylesheets scp fails if using non-default port

should be able to specify the port number via -P 2222 for it to work

namespace :compass do

  desc 'Uploads compiled stylesheets to their matching watched directories'
  task :upload_stylesheets, :roles => :web, :except => { :no_release => true } do
    # ... stuff
    upload_command = "scp -r -P #{port} ./#{dir}/#{stylesheets_dir_name}/*.css #{user}@#{web_server}:#{latest_release}/#{dir}/#{stylesheets_dir_name}/"

    # ...stuff...
  end
# ... more stuff
end

see lines 461 and 473 in ash/base.rb

Magento deployment ignores ':use_sudo' for some operations

Even when you set :use_sudo to false, certain operations will still require sudo to run, for example rsync'ing the media folder during finalize_update.

This is caused by the use of sudo instead of try_sudo. A fix should therefore be trivial.

remove symlink for staging server for shared Drupal set-up

Drupal sites do not need to have the "sites/www.domain.com" directory renamed for the staging server. Currently it looks like this is automatically done in the ash/drupal_shared_hosting file when you define 'set :multisites'. Ideally this functionality would just add a line to the "sites/sites.php" file that would point the staging url to the "sites/www.domain.com" folder. Below is an example of the line that would need to be added:

$sites['aai.server.aaidev.net'] = 'domain.com';

See Adam Erickson with questions.

update for use in Capistrano 3.x

Port issues with compass

Here is the error:
/Users/dev/.rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/capistrano-2.15.5/lib/capistrano/configuration/namespaces.rb:193:in method_missing': undefined local variable or methodport' for #Capistrano::Configuration::Namespaces::Namespace:0x000001009e8468 (NameError)

Update the documentation and create more Wiki pages

On shared servers, perms not reset before cleanup

It seems to me that this code from base.rb is not working on the shared servers, at least. None of the commands inside the "each" command seem to be running, so I would assume that the "directories" variable must be empty.

        directories = (local_releases - local_releases.last(count)).map { |release|
          File.join(releases_path, release) }.join(" ")

        directories.split(" ").each do |dir|
          # adding a chown -R method to fix permissions on the directory
          # this should help with issues related to permission denied
          # as in issues #28 and #30
          try_sudo "chown -R #{user}:#{user} #{dir}"

          set_perms_dirs(dir)
          set_perms_files(dir)
        end

create a task to combine plugins from the repository and the live server

Some WordPress plugins have an issue being located within a symlinked directory (share/plugins) so until the WordPress wp_includes/plugin.php plugin_basename patch is accepted into core the plugins directory should not be located within the shared directory but rather stay in the same root directory of the WordPress application.

Because people can download and install plugins through the admin interface, we should create a task to copy the previous release's plugins to the newest release's plugin directory (probably best handled via rsync)

backup:cleanup task is unable to chmod a blank string...go figure

chmod: missing operand after '755'

real live error during a deployment:

executing "find /path/to/app/staging/backups/magento_staging_dump-2013-06-24_18:17:37_-0500.sql.gz -type d -print0 | xargs -0 chmod 755"

Remove copying of .git files to the live site.

Right now the default exclude file for copying excludes SVN, Capistrano, Ruby, SQL, and README files. I think it should also include ".git" by default so that we do not need to override it in every repository. If this is not done, the git repository gets copied for every release and every backup as currently designed. If it is done with the ".svn" folders, we should do it with ".git" too. I propose it gets added to line 54-55 of "lib/ash/base.rb".

Drush won't run if multisite folder changed on initial deploy

When creating a new deploy with a multisite installation, the multisite variable will create a new name for the sites/mysitename/ folder. This causes an error with the code registry, which means Drush can't bootstrap, and thus can't clear the cache, and the whole deploy process rolls back

PHP Fatal error: require_once(): Failed opening required '/home/aaimmta/domains/mnmusicteachers.com/code/staging/current/sites/mnmusicteachers.com/modules/contrib/entity/includes/entity.inc' (include_path='.:/usr/local/php5/lib/php') in /home/aaimmta/domains/mnmusicteachers.com/code/staging/releases/20111017151748/includes/bootstrap.inc on line 2913

You can get around this by doing a regexp replacement on the database, but it'd be nicer and safer if we could find some sort of variable or method that protects our DB a bit more than simply replacing all instances in the DB. Ideally we'd rebuild the registry, though most ways I can find to rebuild the registry require Drupal to bootstrap. So we have a problem where Drupal can't bootstrap because the registry is wrong, and we can't fix the registry because Drupal can't bootstrap.

There may be some workarounds to this. http://drupal.org/project/registry_rebuild is a module for rebuilding the registry for these types of situations, so maybe we can automatically download this and/or write a script based on it. There's also a method to rebuild the registry in Drupal's API: http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/registry_rebuild/7. We might be able to use something from there to create a workaround.

License missing from gemspec

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec
via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Bundler now generates gems with a default 'MIT' license. There is even a License Finder
to help companies ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec.
Including a license in your gemspec is a good practice, in any case.

If you need help choosing a license, github has created a license picker tool

How did I find you?

I'm using a script to collect stats on gems, originally looking for download data, but decided to collect licenses too,
and make issues for gemspecs not specifying a license as a public service :)
So far it's going pretty well.
I've written a blog post about it

add PostgreSQL support for dumping/importing tasks

Add some configurations to the ash/base.rb file that will allow the user to define which storage system they are using. MySQL will be the default, but Postgre could be added in fairly easily. NoSQL solutions would be nice but will have to wait their turn

handle symlinking of robots.txt

Staging environment's version of robots.txt should block all search engines from indexing the site

User-agent: * - Disallow: /