今、「 Jenkins実践入門 ビルド・テスト・デプロイを自動化する技術」という本を執筆しています。 Jenkins実践入門ではJenkinsの生みの親である@kohsukekawa さんに監修と序論をお願いしています。 # @kohsukekawa さんと同列で自分の名前があるのが、恐縮です。 日本語で書かれたJenkinsの本として、日本初の書籍になる予定です。 Amazonでのご予約はこちらJenkins実践入門　〜ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus) 川口 耕介 監修,佐藤 聖規 監修・著,和田 貴久,河村 雅人,米沢 弘樹,山岸 啓 著 技術評論社 2011-11-11 売り上げランキング : 1972 Amazonで詳しく見る 執筆はちょうど組版が終わり、外部レビューや最終修正中です。 今日、表紙が完成して、タイトルがFixしました。

環境依存の情報の管理やHudsonのジョブ設計など - watawata日記に触発されて。自分もちょうど考えてることがあったのですが、140字ではとても足りないのでブログにまとめてみます。 ちなみにJava開発の話です、はい。 前提 「ビルドスクリプトは、IDE/CIに依存しないこと」が大事だと考えています。（Java開発においては）IDE上で開発する方が大多数だと思いますが、コマンドプロンプト・シェルスクリプト上でビルドできて、かつCI上でも同様に実行できること。これがビルド環境を考える上で大事なことですね。 プロジェクトの分類 ここでは、2つの要素でプロジェクトを分類します。 依存ライブラリ管理の仕組みが有るか？ IDE上で、プロジェクト間での直接参照が有るか？ 依存ライブラリの管理というのは、平たく言えばMaven/Ivyを導入しているか？ということです。IvyはAntベースで、Ma

思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。

年末で、もう仕事納めてますが、空気を読まずに仕事ネタです。メモだけとって、blog にアップしてなかったので。。。 最近、CI ツールを CruiseControl.net から Hudson に移行しました。 まず、Trac を(Hudson が入っている)最新バージョンまでアップグレードしてから、Hudson を最新バージョンに入れ替え。 あとは↓見ながら「サービス化」を実施 Hudson をちゃんと始めてみようと思います - かおるんダイアリー で、↓見ながら、MSBuild Plugin を有効化+NUnit の実施。 Redsolo’s blog site: Guide to building .NET projects using Hudson 基本的には、MSBuild Plugin でビルドし、バッチコマンドで NUnit を叩き、NUnit publisher で受けるだ

.NET開発の継続的インテグレーション(Continuous Integration)の仕組みとして、Hudsonが利用出来ます。その備忘録を残します。 ここでHudsonがやっていること Subversionからソースファイルを取得する MSbuildでビルドを実行する NUnitで単体テストを実行する これだけです。 Hudsonに以下のプラグインを導入します MSBuild Plugin NUnit Plugin HudsonにMSBuildプラグインを導入 http://wiki.hudson-ci.org/display/HUDSON/MSBuild+Plugin msbuild.hpi をダウンロード HudsonにNUnitプラグインを導入 http://wiki.hudson-ci.org//display/HUDSON/NUnit+Plugin nunit.hpi をダウ

こんな具合で，HudsonのテストトレンドをTracに貼る。 ただそれだけ。 {{{ #!html <h3>テスト結果の傾向</h3> <a href="http://example.com:8080/hudson/job/sample-job/"> <img src="http://example.com:8080/hudson/job/sample-job/test/trend"> </a> }}}でも見た目はそれなり。:-D ウチの会社も，SWEBOKのバッタモン配るくらいなら，これ配ればいいのに。 id:matarilloが書評書いてくれる事を期待してる。:-P ドメイン駆動 (Programmer’s SELECTION) 作者: Jimmy Nilsson,尾島良司,株式会社ロングテール長尾高弘出版社/メーカー: 翔泳社発売日: 2008/03/20メディア: 大型本購入: 8

原則として、データベースに対する作業は必ずバージョン管理しなければならない、と強く主張した記事を投稿した後で、Scott Allen氏はデータベースのバージョン管理を最大限に利用する手法について詳しく述べている。彼は、ベースラインを作成し、スキーマのリビジョン管理に変更スクリプトを使い、データベースの（ビューやストアドプロシージャ、ファンクション、トリガ等の）プログラムされたオブジェクトを管理し、そしてブランチやマージ処理を利用する、包括的で実用的な手法を紹介している。 Allen氏は自身の経験から学んだことを、関係データベースを使用した開発のための３つのルール(source)として記載した記事を投稿した後で、一連の投稿を始めた。そのルールとは、: 1. 開発作業には、共有データベース・サーバは決して使用してはいけない。 ソフトウェア開発におけるたくさんの便利なもののように、共有データベー

id:Ewigkeitのブログで、CIについてはここのブログ読んでね、と言及されたんですが、対象記事はCIについてあまり書かれておらず、しかも、古い記事を調べてみてもいい内容がなかったので、ここで改めて「継続的インテグレーション」について説明します。 「継続的インテグレーション（以降、CI*1）」とはXPのベストプラクティスの一つです。 原典として、マーチン・ファウラーの論文があります。 ここでは頻繁にインテグレーション作業を行うと、少し難しく表現されていますが、ものすごく簡単に言いますと、デイリービルドやナイトリービルドのように1日に1回ビルドするのではなく、1日に何回もビルド*2を行う、ということです。 また、プロジェクトの後期に行われるモジュールの結合やシステムテストといったことも1日に何回も行います。 具体的な例として、 チェックアウト コンパイル Unitテスト パッケージング

JJUGでのHudsonの発表と、Sunのホット・トピック・セミナーでしたMetroの発表を以下の場所で公開しました。 Hudson (JJUG CCCにて)View SlideShare presentation or Upload your own. ホット・トピック・セミナー「Metro」View SlideShare presentation or Upload your own. ところどころスライドが崩れているところがありますが、ご了承下さい。

RedmineやTestLink、Hudsonなどのツールは一体何を改善して、何を目指しているのか？ 一言で回答するならば、これらのツールはいわゆるSW構成管理をIT化するツールなのだ、と考えればよい。 つまり、下記のイメージだ。 Excelで進捗管理していた →Redmineでプロジェクト管理をIT化 ソースや仕様書を履歴共有できる仕組みが無くファイルを日付管理していた →Subversionで共同所有 Excelでテスト仕様書を管理していた →TestLinkでテスト仕様書をWeb化 手作業でビルドしていた →Hudsonでビルドを自動化(継続的インテグレーション) 我々IT技術者は、お客様がExcelやAccessで運用している業務をIT化、Web化するのが主な仕事なのに、肝心の自分たちのプロジェクト管理の殆どは、Excelで運用して四苦八苦しているだろう。 日本の殆どのSIerで働

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。 ＃あくまでもメモ書き。 【元ネタ】 ■[development][trac]構成管理ツールをいかにして導入するか ■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？ ■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 ソフトウェア構成管理 【1】バージョン管理が無かった頃 今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。 その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理　にその理由が書かれている。 ほっておくと自然増殖してくるのが、下記のような形式のドキュメント

SIerはお客様の業務をIT化するのがお仕事なのに、自分たちの業務は意外とIT化しきれていない。 大量の印刷した紙、手作業の多い仕事に囲まれている。 ソフトウェア開発のインフラを考えると、最低3個の環境は必須だ。 一つは、ソースコード管理。 二つ目は、検証可能なビルド環境。 そしてBTS。 この3つについて考えてみる。 【1】ソース管理 プログラミングで仕事するならば、ソース管理(SCM)は必須だ。 ソース管理システムの本質は、前回のプログラムへUndoができること。 つまり、プログラムの履歴が残っているからこそ、前バージョンへUndo、Redoができる。 ソース管理は、MSならVSS、普通は、CVSかSubversionを使うのが普通だろう。 ソース管理で重要な作業はブランチやタグ付けができること。 ブランチは、枝分かれしたバージョンツリー。 タグは、ある時点でバージョン付けられたソース

ソフトウェア開発の初期コストと保守コストのグラフの良い記事があったのでメモ。 Miros?aw Jedynak - professional .NET blog: 6 steps to successful Continuous Integration (引用)それぞれの方法について，初期コストと維持コストの対比が提示されているところが印象的。感覚的だけど，このグラフは同意できる。 6つの観点の比較だが、経験的に非常に共感する。 この記事の主張は、「統合ビルドは重要！」の一言。 1. Use source code repository (引用)「SCM使えって当たり前だろ」と思いつつも，未だにOSのファイル共有だけってのもあるからなぁ。現実は小説より奇なりダ。 これは鉄板。SCM使う発想がない時点で，そのプロジェクトは終わってる。 非常に同感。 開発の現場は、教科書よりも奇なり。 SCM

XPのプラクティスの一つが常時統合(CI・Continuous Integration)。 別名、デイリービルドと言われる。 第2世代CIツールと言われるHudsonを使って運用して、常時統合の概念について改めて書く。 #Hudsonの全機能はまだ使いこなせてないので念のため。 【1】バージョン管理(SCM)＋常時統合(CI)＋テスト駆動開発(TDD)で、初めてアジャイル開発が可能になる 【元ネタ】 バージョン管理と常時結合 豆蔵：継続的インテグレーション（CI）をしましょう Subversionでbranches/tags/trunkでソース管理したら、次に行うべき環境構築はビルド環境。 Javaなら、Ant/Mavenでワンクリックでビルドできるようにスクリプトを作る。 今でもビルドする時に、Eclipseから手作業でビルドしているプロジェクトもままある。 ローカルマシンで手作業でビル