![Amazon.co.jp: Jenkins: John Ferguson Smart (著), Sky株式会社玉川竜司 (翻訳): 本](https://cdn-ak-scissors.b.st-hatena.com/image/square/01811901219a5fd2150b7cee44b5acf5d76b0cb4/height=288;version=1;width=512/https%3A%2F%2Fm.media-amazon.com%2Fimages%2FI%2F51v-MV54goL._SL500_.jpg)
同僚の@papandaからの依頼とあれば断わる理由はないので、DevLOVE HangarFlight - Snow Barrage -で、Jenkinsを中心としたCIとそのインフラについてお話ししてきました。 Jenkins勉強会で発表した内容に、それから半年の動きを足した内容となっています。 主たるコミュニケーションツールであるIRCを中心として開発者が開発に集中できること 有限のサーバリソースをどう使って快適なCI環境を手にいれるか ということが、ここ1年くらいホットなトピックだったので、そのために私たちがやっている取り組みをお話させていただきました。 何人かの方から、JenkinsとIRCと会話するのは面白い、GanetiやTravisは知らなかったけど興味が湧いたという声を頂いて、発表してよかったなぁと思いました。 また、懇親会では、Vundleの記事やWeb+DBの特集がよか
みなさんこんにちは。@ryuzeeです。 なんとなく書きためておいた継続的インテグレーションのアンチパターンをいくつか紹介します(結構ラフなメモ書き)。 頻繁にSCMにコミットしないテストコードを書かないテストコードと製品コードを同時にコミットしない定時ビルドのみでコミットビルドがない・夜間ビルドしかない帰り際にコミットしてそのままCIの結果を見ずに帰るCIでテストを通すために手作業の準備が必要メインラインのみで大きなブランチをCI対象にしていない様々な種類のテストをまとめて行っているビルドの失敗に気付かないビルドに失敗しても放置しているビルドの失敗に気づいても、修正コード以外のコードをコミットする何も変更していないのにビルドが落ちたり落ちなかったりする頻繁にビルドが失敗しているので、失敗するのが普通だと思うCIからの通知メッセージが大量すぎるCIが落ちても何も通知しないCIサーバのリソー
みなさんこんにちは。@ryuzeeです。 Jez Humble氏のContinuous Delivery vs Continuous Deploymentが分かりやすいので抜粋・意訳にてご紹介します。 (翻訳部分はCC-BY−SAとします) ティモシー・フィッツの継続的デプロイに関するブログは、デイブと私が継続的デリバリーについての本を出版する1年以上も前に、すでに書かれていた。そんな中でなぜ私たちは異なる名前を選んだのだろうか。実際に違いはあるのだろうか?それとも単に我々が不親切なだけなのだろうか? 我々はいくつかの理由で本の名前を「継続的デリバリー」とすることにした。まず第一に、デプロイがリリースを意味しないというちょっと学者ぶった事実。我々が本の中で言っているように、継続的に顧客受け入れ環境にデプロイすることはできるだろう。それ自体はたいしたことはない。継続的デプロイを特別なものにす
CIツールであるJenkinsの解説書です。目的に応じて、様々な設定について説明されています。継続的インテグレーションやJenkinsに興味がある人にとっては、導入する際に手元に置いておいて参考にすることができます。すでに、Jenkinsを使用している人であれば、自分が知らない新たな発見があると思います。 継続的インテグレーションは、どのような開発プロセスを使用していても必須だと言っても過言ではありません。ウォータフォール開発しているとかアジャイル開発ではないから関係ないというものではありません。 この本のカバーには次のように書かれています。 「手作業でミスが多発」 「別の環境だとビルドできない」 「結合テストで修正地獄に] 「リリース直前なのに動作しない」 ↓ 自動化でストレスはゼロに 品質は最高に どのようなソフトウェア開発でも起きる問題なのです。 私自身が初めてビルド作業を完全自動化
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:/
先日行われたRuby勉強会@札幌-18で、Ruby勉強会にもかかわらず空気を読まず、継続的インテグレーションについて発表しました。 継続的インテグレーション - Ruby勉強会@札幌-18 View more presentations from hotchpotch 継続的インテグレーションは複数人開発ではやるべき価値がある手法だと思ってますが、実際に実践してみないと価値をなかなか体験できない物だと思っています。 継続的インテグレーションについて語る際に、言葉で伝えにくい部分がある。それは、継続的インテグレーションは開発全体に関わる「パターン」への移行をもたらすものだということであり、こればかりは、実地で体験してみないと理解しがたいのだ。 継続的インテグレーションの恩恵 スライドの中では、実際にクックパッドで継続的インテグレーションを行っていて感じた価値、その結果変わった開発サイクル・プ
追記: 公式プラグインになりました。Websocket Plugin - Jenkins - Jenkins Wiki 「pollingが許されるのは小学生までだよねー キモーイ キャハハハハハハ」というわけでビルド結果をpush通知するJenkinsプラグインを書きました。 特徴 Jenkinsのビルド結果をWebsocketを使って通知します。 モダンなブラウザはWebsocketに対応しているので、Javascriptで簡単に通知を受け取れます。 Websocketはプラットフォームに依存しないプロトコルなので、Javascript以外でも通知を受け取れます。 インストール方法 https://github.com/mzp/unageel/archives/master からwsnotifier.hpiをダウンロードする。 wsnotifier.hpiをJenkins の管理 > プ
6/18 に開催された開発環境勉強会 in Nagoya #1で CI っぽい話と Vim の話をしてきました。 CIのその先へ View more presentations from bleis tift Vim再入門 View more presentations from bleis tift @kei10in / Vim 結構ぱないね.使わないけど! #devstudy @sunflat / Vim奥が深い #devstudy @kaizen_nagoya / vim長年使っていたが、使っていない機能を覚えれた。#de... @fate_fox / Vimのことがさらに好きになった #devstudy @youku_s / 家に帰ったらvimプラグインをいろいろ試そう。補完系しかい... Emacs 使いの人にも Vim のいいところを伝えることができたのはよかったですね。 ちな
2011/06/06 5月24日、日本Javaユーザグループ(以下、JJUG)の主催による「JJUG Cross Community Conference(以下、JJUG CCC) 2011 Spring」が行われた。JJUG CCCはJJUGが年2回開催している定例イベントであり、Javaに関する最新の動向や活用事例などが紹介される。 本稿では、オープンソースのCIサーバ「Jenkins」の生みの親である川口耕介氏による基調講演の様子をお伝えする。 「Jenkins」はソフトウェアプロジェクトのビルドやテストを自動化する継続的インテグレーション(CI:Continuous Integration)サーバの一種である。もともとは「Hudson」という名称で開発・公開されていたが、商標上の問題によってJenkinsに改名された。 JJUG CCCの基調講演は、その生みの親であり現在もプロジェ
Jenkins Build great things at any scale The leading open source automation server, Jenkins provides hundreds of plugins to support building, deploying and automating any project. We stand with the people of Ukraine. Please assist humanitarian efforts for the Ukrainian people and those affected by the military invasion of Ukraine by supporting international aid organizations, including the Ukrainia
ストーリー by reo 2011年02月01日 11時00分 ツンの後にデレが来ると信じて…! 部門より Oracle は昨年末から継続的インテグレーションツールである「Hudson」の商標権及びプロジェクトの管理を主張していたが (/.J 記事、SourceForge.JP Magazine の記事) 、Hudson 開発コミュニティの投票の結果、新名称「Jenkins」への改名が決定したそうだ (The H OPEN) 。 Hudson プロジェクトの開発者を対象に投票が行われたところ、214 票は Hudson から Jenkins に改名する方に投じられ、Oracle 管理を支持する票は 14 票だけであったとのこと。既に jenkins-ci.org が登録されており、Twitter アカウント及びメーリングリストも新名称に移行することとなる。当面は、本プロジェクトのクリエータ
id:Ewigkeitのブログで、CIについてはここのブログ読んでね、と言及されたんですが、対象記事はCIについてあまり書かれておらず、しかも、古い記事を調べてみてもいい内容がなかったので、ここで改めて「継続的インテグレーション」について説明します。 「継続的インテグレーション(以降、CI*1)」とはXPのベストプラクティスの一つです。 原典として、マーチン・ファウラーの論文があります。 ここでは頻繁にインテグレーション作業を行うと、少し難しく表現されていますが、ものすごく簡単に言いますと、デイリービルドやナイトリービルドのように1日に1回ビルドするのではなく、1日に何回もビルド*2を行う、ということです。 また、プロジェクトの後期に行われるモジュールの結合やシステムテストといったことも1日に何回も行います。 具体的な例として、 チェックアウト コンパイル Unitテスト パッケージング
面白いエントリ見つけました。 ビルドシステム構築スキルの重要性 - 達人プログラマーを目指して いやー、もう本当によくわかる。 100KSのコンパイルも通らないJavaコードより1KSのbuild.xmlのほうが重要だったりするんだけど、その必要性はあんま理解されてない。 そのせいかビルドスクリプトが無くてビルドがIDE依存なプロジェクトって結構あると思う。そういうプロジェクトって文字コードがらみの問題でjavacでコンパイルしようとすると、java.nio.BufferOverflowExceptionとかで落ちたりするわけだ。 #Eclipseでコンパイルできるからといって、javacでコンパイルできるわけではない。 最初からビルドが自動化されてCIしていればこのような問題はもちろんすぐ気づく。 小規模プロジェクトであれば、ビルドが手動でもなんとかなるだろうが、大規模だとつらい。 そこ
忙しいプロジェクトだとどうしてもおろそかにされがちなところですが、maven2やant+ivyを使ってビルドやリリースの自動化を行い、Hudsonなどの継続的結合環境上で動作させることは、開発生産性向上のために欠かせないことです。ビルド自動化はアジャイル開発なら当然必須ですが、そうでないウォーターフォールのプロジェクトであっても、是非取り入れたいことです。 そこで、意外な盲点となるのが、正しくビルドスクリプトを作成して、メンテナンスするプログラマーのスキルが非常に重要であるという点です。こういったビルドスクリプトはあくまでも最終納品物ではなく、生産性向上のためのツールという位置づけのためか、多くのプロジェクトではきちんとした工数や担当者がアサインされることなく、仕事の合間に知識のあるプログラマーがボランティアで開発するというケースも多いのではないでしょうか。しかし、最近の複雑なアプリケーシ
「継続的インテグレーション」ツールHudsonを使った最初の一歩です。新しいツールは使いはじめるのに敷居があるので、Hudsonにおける敷居を越える参考にと日記をしたためてみました。 前置き 現在のプロジェクトでは、毎週リリースを行っているのですが、有人作業のため、作業を開始してビルドエラーが発生すると、そのたびに関係者を聞きまわって調整して、という作業が入ります。 ビルドの自動化(定期化)は、当初からの出来たらいいなリストに挙げられていますが、手が回らずに後回しになったまま現在に至っています。試験作業のウェイトが増えてきた時期に、ビルド専任者が外され、ますます手が及ばなくなってしまいました。リリース作業が大事になってくるプロジェクト終盤ですが、予算的要因のためいる人間で何とかしろと・・・(大規模だ〜といいながら、ビルド担当、構成管理担当が専任化されない・・・)。 ビルドの自動化で思いつく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く