久々にチーム開発したのでメモ - ひげろぐ
昨年秋頃から年明けにかけてRailsで顧客のサービスをひとつ作った 久々のチーム開発で。チーム人数は3名。 せっかくなので使ったツールややり方などを備忘録的に残しておく。次いつまたチーム開発する機会があるのか知らんけど。 実践したこと プルリクベースの開発 Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー 上記のやり方が面白そうだったので試してみた。 Githubを使っていれば拍子抜けするほど簡単に流れに乗ることができた。 Git力が足りないので最初は少し大変だったが、馴れてくると細かくブランチを切ってフィーチャーごとに対応するということが開発のテンポを良くしてくれた。 コードレビューはイージーミスによるバグや既存のコードと大きく流れの違うコードが混ざるのを未然に食い止める事ができたりと、一定の成果はあった。 一方でい
CapistranoでWhenever - ひげろぐ
昨日の続き。 Whenever標準でCapistranoのタスクが用意されているので、簡単に組み合わせることができる。 deploy.rbの編集 以下の行を適当な場所に挿入。例えばロールを定義している下あたりとか。 set :whenever_command, "bundle exec whenever" require "whenever/capistrano" これだけでもうcap deployすればconfig/schedule.rbの内容がCrontabに反映されるようになる。 ロールの設定 Wheneverの対象となるデフォルトのロールは:dbになっている。 必要ならば:appに変更したり、適当に:batchなどのロールを作ってdeploy.rbに書く。 set :whenever_roles, { :batch } 複数サーバーで実行されると負荷などが面倒になりそうな処理を実行
WheneverでRailsのバッチ処理 - ひげろぐ
WheneverはCronを利用して繰り返し処理を行うためのライブラリ。 シェルコマンドやRailsのRunner、RakeタスクなどのジョブをCronで実行できる。 実際のところCrontabへの登録を補助してくれるだけなのだが、そのシンプルさがかえって分かりやすい。 バッチ処理の管理にうってつけ。 タイトルではRailsとなっているがRails以外でも利用できる。 以下はRails3での使い方メモ。 導入 Gemfileに以下の行を追加してbundle install gem 'whenever', :require => false schedule.rbの編集 config/schedule.rbにスケジュール設定を書いていく。 bundle exec wheneverize . を実行するとひな形を作ってくれるので、それを元に編集していくのが吉。 スケジュールは「every」に続
Titanium MobileとRubyMotionの比較 - ひげろぐ
双方とも脱Objective-Cを実現してくれるプロダクトだけど性格はけっこう違う。 共通で興味を持っている人が多そうなので思うところをとりとめもなく書いてみる。 取っつきやすさ iOS SDK開発未経験者がとっつきやすいのはTitanium。おそらくRuby経験者でも。 逆にiOS SDK経験者ならばRubyMotionの方が入って行きやすいかもしれない。 RubyMotionはiOS SDKのAPIをタイトになぞっているためにiOS SDKのAPIに関する知識が必要だが、iOS SDKのAPIには直感的じゃない部分が多々あって、それに馴染むまでけっこう時間がかかる。その学習コストがけっこう高い。 TitaniumのAPIはTitanium独自のものだが整理されていて扱いやすい。学習コストは皆無ではないがiOS SDKに比べればずっと楽。 またObjective-Cよりマシとは言えRub
nginx+Unicornでサブディレクトリでアプリを動かす - ひげろぐ
Passengerだと簡単だったけどUnicornだとちょっと手こずった。 nginx側 ディレクトリの準備 nginxのroot以下に任意の名前のサブディレクトリを作る。 これはRalisアプリケーションのpublicディレクトリのシンボリックリンクにする。 cd /var/www/root ln -s /var/www/my-app/current/public my-app （Capistranoを使っているのでこの例ではcurrentがついている） nginxの設定 nginxのupstreamとserverの設定を抜粋。 upstream unicorn-of-my-app { server www.example.com:8080; } server { listen 80; server_name www.exemple.com root /var/www/root; err
Unicornのダウンタイムなし再起動は考え無しに使うと危険 - ひげろぐ
UnicornのプロセスにUSR2シグナルを送ると古いプロセスを残しつつ新しいプロセスが起ち上がるので、ダウンタイムが発生しない。 というのはUnicornの利点の一つとして数えられているが、実は罠なんじゃないだろうかと思い始めた。 USR2を送った直後の状態でプロセスのリストを見ると以下のようになる。（行が長いのでプロセス名の部分だけ抜粋） akahige:# ps aux |grep unico unicorn_rails master -E production -D --path /hoge-app -l0.0.0.0:8080 unicorn_rails worker[0] -E production -D --path /hoge-app -l0.0.0.0:8080 unicorn_rails master (old) -E production -D --path /hog
CapistranoでUnicornの起動と停止と再起動 - ひげろぐ
ちょっとした気まぐれでUnicornを使ってみた。 初Unicorn。 ということでUnicorn用のCapistranoのタスクをdeploy.rbに書いた。 内容はだいたい以下の受け売り。 Capistrano tasks for starting unicorn — Gist Twiwt:Blog / jugyo : Capistrano によるデプロイ時に Unicorn の再起動に失敗することがある問題への対処 namespace :deploy do task :start, :roles => :app, :except => { :no_release => true } do run "cd #{current_path} && BUNDLE_GEMFILE=#{current_path}/Gemfile bundle exec unicorn_rails -c #{cu
Capistranoとchef-soloを組み合わせて使う - ひげろぐ
たくさんのホストをChef設定したいけどChefサーバー立てるのめんどくさいし！ でもコマンド一発ですべてのホストが更新されて欲しいし！ というわけでこの組み合わせです。 Capistranoはインストール済みでsshのログインに必要な鍵も各ホストに配ってあるものとする。 加えてChefのクックブックなどはすでに定義済みで以下のパスにある前提で。 /home/akahige/chef-repo Chefに関してはここでは深くつっこまないので、よかったら以前書いたものをどうぞ。 chef-soloで作業環境構築の自動化 | ひげろぐ Chefを試してみた | ひげろぐ sudoの設定 chef-soloはsudo経由（root権限）で実行する必要がある。 そしてCapistranoでsudoを実行するにはパスワードなしでコマンドを実行できる必要がある。 そういう事情なのですべてのホストにてs
RVMとCapistranoを組み合わせて使う - ひげろぐ
デプロイ先のRubyをRVMで入れている場合、そのRubyをCapistranoが見つけてくれないのでうまくデプロイが進まない現象が起こる。 それをうまく動かすためにひと工夫。 rvm capistrano plugin Capistranoを実行するマシンとデプロイ先のマシンの両方にRVMの1.0.1以上が入っている場合は、RVMのプラグインで解決できる。これはデフォルトで入っているので特にインストールしたりする必要はない。 deploy.rbの先頭に以下のコードを追加。 set :rvm_type, :user $:.unshift(File.expand_path('./lib', ENV['rvm_path'])) require "rvm/capistrano" set :rvm_ruby_string, '1.9.2' rvm_typeはRVMをrootでインストールしている場
nginx+UnicornでRailsのページキャッシュを使おうとしてはまった話 - ひげろぐ
ここやここを参考に設定してみたが、nginx+Unicornの組み合わせでページキャッシュが効かなかったので、ちょっと試行錯誤。 最終的には以下を参考にしてなんとかなった。 RubyonRailsMongrel 原因 nginxがキャッシュファイルを見つけてくれなかった 状況を調べてみるとキャッシュファイル自体は作られている。 しかしRailsがキャッシュファイルを作るときにパス名に「index.html」か「.html」を付加したものをファイル名とするが、nginxはこの事情を知らないので、キャッシュファイルを見つけられなかった。 なので都度Unicornの方へリクエストを振っていた。 一方Unicornは静的ファイルへのアクセスをnginxに一任していた Rails3からはProduction環境ではデフォルトで静的ファイルへのアクセスを受け付けていない。 以下デフォルトのconfig
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
