Team Geek

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

タイトルは聞いたことありましたが、あんまりピンと来なかったのでスルーしていました。が、QiitaやKobitoを作る開発チームの文化 - Qiita Blogでお勧めされていたので買ってみました。

正直もっと早く読めば良かったと思える本です。例えばこちらのブログ、小野和俊のブログ:HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜にも書かれていますが、言っていることが正しくとも言い方一つで人間関係は大きく変化してしまいます。（悪い方への変化は特に簡単です） そこでお互いが謙虚に、相手を尊敬・信頼して接するようになれば、少なくとも悪い方向には進まないんじゃないかと思います。

かくいう自分もHRTを欠いた振る舞いのせいでチームの人との人間関係を悪化させてしまったことがありますし（これは今でも後悔してます）、逆に本書の言うところの「悪いマネージャー」に遭遇してストレスで身体を壊してしまったこともあります。

コンピュータを扱う仕事とはいえ、最後は人対人であることを肝に銘じて、今後はチームを良い方向に進められていければなと思います。

jUnit実践入門

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)を読み終わったので、引き続きjUnit実践入門を読み始めます。もうすぐ次のプロジェクトが始まるのでそこではTDDを導入していければと思ってます。今でもテストは書いてますが、先にテストを書くというのが徹底できていないので。

チーム開発実践入門を読んでみて

本に書かれている「こうあるべき」という部分といまのプロジェクトを比較しながら読んでみると色々足りてない部分が明確になったので、次のプロジェクトではなるべく取り入れていきたいと思います。今の現場で、書かれているツール等を導入するのはそんなにハードルは高くないはず、というか多分他のチームで導入しているものがあるはずなので、そこは上手く情報を共有して貰いながらやっていければ良いかなと思います。

第3章まで読了。DBマイグレーションの部分がちょっと理解できてないのはこの類のツールを使ったことがなくてどういう動きをするのか分かってないからだと思う。とりあえず先に進もう。

— ナミキマサトシ[撃沈] (@m_namiki) 2014, 4月 19

寝て起きて5章まで読了。チケット管理はやれてるしsvnとも連携させてるから問題ないかな。ただこの前保守・運用の部分に問題がありそうなのが分かったので、そこを上手くチケットベースに変えていけるといいかもしれない。

— ナミキマサトシ[撃沈] (@m_namiki) 2014, 4月 19

CIは今のプロジェクトではやれてないけど、次のプロジェクトでは必ず導入しよう。基本的にビルドはMavenだしテストコードもちゃんと書いていくので。っていうか前のプロジェクトでは導入してたんだよな。

— ナミキマサトシ[撃沈] (@m_namiki) 2014, 4月 19

6章、7章読了。今のプロジェクトだとデプロイ自動化はちょっと難しそうだけどweb側はやりたい。LBAをこっちがコントロールできるなら。

— ナミキマサトシ[撃沈] (@m_namiki) 2014, 4月 20

リグレションテスト、いまはデバッガさんたちにお願いしてるけど、これも自動化していきたいところ。

— ナミキマサトシ[撃沈] (@m_namiki) 2014, 4月 20

で、Twitterでも呟きましたが、DBマイグレーションの部分があんまりよく理解できていないです。そもそもどういう動きをするのかとか、嬉しい部分は何なのかとかがイマイチ分かっていないので、ここはもうちょっと周辺情報を漁ってみたいと思います。

Sublime Textの教科書とチーム開発実践入門

Web制作者のためのSublime Textの教科書 今すぐ最高のエディタを使いこなすプロのノウハウ

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

このところSublimeTextを使っていて、各所で絶賛される意味が分かってきたのでもうちょっと便利な使い方はないかなと思い買ってみました。主にMarkdownとRubyを書くときに使っていますが、まだちゃんと使いこなせていないので。

チーム開発実践入門の方は 著者の池田さんがブログで仰ってた内容に惹かれて買ってみました。以下当該部分を引用します。

むしろのこの『チーム開発実践入門』という本は、『GitHub実践入門』、『Jenkins実践入門』、『JUnit実践入門』といった書籍の間をつなぐミッシングリンクのような本です。

最近現場で段々とチームメンバーが増えており、プロジェクトを上手に推進させていくにはどうしたら良いかと考えることが多くなってきたので、ここらでチーム開発とはなんたるかをもう一度しっかりと考えてみたいと思います。

チケット駆動開発とGit逆引き入門

チケット駆動開発

開発効率をUPする Git逆引き入門

チケット駆動開発はだいぶ前に買っていましたが載せてなかったので。最近サービスの保守・運用でうまく情報共有できていないことが発覚したため、開発チームだけではなく関係者全員（企画や他のプロジェクトも含めて）でチケットベースでやりとりが出来ないかな、と考えています。今は情報が散見していて、一目でいまこのサービスに何が起こっているのか、過去にどんなことが起こっていたのかが分からず、また不具合があっても担当者間でのメールベースのやりとりで終わってしまっているので、これをもうちょっとどうにかしたいと思ってます。開発チーム内ではチケット駆動が上手くいってきているので、うまく流用というかパターンに組み込めると良いなと思ってるんですが、はてさてどうなるか。

Git逆引き入門はまだイマイチやりたいことと実際のコマンドが結びつかないことがあるので、あったら便利そうだと思い買ってみました。で、本に書かれているSourceTreeというソフトが便利そうだったので早速入れてみようと思います。個人的にはCUIの方が好きなんですが、チームに導入しようとするとGUIの方が受け入れられやすいんですよね。SourceTreeには専用ターミナルも付属しているとのことなので、CUI／GUIのどちらでも使えるというのはいいなと思います。

ntpの導入をTDDライクにやってみる

serverspecでテストを実行できるようになったので、ntpの導入をTDDライクに進めながらやってみようと思います。まずはテストケースから。

describe package('ntp') do
  it { should be_installed }
end

describe file('/etc/ntp.conf') do
  it { should be_file }
  its(:content) { should match /server ntp.nict.jp/}
end

describe service('ntpd') do
  it { should be_enabled }
  it { should be_running }
end

実行してみると当然失敗します。

Failed examples:

rspec ./spec/default/base_spec.rb:63 # Package "ntp" should be installed
rspec ./spec/default/base_spec.rb:67 # File "/etc/ntp.conf" should be file
rspec ./spec/default/base_spec.rb:68 # File "/etc/ntp.conf" content should match /server ntp.nict.jp/
rspec ./spec/default/base_spec.rb:72 # Service "ntpd" should be enabled
rspec ./spec/default/base_spec.rb:73 # Service "ntpd" should be running
C:/Ruby193/bin/ruby.exe -S rspec spec/default/base_spec.rb failed

次にレシピですが、きっとopscodeにあると思って検索してみたらやっぱりありました。なのでこちらを使ってみます。まずはBerksfileに追加。

# chef-repo/Berksfile
site :opscode
（中略）
cookbook 'ntp'

で、インストール。

berks install --path cookbooks

これでcookbooksにntpが追加されたので、個別のパラメータを追加しています。設定はattributes/default.rbに行います。serversを追加するのと同期を行うような設定を追加します。serversは公開NTPサーバを2つ追加しておきます。

# default attributes for all platforms
#default['ntp']['servers']   = [] # The default recipe sets a list of common NTP servers (COOK-1170)
default['ntp']['servers']   = ['ntp.nict.jp', 'ntp.jst.mfeed.ad.jp'] # The default recipe sets a list of common NTP servers (COOK-1170)
default['ntp']['peers'] = []
default['ntp']['restrictions'] = []

# internal attributes
（中略）
#default['ntp']['sync_clock'] = false
default['ntp']['sync_clock'] = true

ここまで来て気付いたんですが、タイムゾーンの設定を行わなきゃダメそうです。CentOSの場合、タイムゾーンの設定は/etc/sysconfig/clockを書き換えてやれば良さそうなので、まずは今の状態を確認しておきます。

[vagrant@localhost ~]$ cat /etc/sysconfig/clock 
ZONE="UTC"

で、これを下記のように書き換えるようにして、レシピのtemplates/default/clock.erbとして保存しておきます。

# clock.erb
ZONE="Asia/Tokyo"
UTC="false"

次にrecipes/default.rbをこのファイルを使うように編集します。

file "/etc/localtime" do
  content IO.read("/usr/share/zoneinfo/Asia/Tokyo")
  action :nothing
end

template "/etc/sysconfig/clock" do
  source 'clock.erb'
  owner 'root'
  group 'root'
  mode '0644'
  notifies :create, resources(:file => "/etc/localtime"), :immediately
end
log "done copy to /etc/sysconfig/clock."

clock.erbを書き換えた後に/usr/share/zoneinfo/Asia/Tokyoを/etc/localtimeにコピーするようにしてみました。executeリソース側でacitonが:nothingとなっているのはtemplateリソースから呼ばれたときだけ実行されるようにです。

最後にVagrantfileにntpのレシピを使うように定義します。

  config.vm.provision "chef_solo" do |chef|
    chef.cookbooks_path = ["./chef-repo/cookbooks", "./chef-repo/site-cookbooks"]
    chef.add_recipe "yum"
    chef.add_recipe "rbenv"
    chef.add_recipe "ruby_env"
    chef.add_recipe "nodejs"
    chef.add_recipe "ntp"
  end

これでvagrant provisionを実行します。

vagrant provision

INFO: template[/etc/sysconfig/clock] backed up to /var/chef/backup/etc/sysconfig/clock.chef-20140402081837.835605
INFO: template[/etc/sysconfig/clock] updated file contents /etc/sysconfig/clock
INFO: template[/etc/sysconfig/clock] sending createaction to file[/etc/localtime] (immediate)
INFO: file[/etc/localtime] backed up to /var/chef/backup/etc/localtime.chef-20140402081838.206681
INFO: file[/etc/localtime] updated file contents /etc/localtime
INFO: done copy to /etc/sysconfig/clock.
INFO: package[ntp] installing ntp-4.2.6p5-1.el6.centos from base repository
INFO: cookbook_file[/etc/ntp.leapseconds] created file /etc/ntp.leapseconds
INFO: cookbook_file[/etc/ntp.leapseconds] updated file contents /etc/ntp.leapseconds
INFO: cookbook_file[/etc/ntp.leapseconds] owner changed to 0
INFO: cookbook_file[/etc/ntp.leapseconds] group changed to 0
INFO: cookbook_file[/etc/ntp.leapseconds] mode changed to 644
INFO: template[/etc/ntp.conf] backed up to /var/chef/backup/etc/ntp.conf.chef-20140402171846.501042
INFO: template[/etc/ntp.conf] updated file contents/etc/ntp.conf
INFO: execute[Stop ntpd in preparation for ntpdate]ran successfully
INFO: execute[Stop ntpd in preparation for ntpdate]sending stop action to service[ntpd] (immediate)
INFO: execute[Force sync system clock with ntp server] ran successfully
INFO: service[ntpd] enabled
INFO: service[ntpd] started
INFO: template[/etc/ntp.conf] sending restart action to service[ntpd] (delayed)
INFO: service[ntpd] restarted
INFO: execute[Force sync system clock with ntp server] sending start action to service[ntpd] (delayed)
INFO: Chef Run complete in 60.733069975 seconds
INFO: Running report handlers
INFO: Report handlers complete

templateとファイルコピーが正常に行われ、その後にntpのインストールが動作しているのが分かります。続いてテストの実行ですが、タイムゾーンの設定を追加したのでテストケースも追加しておきます。また公開NTPサーバも2つにしたのでそれのテストも増やします。

describe file('/etc/sysconfig/clock') do
  it { should be_file }
  its(:content) { should match /ZONE="Asia\/Tokyo"/ }
  its(:content) { should match /UTC="false"/ }
end

describe file('/etc/ntp.conf') do
  it { should be_file }
  its(:content) { should match /server ntp.nict.jp/}
  its(:content) { should match /server ntp.jst.mfeed.ad.jp/}
end

うーん、2行になってしまっていますが、この書き方で良いんでしょうか。もうちょっとスマートな方法がありそうですがここはこのまま実行してみます。

rake spec

C:/Ruby193/bin/ruby.exe -S rspec spec/default/base_spec.rb
.........................

Finished in 33.55 seconds
25 examples, 0 failures

無事テストが通ってntpのインストールとタイムゾーンの設定がうまくいったようです。最後に実際に時間が変更されているか確認します。

[vagrant@localhost ~]$ date
Wed Apr  2 22:54:12 JST 2014

おぉ、タイムゾーンも変更されて時間もちゃんと設定されました:-) ただあんまりTDDライクに進められた気がしないので、次はもうちょっとちゃんと進められたらいいなぁ。

参考にさせて頂いたページ

• vagrant-serverspec で TDD ライクにサーバ構築を行う - Shin x blog
• サーバの時刻設定、NTPで自動設定・時刻補正 [Fedora, RedHat, CentOS] - Linux
• NTP/推奨公開サーバ - wiki@nothing
• chef-solo で学ぶ chef の基本動作 - jedipunkz' blog
• ファイルのコピーを試してみました - pochi's weblog
• パソコンの時計 ハードウェアクロックとシステムクロック

digをインストールする

チュートリアル環境にnslookupもdigも入っていなかったのでインストールしておきます。

[vagrant@localhost ~]$ dig
-bash: dig: command not found
[vagrant@localhost ~]$ nslookup
-bash: nslookup: command not found
[vagrant@localhost ~]$ 

[CentOS] digコマンドをインストールするの巻 - TrippyBoyの愉快な日々 を参考にすると、bind-utilsを入れればいいことが分かったのでレシピとテストケースに追加します。

# chef-repo/site-cookbooks/ruby_env/recipes/default.rb
package "bind-utils" do
  action :install
end

# spec/default/base_spec.rb
describe package('bind-utils') do
  it { should be_installed }
end

あとはvagrant provisionしてテストケースを実行するだけ。

cd rails3_tutorial
vagrant provision
rake spec
C:/Ruby193/bin/ruby.exe -S rspec spec/default/base_spec.rb
................

Finished in 33.19 seconds
16 examples, 0 failures

テストが通ったので実際に確認。

[vagrant@localhost ~]$ which dig
/usr/bin/dig
[vagrant@localhost ~]$ which nslookup
/usr/bin/nslookup

無事にインストールできました:-)

あとどうでも良いことですが、記事の書き方をはてな記法からmarkdown記法に変更してみました。GitHubでも使えるし覚えておく必要があるかなと。この書き方はかなり楽ですね。改行が半角スペース2つっていうのが微妙に面倒ですが。

serverspecのテストケースを育ててみた

前回の記事で作成したserverspecのテストケースを育ててみました。Ruby on Railsチュートリアルの写経を始めました - m-namikiの日記のときに作成したレシピを対象にします。レシピはこんなことをやっていました。

• iptablesの停止、無効化
• epel、remiをyumのリポジトリに追加
• sqlite-develのインストール
• rbenvでruby1.9.3-p545のインストール
• gemでrbenv-rehash、rails3.2.14のインストール

で、追加したテストケースはこちら。

# package for rails3-tutorial
describe package('sqlite-devel') do
  it { should be_installed }
end

# ruby versions
describe command('ruby -v') do
  it { should return_stdout /ruby 1\.9\.3p545.+/ }
end

# for gem packages
describe package('rbenv-rehash') do
  it { should be_installed.by('gem') }
end

describe package('rails') do
  it { should be_installed.by('gem').with_version('3.2.14') }
end

epel、remiに関しては最初に書いたときに入れていたので割愛します。で、さっそく実行してみると

C:\Users\m-namiki\Documents\20_vagrant\rails3_tutorial>rake spec
C:/Ruby193/bin/ruby.exe -S rspec spec/default/base_spec.rb
..........FFF

Failures:

  1) Command "ruby -v" should return stdout /ruby 1\.9\.3p545.+/
     Failure/Error: it { should return_stdout /ruby 1\.9\.3p545.+/ }
       sudo ruby -v
       ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
       expected Command "ruby -v" to return stdout /ruby 1\.9\.3p545.+/
     # ./spec/default/base_spec.rb:36:in `block (2 levels) in <top (required)>'

  2) Package "rbenv-rehash" should be installed
     Failure/Error: it { should be_installed.by('gem') }
       sudo gem list --local | grep -w -- \^rbenv-rehash
       expected Package "rbenv-rehash" to be installed
     # ./spec/default/base_spec.rb:41:in `block (2 levels) in <top (required)>'

  3) Package "rails" should be installed
     Failure/Error: it { should be_installed.by('gem').with_version('3.2.14') }
       sudo gem list --local | grep -w -- \^rails | grep -w -- 3.2.14
       expected Package "rails" to be installed
     # ./spec/default/base_spec.rb:45:in `block (2 levels) in <top (required)>'

Finished in 27.6 seconds
13 examples, 3 failures

Failed examples:

rspec ./spec/default/base_spec.rb:36 # Command "ruby -v" should return stdout /r
uby 1\.9\.3p545.+/
rspec ./spec/default/base_spec.rb:41 # Package "rbenv-rehash" should be installe
d
rspec ./spec/default/base_spec.rb:45 # Package "rails" should be installed
C:/Ruby193/bin/ruby.exe -S rspec spec/default/base_spec.rb failed

残念、失敗！エラーメッセージを見るとsudoしているので、rbenvでインストールしたrubyのバージョンが違ったり、gemで認識されていなかったりするようです。なのでまずはvagrantユーザで実行しているrubyとgemはどこを見ているのか確認してみます。

[vagrant@localhost ~]$ which ruby
/opt/rbenv/shims/ruby
[vagrant@localhost shims]$ which gem
/opt/rbenv/shims/gem

なるほど、ならばリソースタイプがcommandの場合はこのパスを追加してあげれば良さそうですが、packageの場合はどうしよう。答えは公式ドキュメントに書いてありました。ページ下段の方にあるBlock scoped PATH environment variableを読んでみるとブロック内でPATHを指定することができるようです。なので以下のように書き換えてみました。

# ruby versions
describe command('ruby -v') do
  let(:path) { '/opt/rbenv/shims' }
  it { should return_stdout /ruby 1\.9\.3p545.+/ }
end

# for gem packages
describe package('rbenv-rehash') do
  let(:path) { '/opt/rbenv/shims' }
  it { should be_installed.by('gem') }
end

describe package('rails') do
  let(:path) { '/opt/rbenv/shims' }
  it { should be_installed.by('gem').with_version('3.2.14') }
end

同じ設定を3回書いてるのがちょっとアレですが、これで実行してみます。

C:\Users\m2-namiki\Documents\20_vagrant\rails3_tutorial>rake spec
C:/Ruby193/bin/ruby.exe -S rspec spec/default/base_spec.rb
...............

Finished in 29.69 seconds
15 examples, 0 failures

今度は無事に成功しました。公式ドキュメントは隅々まで読まなきゃダメですね。。。あとはChefでrbenvを使ってRubyをインストールするCookbookを書いた | ひげろぐを参考にさせていただき、最終的なテストケースはこんな感じになりました。
serverspecをvagrantと連携させるためのプラグイン（vagrant-serverspec）もあるそうなので、今度はこちらも試してみようと思います。