Jenkins先生とIRCの連携の巻

IRCサーバうごいたので、早速Jenkinsのビルド結果をIRCサーバに送ってみよう。
JenkinsにはIRC Pluginがあるので導入。

Jenkinsの管理→プラグインの管理→Jenkins IRC Plugin

「Jenkinsの管理」→「システムの設定」にIRC Nortification発見！有効に。

ビルドしてみる…jenkins-botきた！わーい

いや、なんかしろ(笑)

気を取り直して設定見直し。
プロジェクト単位の設定の方にあった。

再度ビルド。

できたー！連携サイコー！

IRC用のちっちゃいモニター欲しい。

かねこ( ^ω^ )

最強の開発環境をつくるぞ！

本気でやるぞ！

というわけで、グランドデザインのラフつくりました。イマイチ！
トモチンに「もっとかっこよくしたい！」って相談したら、「モノクロにするとかっこよくなりますよ～」って言われたんだけど、モノクロのやりかたはおしえてくれませんでした
(-∧-；) あいつめ。

現在導入済みの環境は、

• Jenkins
• SVN
• Redmine
• Aipo
• サーバ死活監視

ほかにもあったっけな？

次はとりあえず全部つないじゃうのがわかりやすくていいだろうと思うので、iRCサーバ作って導入済みプロダクトの通知をバンバン飛ばしてみたい！

よって次回は、iRCサーバをたちあげてみたいと思います。
楽しみ！

かねこ(゜-゜)

Jenkins導入しました

ひろっちと開発チーム用サーバつくりました。KVM上にCentOS。

サーバ名はpolyrhythm.

かっこいい！

Jenkins入れました。

メモリ不足。

スペック貧弱すぎたか( TДT)

まだまだ序の口。

かねこ(ﾟзﾟ)

vs Travis CI

CIサーバの用意めんどくさいから、オンラインのJenkinsあったらいいのになーと思っていたら、githubのリポジトリをそのまま使える、Travis CIというCIをみつけました。
とりあえずgithubのOAuthでログインして雰囲気をみて終了。

で、その後ちょっとだけコードかいたりしていたら、gmailにメールがいっぱい！！！



どうやらいつのまにか、自分のリポジトリをCI対象にしていたようだ。
ということで、せっかくなのでStill Failingを解決してずっと使えるようにしようと思います。

まず調査。

Using worker: ruby2.worker.travis-ci.org:travis-ruby-6



$ cd ~/builds

$ git clone --depth=100 --quiet git://github.com/e2kaneko/SocialLoginExamples.git e2kaneko/SocialLoginExamples

$ cd e2kaneko/SocialLoginExamples

$ git checkout -qf 4bea04f3da2290593d511804e3274821429835c1

$ export TRAVIS_RUBY_VERSION=default

$ rvm use default

Using /home/vagrant/.rvm/gems/ruby-1.8.7-p357

$ ruby --version

ruby 1.8.7 (2011-12-28 patchlevel 357) [i686-linux]

$ gem --version

1.8.15

$ rake

rake aborted!

Rubyでテストしようとしてる（笑）
.travis.ymlをリポジトリルートにおいてPHPを指定しないといけないらしい。 ということで、追加。

.travis.yml

language: php

php:
 - 5.3
 - 5.4

Using worker: php1.worker.travis-ci.org:travis-php-1



$ cd ~/builds

$ git clone --depth=100 --quiet git://github.com/e2kaneko/SocialLoginExamples.git e2kaneko/SocialLoginExamples

$ cd e2kaneko/SocialLoginExamples

$ git checkout -qf 479e254740fa4be905cfbc392eb640aa27044dfa

$ phpenv global 5.3

$ php --version

PHP 5.3.9 (cli) (built: Jan 22 2012 13:00:07) 

Copyright (c) 1997-2012 The PHP Group

Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

    with Xdebug v2.1.2, Copyright (c) 2002-2011, by Derick Rethans

$ phpunit

PHPUnit 3.6.8 by Sebastian Bergmann.



Usage: phpunit [switches] UnitTest [UnitTest.php]

       phpunit [switches] <directory>

できた。
CakePHPの場合、通常はphpunitコマンドじゃなくてcakeコマンドでテスト実行するので、スクリプトを.travis.ymlに追加してみる。

 .travis.yml

language: php

php:
 - 5.3
 - 5.4

script:
 - ./lib/Cake/Console/cake testsuite app AllTests --stderr

$ ./lib/Cake/Console/cake testsuite core AllTests --stderr

-bash: ./lib/Cake/Console/cake: Permission denied

パーミッションあるのか。

 .travis.yml

language: php

php:
 - 5.3
 - 5.4

before_script:
 - chmod -R 777 ./lib/Cake/Console/cake

script:
 - ./lib/Cake/Console/cake testsuite app AllTests --stderr

Welcome to CakePHP v2.0.4 Console

---------------------------------------------------------------

App : app

Path: /home/vagrant/builds/e2kaneko/SocialLoginExamples/app/

---------------------------------------------------------------

CakePHP Test Shell

---------------------------------------------------------------

Error: Database connection "SQLSTATE[42000] [1049] Unknown database 'test'" is missing, or could not be created.

#0

テスト用データベースに接続できなかった。
作る。

 .travis.yml

language: php

php:
 - 5.3
 - 5.4

env:
- DB=mysql

before_script:
 - sh -c "if [ '$DB' = 'mysql' ]; then mysql -e 'CREATE DATABASE test;'; fi"
 - chmod -R 777 ./lib/Cake/Console/cake

script:
 - ./lib/Cake/Console/cake testsuite app AllTests --stderr

$ phpunit

PHP Notice:  Undefined offset: 0 in /home/vagrant/.phpenv/versions/5.3.9/share/pyrus/.pear/php/PHPUnit/Util/Configuration.php on line 860

PHP Stack trace:

そういえば、コンフィグファイルなかった。

 .travis.yml

language: php

php:
 - 5.3
 - 5.4

env:
- DB=mysql

before_script:
 - sh -c "if [ '$DB' = 'mysql' ]; then mysql -e 'CREATE DATABASE test;'; fi"
 - chmod -R 777 ./lib/Cake/Console/cake
 - cp ./app/Config/const.php.default ./app/Config/const.php

script:
 - ./lib/Cake/Console/cake testsuite app AllTests --stderr

グリーン！！やったね！

SCMもCIもクラウドの時代ですよ、というわけで、おやすみなさい。

かねこ（＾ν＾）

FacebookのCIのはなし

「Facebookには、テストサーバが存在しない。すべての開発者は本番サーバで直接開発・リリースしている。」という話があるようですが、少なくとも開発者ならこの話を文面通りに受け取る人はいないはずで、CIでバッチリ管理してるだろうということで、少し調べてみた。


まず、

• http://www.quora.com/What-kind-of-automated-testing-does-Facebook-do
• For our PHP code, we have a suite of a few thousand test classes using the PHPUnit framework. They range in complexity from simple true unit tests to large-scale integration tests that hit our production backend services. The PHPUnit tests are run both by developers as part of their workflow and continuously by an automated test runner on dedicated hardware. Our developer tools automatically use code coverage data to run tests that cover the outstanding edits in a developer sandbox, and a report of test results is automatically included in our code review tool when a patch is submitted for review.
• For browser-based testing of our Web code, we use the Watir framework. We have Watir tests covering a range of the site's functionality, particularly focused on privacy there are tons of "user X posts item Y and it should/shouldn't be visible to user Z" tests at the browser level. (Those privacy rules are, of course, also tested at a lower level, but the privacy implementation being rock-solid is a critical priority and warrants redundant test coverage.)

テストちゃんとやってますよ、と。

Watirてのは初めて聞いた。こんどドキュメント見てみよう。

そして、

• http://framethink.blogspot.com/2011/01/how-facebook-ships-code.html
• ops team runs code releases by gradually rolling code out
• facebook has around 60,000 servers
• there are 9 concentric levels for rolling out new code
• [CORRECTION thx epriest] "The nine push phases are not concentric. There are three concentric phases (p1 = internal release, p2 = small external release, p3 = full external release). The other six phases are auxiliary tiers like our internal tools, video upload hosts, etc."
• the smallest level is only 6 servers
• e.g., new tuesday release is rolled out to 6 servers (level 1), ops team then observes those 6 servers and make sure that they are behaving correctly before rolling forward to the next level.
• if a release is causing any issues (e.g., throwing errors, etc.) then push is halted.  the engineer who committed the offending changeset is paged to fix the problem.  and then the release starts over again at level 1.
• so a release may go thru levels repeatedly:  1-2-3-fix. back to 1. 1-2-3-4-5-fix.  back to 1.  1-2-3-4-5-6-7-8-9.

最小レベルはサーバ６台構成。概念が違うだけで、p1=テスト、p2=ステージング、p3=本番　でした。

サーバ多くなってくると、いろいろな工夫が必要になってくるね！

かねこ(・ε・)