cool な方法がわからないので、一旦は実現方法だけメモ。
[設定]-[commands] の冒頭に以下コマンドを追加する。
export RUBY_VERSION=1.9.3-p194
curl -s https://repository-cloudbees.forge.cloudbees.com/distributions/ci-addons/ruby/use-ruby | source /dev/stdin
export PATH=/scratch/hudson/rubies/ruby-1.9.3-p194-i686/bin:$PATH
これで コマンド中にrubyバージョンを確認するコマンドを入れてみて確認すると
+ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux]
となっている。
プロジェクトを有効化した直後のビルドログをみると use-ruby が必要最低限のセットアップを行なっているようだ。
実際には 各workspace にuse-rubyが組み込まれて、実行されているのかな。
use-ruby にはこのように書かれていて
export RUBY_VERSION=1.8.7-p352
curl -s https://repository-cloudbees.forge.cloudbees.com/distributions/ci-addons/ruby/use-ruby | source /dev/stdin
この設定をなんとか
export RUBY_VERSION=1.9.3-p194
とできれば 色々うまくいきそうなのだけれど、use-ruby は ユーザーがcommandsに書いたコマンドよりも前に設定される。ので use-rubyが実行された後で RUBY_VERSION だけ変えてもなにも変化しない。
というわけで暫定的に curl もcommands で実行するようにした。
川口さんが作ったプロダクトだし、こんな実現方法にするわけはないとは思うので、もっと簡単な方法がありそうなのですが、何か仕組みの考え方が間違っていたり、もっと coolな実現の方法があれば教えていただきたいです。
参考
CloudBees DEV@cloud (Jenkins as a Service) Documentation
BuildHive を利用し始めた。
BuildHiveは CloudBeesのDEV@cloudの一環らしい。Jenkins界隈では知らない人はいない @kkawaこと川口耕介氏が関わっているサービスだ。
噂には聞いていたけれど、実際に使ってみるとこれは Cool なサービスだ。
できるコトは jenkins でできるコト (つまりはCI) と同じだが、
(今のところ)Jenkins のplugin を入れることはできないようなので自由度は低いのかもしれない。
でも初期導入コストが段違いだ。
- BuildHive に GitHub経由でサインアップ
- 自分の GitHubリポジトリの一覧が表示される (参加している organization のリポジトリも含まれる)
- 有効化のボタンを押す。
たったこれだけで CI 環境が Cloud上に構築される。
GitHub Hook しているので リポジトリに push が行われるとちゃんと ビルドされるし、
organization のリポジトリなら他のメンバがビルドした内容をそのまま共有できる。
有効化時にある程度リポジトリの種類を判別して、ビルドの設定も適用してくれるようだ。
Ruby on Rails なら
bundle install
bundle exec rake
といった具合に。
なんとも Cool だと思わない?
詳細はコチラ
BuildHiveをリリースしました – 川口耕介の日記
ScrumBC in 大阪に参加してきた。
詳細なレポートは
Scrum BootCamp大阪に参加してきました #scrumbc – 亀岡的プログラマ日記
に譲るとして
今回思った事など。
やっぱりワークショップはオモシロイ。
ネタバレ禁止な気がするのであんまり書かないけれど
やっぱりチームにはワークショップを定期的にやってもらいたい。
色んな気づきが得られるコト間違いなし。
なんの為にスクラムでやりたいのか
大質問大会の時に思ったのは
どうやってスクラムやるかに頭がいきがちで、
なんの為にスクラムでやりたいのかを忘れがちな気がする。
「どうやったらうまく行きますか?」
「なにから始めたらいい?」
に対しては逆に
「何をどうしたいですか?」
「何のためにスクラムを選択したのか?」
を聞いてから答えたい。
それによってどうすればいいかは変わってくると思う。
(当然コンテキストによって答えは変わってくるよね)
「なんかスクラム導入したらうまく行くんですよね。」
とかいう認識は避けたい。
あと別にスクラムやりますって宣言してフレームワーク使わなくてもいいし
紹介されているやり方を全部キッチリそのままやらなくてもいいと思う。
@nawoto さんも スクラムガイドナナメ読みで
• 軽量
• 理解が容易
• 習得は非常に困難 (←なんでやねん !!)
と紹介されていて、
習得が困難なのは、習得するものではなくて、
みんながそれぞれ創りあげていくものだからと言っていたけれど
それとも合致すると思う。
スクラムマスターの背中を見て学べ!!
もうひとつ
大質問大会の時に思ったのは
質問に答えていたスクラムマスター陣のマインドがなんかすごい。
正直なにがすごいのか言い難いのだけれど、
・詳細までコンテキストを把握しようとしたり (コンテキスト依存の具体的な質問が多かったので、曖昧な答えを出して
もやもやのままで帰って欲しくないという思いからだと思う)
・質問に対する姿勢とか
・全員に合意をとって質問進めるとか (この時間すら自己組織化しようとすのか)
その空気を生で感じるコトがとてもいい勉強になりました。
# 質問の答えが抽象的すぎて役に立たないコトはよくあるし。当たり前のコトっぽくてもできてないコト多いよね。
ひたすら感謝
また関西でやるコトがあればなにかしらお手伝いしたいと思います。
ずっと喋りっぱなしの@nawotoさんと それを支えるコーチ陣 @kawaguti さん、@miholovesq さん
急遽 大質問大会に登壇された@masahirotaguchiさん
会場で設営、TAしてくれた @toshiotmさん や 関西メンバの皆さん
ありがとうございました。
そして最後にこの企画を立ちあげて大阪に ScrumBCを呼び込んだ @yohhatu に感謝します。