Capistrano3を最後にもう一度だけ懇切丁寧にまとめてみる - そのねこが学ぶとき
2017-08-15 追記 Googleの「Capistrano」検索順位で上位にあるためか、いまだにこの記事がたびたびブクマされるんですが、3年前の情報ですし、執筆者はRubyを専門としたプログラマーではないのでその点ご注意ください。（追記ここまで） いろいろエントリーを上げながら苦しんでいたCapistranoだが、ようやっとそこそこ落ち着いてきた気がするのでそろそろ完結編といく。Capistranoの基本とかはすでにこちらのエントリーで書いたので、今回は各設定ファイルの書き方とか、その他ハマったポイントを中心に。 今回作成したファイル 以下4ファイルを作成した。 Capfile config/deploy.rb config/deploy/staging.rb lib/capistrano/tasks/unicorn.cap 基本的にCapistranoを使う場合「必須」なのは上2つ
Speed up assets:precompile with Rails 3.1/3.2 Capistrano deployment
The idea is that if you don't change your assets you don't need to recompile them each time: This is the solution that Ben Curtis propose for a deployment with git: namespace :deploy do namespace :assets do task :precompile, :roles => :web, :except => { :no_release => true } do from = source.next_revision(current_revision) if releases.length <= 1 || capture("cd #{latest_release} && #{source.local.
Only precompile assets when necessary (Rails 4, Capistrano 3)
The problem rake assets:precompile can take up a large chunk of time of Rails application deploys with Capistano, even on deploys where the assets haven't changed! Other solutions to skip unnecessary asset precompilation seem to rely on Capistrano 2. The solution Make these changes in your deploy.rb file: Step 1: Set the locations to look for relevant changes to trigger a precompilation set :asset
DockerコンテナをCapistranoでデプロイ
開発環境と運用環境の差異 Railsアプリの開発をMacでしている人は多いと思います。しかし本番では大抵Linuxマシンで運用するため、実行環境の違いから問題が発生することがあります。特にサードパーティ製ライブラリやツールを使う場合、MacとLinuxで同じ動作をする保証はどこにもありません。また、開発にLinuxマシンを使っていたとしても、本番と全く同じ構成で開発するのは難しいでしょう。 Dockerを使うと開発から運用まで同じ環境を使え、しかもハードウェア仮想化よりも遥かに軽量です。そこで、私が今KRAYで担当しているプロジェクトでは開発から本番まで全ての環境でDockerを使えるようにしました。 それぞれの環境で解決すべき課題がありましたが、今日は本番環境にデプロイする仕組みを紹介します（KRAYでインテグレーション環境と呼ばれる環境についてはDockerホストをプロジェクトや権限で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
