GitHubのdefunktが作ったCIサーバ cijoeは、とても簡単に使えるので小さなプロジェクトではおすすめ（Jenkinsのような充... - Sooey
GitHubのdefunktが作ったCIサーバ cijoeは、とても簡単に使えるので小さなプロジェクトではおすすめ（Jenkinsのような充実機能はありません）。 ためしに、巷で話題のamatsuda/kaminariのテストをcijoeで実行してみましょう。 まずはcijoeをインストール。 $ gem install cijoe 手元のSnowLeopard + Ruby 1.9.2だとkaminariのbundle install中にlinecacheのインストールでコケてしまうので、1.8.7を使います。 $ ruby -v ruby 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin10.5.0] まず、ビルド対象のリポジトリをローカルに持ってきて、rake specが成功するところまで確認します。 $ git clone https:/
ビルドシステム構築に関して - wyukawa's diary
面白いエントリ見つけました。 ビルドシステム構築スキルの重要性 - 達人プログラマーを目指して いやー、もう本当によくわかる。 100KSのコンパイルも通らないJavaコードより1KSのbuild.xmlのほうが重要だったりするんだけど、その必要性はあんま理解されてない。 そのせいかビルドスクリプトが無くてビルドがIDE依存なプロジェクトって結構あると思う。そういうプロジェクトって文字コードがらみの問題でjavacでコンパイルしようとすると、java.nio.BufferOverflowExceptionとかで落ちたりするわけだ。 ＃Eclipseでコンパイルできるからといって、javacでコンパイルできるわけではない。 最初からビルドが自動化されてCIしていればこのような問題はもちろんすぐ気づく。 小規模プロジェクトであれば、ビルドが手動でもなんとかなるだろうが、大規模だとつらい。 そこ
ビルドシステム構築スキルの重要性 - 達人プログラマーを目指して
忙しいプロジェクトだとどうしてもおろそかにされがちなところですが、maven2やant+ivyを使ってビルドやリリースの自動化を行い、Hudsonなどの継続的結合環境上で動作させることは、開発生産性向上のために欠かせないことです。ビルド自動化はアジャイル開発なら当然必須ですが、そうでないウォーターフォールのプロジェクトであっても、是非取り入れたいことです。 そこで、意外な盲点となるのが、正しくビルドスクリプトを作成して、メンテナンスするプログラマーのスキルが非常に重要であるという点です。こういったビルドスクリプトはあくまでも最終納品物ではなく、生産性向上のためのツールという位置づけのためか、多くのプロジェクトではきちんとした工数や担当者がアサインされることなく、仕事の合間に知識のあるプログラマーがボランティアで開発するというケースも多いのではないでしょうか。しかし、最近の複雑なアプリケーシ
自動ビルド環境とHudson - torutkのブログ
「継続的インテグレーション」ツールHudsonを使った最初の一歩です。新しいツールは使いはじめるのに敷居があるので、Hudsonにおける敷居を越える参考にと日記をしたためてみました。 前置き 現在のプロジェクトでは、毎週リリースを行っているのですが、有人作業のため、作業を開始してビルドエラーが発生すると、そのたびに関係者を聞きまわって調整して、という作業が入ります。 ビルドの自動化（定期化）は、当初からの出来たらいいなリストに挙げられていますが、手が回らずに後回しになったまま現在に至っています。試験作業のウェイトが増えてきた時期に、ビルド専任者が外され、ますます手が及ばなくなってしまいました。リリース作業が大事になってくるプロジェクト終盤ですが、予算的要因のためいる人間で何とかしろと・・・（大規模だ〜といいながら、ビルド担当、構成管理担当が専任化されない・・・）。 ビルドの自動化で思いつく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
