CentOS リポジトリ 追加
覚書のための記述です。CentOS6.2 x86_64で行っています。
追加するリポジトリ
EPEL、RPMforge参考にしたページ
RPMforgeリポジトリ導入(RPMforge)CentOS 外部レポジトリの追加(EPEL)
手順
- yum-prioritiesのインストール rootで以下のコマンドを実行してインストールします。
- すでにyumに設定されているCentOSのデフォルトのリポジトリの優先度をもっとも優先に設定しておきます。 完成イメージとしては、CentOS-Baseを1または2、EPELを3、RPMforgeを4とします。 CentOS-Base.repoに設定を追加します。
- EPELの導入 下記リンクにアクセスしてインストールするRPMを確認します。
- RPMforgeの導入 続いてRPMforgeを導入します。以下のリンクから最新版を確認します。
yum -y install yum-priorities
vi /etc/yum.repos.d/CentOS-Base.repoCentOS 外部レポジトリの追加(EPEL) にしたがって以下のように設定します。
[base] priority=1 [updates] priority=1 [addons] priority=2 [extra] priority=2 [centosplus] enabled=1 priority=2 [contrib] enabled=1 priority=2priorityは各要素の最後に追加し、enabledはすでにある要素を変更します。
http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/epel/5/x86_64/ epel-release-X-X.noarch.rpmをインストールします。探してクリックすると「インストールしたいですか?」と聞いてきますので、「はい」でインストールします。 インストール後、yum-prioritiesの設定を変更します。
vim /etc/yum.repos.d/epel.repoCentOSbaseと同じように以下のように設定します。
[epel] enabled=1 priority=3おそらく、enabledは設定されているはずです。priorityはブロックの最後に追加します。
http://pkgs.repoforge.org/rpmforge-release/ ファイルはrpmforge-release-0.X.X-X.el6.rf.x86_64.rpmです。EPELと同様にクリックでインストールできます。 EPELと同様にyum-prioritiesの設定を変更します。
vim /etc/yum.repos.d/rpmforge.repo以下のように設定します。
[rpmforge] enabled=1 priority=4
おわり
とりあえずこれで使っていこう。Groovy で はてなダイアリー 書く Gradle で 準備する #gadvent2012
G*な皆さん、こんにちは!
G* Advent Calendar 2012、12/19担当の@nightmare_timです。前日は、@hideokuさんの、 Geb で JavaScript のテストをしてみた #gadvent2012でした^^
今年は、6月に転職という大きな波をくぐり抜け、やっと生活が落ち着いてきた感じがあります。ばたばたは相変わらずですけども、こうやってG* Advent Calendar 2012に参加できるのもうれしく思います。では、始めます。
今回のテーマ
今回のテーマは、 「Groovyではてなダイアリーを書く」です。ぶっちゃけ言うと、ただ HTMLBuilderを使ってHTMLを生成するだけなんですが(^^;本当はHatenaAPIとかを使って自動でアップデートまでやりたいとこですが、まずはコードで原文書いてそれをGitやMarcurialで管理したいのもあって、ローカルで作成手順を作りました。きっかけは、以前行われた SCMBC NAGOYAの時に、@irofさんが言われていた 「Groovistだったら閉じタグのHTMLなんか面倒でしょ?」という発言をお聞きして、「ほう」と思ったことが始まりです。(もう8カ月も前の話xx)それまではてなダイアリーも普通にHTMLで書いていたので、「それだったらGroovyで書くかな」と思いはじめ始めました。
実際に最近は全てこの形式で書いていますので、その書き方を紹介します。後でその準備と、HTML作成してコピペベースを作るGradleスクリプトを紹介します。
GroovyでHTMLを書くHTMLBuilder
まず記述する時の書式を説明します。参考にしたのは@fumokmm(id:fumokmm)さんの記事 MarkupBuilderでHTML生成を試してみた です。ヘッダー情報等の決まった構文部
以下の様に記述します。import groovy.xml.MarkupBuilder
def writer = new File('作成するファイル.html').newPrintWriter('UTF-8')
def html = new MarkupBuilder(writer)
html.doubleQuotes = true
html.html{
body{
//本文
}
}
本文
プレーンな記述は、以下のように書きます。mkp.yield('プレーンな記述は、以下のように書きます。');全てこの形で囲うようにしてください。このmkp.yieldで渡された文字列はすべて平文としてHTML内に配置されます。
色付き文字
こういった文字を書くにはfont(color:'#00AA00','こういった文字を書くには');
リンク
G* Advent Calendar 2012a(href:'http://atnd.org/events/34317','G* Advent Calendar 2012');
箇条書き
- りんご
- みかん
- ぶどう
ul{
li{mkp.yield('りんご');};
li{mkp.yield('みかん');};
li{mkp.yield('ぶどう');};
}
表組み
果物 | 価格 |
---|---|
りんご | 100 |
みかん | 30 |
ぶどう | 150 |
table(border:'1'){
tr{th('果物');th('価格');}
tr{td('りんご');td('100');}
tr{td('みかん');td('30');}
tr{td('ぶどう');td('150');}
}
pre要素
個人的にはこれが一番 面倒です。上述の表組みのソースを示すpre要素の記述はこうなります。pre{pre要素の中に、mkp.yieldで囲った文章を列挙し、brもつける必要があります。また、 シングルクォーテーションやダブルクォーテーションはバックスラッシュでエスケープする必要があります。
mkp.yield('table(border:\'1\'){');br();
mkp.yield(' tr{th(\'果物\');th(\'価格\');}');br();
mkp.yield(' tr{td(\'りんご\');td(\'100\');}');br();
mkp.yield(' tr{td(\'みかん\');td(\'30\');}');br();
mkp.yield(' tr{td(\'ぶどう\');td(\'150\');}');br();
mkp.yield('}');
}
ヘッダー要素
h5('ヘッダー要素')
注意点
- 改行をしっかり入れる
はてなダイアリーは文章の改行コードをしっかり理解してくれるので、それに頼るとレイアウトがよく分からなくなりますので、改行はbrをしっかりつかいましょう。以下のメソッドを使います。
br();
意外にやってしまいますが、これはコンパイルエラーにならずにRuntimeExceptionになります。
}br(); //エラーになります
記事全体
当記事の全体をgistに上げておきます。ファイル全体
ビルド
HTMLと違ってGroovyコードは実行してHTMLコードを出力します。構文間違いなどはコンパイルエラーとして吐き出してくれるので、間違いが少なくなるのは間違いないのですが、やっぱり何度もやるのは骨が折れます。そこで Gradleさんの出番ですね!行いたいこと
- 決まった構文が入ったGroovyファイルを用意する。
- (手動で)HTMLBuilderを使って本文を書く。
- Groovyを実行してHTMLファイルを作成する。
- 作成したHTMLファイルの改行を取り除く
- チェック用のhtml要素とbody要素を抜いたコピペ用を作る。
作成したスクリプト
長くなりそうなので、リンクと使い方だけ説明しておきます。作成したGradleスクリプトのbitbucket:Mercurialリポジトリ
上記リポジトリをクローンしてください。クローンすると以下のようなGradleスクリプトができます。
└── hatenadiarymakescript以前作成した Gradle 標準ディレクトリ構造 自動作成をここでも使用しています。ただし、build.gradleの外部参照として定義してあります。手順は以下の様になります。
├── build.gradle
└── gradle_mkdir.gradle
- GradleにGroovyファイルを準備させる。
- 本文を書く もちろん、手動です^^
- Groovyの実行、改行の除去、チェック用HTMLとコピペ用ファイルを生成する。
gradle readyこれで、GradleのGroovy標準ディレクトリ構成が作成され、hatenadiary.groovyファイルが準備されます。すでに決まった構文部は記述された状態になります。
gradle hdmakeGradleが自動で実行、改行の除去、コピーの作成を行ってくれるので、ビルドが成功すると以下のようなファイルができるはずです。
hatenadiary.html hatenadiary.hdhtmlファイルがチェック用HTML、hdファイルがコピペ用のファイルです。どちらも改行コードは抜けています。htmlファイルをブラウザで確認し、良ければ、hdファイルの内容をコピーして、はてなダイアリーにはってください。単純なHTMLですので、はてなブログにも問題なく使用できると思っています。 ※実行確認はLinuxで行っています。
gradle tasks特に、gradle hdmakeをこまめに実行して確認していくと、バグやエラーを発見しながら書いていく事ができます。
課題
今のところこれらは手動で…まとめ
Gradleスクリプトはケーススタディのために別で記事にしようと思います。次は@bikisukeさんですね^^楽しみです!今年もあっという間でしたが、皆さん、よいお年をお過ごしくださいm(_ _)mcronを試してみました
ちょっとcronに触る機会ができたので、メモしておきます。試すのは最も単純な、 ログインユーザーでログインユーザー実行のスクリプトを定期実行するパターンです。
まずはcrondのインストール、起動を確認する
cronの実行可能かどうかを調べます。# /etc/rc.d/init.d/crond statusと表示されれば、使用可能です。動いていない場合は、 chkconfig等で crondが自動で起動する様にしてください。
crond (pid xxx) を実行中...
自動起動したいスクリプトを準備する
今回はテスト用に、現在時刻をtest.txtに吐くだけの簡単なスクリプトを準備しました。ファイル名:getdate.sh
#!/bin/bash上記ファイルを以下のパスに置いておきます。
#現在時刻日付をtest.txtに出力する。
date > test.txt
/home/ユーザー/getdate.sh実行権限の付与を忘れずに。
$ chmod 755 /home/ユーザー/getdate.sh
自動実行の設定をする
自動実行の設定をします。 crontabで設定ファイルを記述します。$ crontab -e以下の様に設定ファイルを記述します。この記述に使われるのは、標準のテキストエディタですので、基本viです。
#メール処理は行わない分や時の指定の書き方は cronの設定ガイド:実行時間指定の書き方に詳しく書かれています。
MAILTO=""
#以下スケジューリング
#分 時 日 月 曜日 コマンド
#毎分 毎時 毎日 毎月 全ての曜日 にgetdate.shを実行する
0-59 * * * * /home/ユーザー/getdate.sh
記述をするとcronファイル読み込みプロセスが 毎分読み込みしてくれるようで、すぐ実行が開始されます。
ちなみにこの自動実行は、設定したユーザーがログインしている間だけでなく、他のユーザーでログインしているときもずっと実行され続けます。
便利ですね!
参考リンク
cronの設定ガイドcrontabの書き方
継続的デリバリー読書会 5 参加してきた #CDStudy
10月14日に継続的デリバリー№5が行われましたので、参加してきました。
募集ページ
Twitterのまとめ
タイムテーブル
13:30 - 14:00 アイスブレイク & Chapter10説明(@kyon_mm)14:00 - 15:15 Chapter10(アプリケーションをデプロイ・リリースする)
15:15 - 15:30 Chapter11説明(@kyon_mm)
15:30 - 16:45 Chapter11(基盤と環境を管理する)
16:45 - 17:00 Chapter12説明(@kyon_mm)
17:00 - 18:15 Chapter12(データを管理する)
18:15 - 18:30 クロージング
今回は、割とプログラミングというよりは、インフラに近い内容だった感じがしました。ですがとても重要な事で、開発チームとして様々な役割の人と連携しなくてはならない事もよくわかりました。
10章 アプリケーションをデプロイ・リリースする
今回は@nobusueさんと@akuraruさんと同じテーブルで議論しました。この章で印象的だったのは、 ブルー・グリーン・デプロイメントと カナリアリリースです。ブルー・グリーン・デプロイメントとは、システムを2系統以上並行稼動させて、デプロイ時に1系統にインストールし、テストを行います。新システムへの移行は、ユーザーをその系統に向かわせる様ロードバランサ等で制御するだけで可能です。。そして、もし何か起こったら、すぐロードバランサで経路を新システムでない系統に戻し、新システムで何が起こったかをじっくり確認するというわけです。絵にするとこんな感じですね。
カナリアリリースは、上記のブルー・グリーン・デプロイメントの仕組みや、アプリケーション内の制御でもいいのですが、一部のユーザーをテスト的に新システムを使用してもらい、ある程度の期間をおいて全ユーザー向けに切り替える仕組みですね。考えてみると、業務系のシステムだけでなく、多くのインストールして使うOSやツール何かも、アルファ版等でこういったやり方をやっていますね。
こういったインフラ系の話は@nobusueさんの得意とする所で、いろいろとためになるお話がありました。ブルー・グリーン・デプロイメントは私の印象では、 「金持ちの仕組み」と思ってしまったのですが、クラウドを使うと安くなるとか(AWSではロードバランサ機能がある)、企業によっては3系統以上持っているとか、実例を聞くことができました。@nobusueさんありがとうございました。
11章 基盤と環境を管理する
この章は主にアプリケーションを実行するOSやネットワーク環境などのお話でした。私たちが開発するアプリケーションは、基盤無しでは動かない物であり、その環境はすでにお客様の元にあるか、新規で準備するのか、それはアプリケーションのスコープによって違うとは思います。継続的デリバリーにおいては、こうした基盤に関する事も、スクリプト化して、バージョン管理にあげる事が書かれています。私たちのテーブルの議論では、環境を構築する「自動化」の話がよく語られました。ここでよく出てくるツールといえば、 chefや puppetなどがよく話されますね。puppetの方が歴史が古く、資料が多く残っているが、記述する設定は多い様です。chefの方が記述量が少ない様ですが、Rubyの環境に依存する様です。こういったツールが出てくると、サーバー管理の増設が楽になりますね。また、仮想化やクラウドの話をした際、管理対象のサーバーを楽に立ち上げるツールはあっても、間のネットワークやロードバランサ等の設定スクリプトが自動化できない、もしくは機種依存が強いという話題にもなりました。
12章 データを管理する
これも大事な話ですね〜。データの移行は多くのシステムで起こることですし、私自身最近DBに触れることが多くあり、気になる内容です。書籍の中では、「データ移行を自動化する」とか「データベースをバージョン管理し、ロールフォワードスクリプトとロールバックスクリプトを作成する」などの手法が書かれています。これは特に、「止めれない仕組み」に対して有功と考えます。また、継続的デリバリーのように頻繁にデリバリーを行うなら、止められる仕組みであってもそういったスクリプトが必要だと思います。個人的には、新システムに対応したデータ書き込みトランザクション発生時に、旧データベースを更新する仕組みが一番いいと思っています。また、書籍の中ではテストデータをバージョン管理すべきともかかれていました。
議論では、変更に強いテーブル設計にするために、「間にVIEWをはさんでおく」とか、「汎用カラムを作っておく」とかの話になりました。やっぱりそういったケースは稀にあるんですねぇ。 汎用テキスト1とか。。。
まとめ
今回も楽しめました。開発のtobeモデルを少しずつ紐解いていく感じで、勉強になります。いよいよ次回が 最終回!その後、別の書籍にやるのか、報告会をやるのか、いずれにせよ楽しみにしています。何か自分の仕事と絡めていろいろ試してみたいな〜。↓↓お楽しみなおやつ達↓↓
継続的デリバリー読書会 4 参加してきた #CDStudy
9月22日に継続的デリバリー№4が行われましたので、参加してきました。
募集ページ
Twitterのまとめ
タイムテーブル
13:30 - 14:00 アイスブレイク & 7章説明(@kyon_mm)14:00 - 15:15 Chapter7(コミットステージ
15:15 - 15:30 8章説明(@kyon_mm)
15:30 - 16:45 Chapter8(自動受け入れテスト)
16:45 - 17:00 9章説明(@kyon_mm)
17:00 - 18:15 Chapter9(非機能要件をテストする)
18:15 - 18:30 クロージング
今回は、全体的に@kyon_mmさんによる開発やテストに関する解説を多くしていただきましたよ。相変わらずすごいですね@kyon_mmさんは^^
7章 コミットステージ
コミットステージでは、開発時のソースコードのコミット時に何を行うべきか?というお話でした。ここで関わってくる重要な要素としては、 ユニットテストがあるでしょう。私たちのテーブルの議論は以下のようになりました。テーブルメンバーは私と@kyon_mmさん、@mau0824さんです。また、@kyon_mmさんにテストの分類について詳しく説明してもらいました。
上のホワイトボードはまだ書きかけの状態の図なんですが、私自身が非常にためになったのは、 開発したコードのメインブランチへのマージは、既存システムを網羅したユニットテスト群を通過した後に行うという事です。作成したコードのユニットテストに関しては作成者の責任において行われるべきであり、それをメインブランチへマージする前には、他のシステムへの影響を踏まえて、あらかじめ作成してあるユニットテスト群をくぐらせるという事ですね。
8章 自動受け入れテスト
受け入れテストは最も顧客に近いところで、最も変更の多い所です。また、 見積りとの兼ね合いも難しい所です。私たちのテーブルの議論は以下の様になりました。私は特に見積りとテストの兼ね合いが気になっていたので、その辺を重点的に話を聞いていました。例えば、「客先から予算の関係でテストを削ること」を求めらた場合、その説明の難しさという事を感じました。 品質とコストと納期、その全てが揃ってこそ価値ある製品が納入できるとは思っていても、人と人(企業と企業)の考え方の違いによって差が生まれてしまい、自分たちの品質方針が守れなくなってしまう事もあるかもしれません。
また、@kyon_mmさんにまたホワイトボードで熱く語っていただきました。
ユーザーストーリーとか ハッピーパスは、アジャイルやXP界隈で出てくる単語ですね。ここでは、右上に書いてあるピラミッド型のテストの重点度の図が、私にとってツボでした。ユニットテストが一番下にあって、上のテストを支えているように見えるこの図は、 開発者目線の図であると、@kyon_mmさんは言っていました。加えて客先が求めているのは、 一番上の受け入れテストを重点に考えるはずだから、形状はまったく逆になると。なるほど。忘れがちですが 真理ですね。こういう点からも受け入れテスト、大事ですね。ここまで自動化する価値があるという事ですね。
9章 非機能要件をテストする
これも難しい問題ですね。私が気になったのは、 非機能要件は標準化されているか?という点です。最近私は仕事上BIとかデータベースに触れることが多く、パフォーマンスチューニングという点でも今後関わっていく可能性があります。私達のテーブルの討論結果は以下の様になりました。ここでも、いいお話が聞けました。ユニットテストをうまく使ってDAOのレスポンスタイムを計測するテストプログラムを組み、極端にレスポンスが悪いプログラムを確認しておくと。なるほど!そうすれば継続的デリバリープロセスにも組み込めますね。昨今、DBMSが充実していてデータベースエンジニアとしてSQLの処理速度を確認する事は容易でも、統合自動化プロセスの一環として使用できるようにするには、これもありかなと思いました。
まとめ
この勉強会「継続的デリバリー読書会」ですが、書籍にかかれていることが参考になるのはもちろんですが、継続的デリバリーがシステム開発プロジェクトのライフサイクルの多くに関わっているので、他の方の例をいろいろ聞くことができる点でもすばらしいと思います。私は最近ドタバタしていて勉強会の参加が2ヶ月ぶりくらいでしたが、やっぱりモチベーションが上がりました。次回も楽しみにしています。仲間内の勉強会でMercurialについて話してきた
書くのがずいぶん遅くなりましたたが、8月25日に仲間内の勉強会で 分散バージョン管理Mercurial+フリーでオープンなリポジトリBitbucketについて発表及び軽いワークショップを行って来ました。私自身、1時間半の長い時間をもらって話すのは初めての事で、それなりに準備していったつもりでしたが、ワークショップ部分でつまづきがありました。
内容
- 導入
- 分散バージョン管理について @matheneさんの資料を使って予定でした。(事前にご本人に確認したら、OKとの事だったので)ただ、バージョン管理自体初めてという方もいらっしゃったので、説明を簡単にするために飛ばしました。
- 図を交えてMercurialの使い方について説明
- 簡単なワークショップ
発表資料
失敗
- ネットワークがつながらずデモが出来なった。 私の確認漏れです。何のためにWimaxルーター持ってるんだかTT
- BitBucketの共同開発者の考えを理解していなかった。 ハイ!すっかり 「プライベートリポジトリにつき共同開発者4人」と勘違いしておりました。正確には、 1アカウントにつき、共同開発者4人なんですね。一部の人が見るだけになってしまったのが残念です。
- Linuxで作ったファイル名が、日本語のファイル名だったため、Windows環境の方が文字化け これも、研究不足でした。調べてみると、日本語ファイル名の文字化けはどうしても起こる様で、詳しくは時節で説明します。
フォロー
Mercurialの日本語ファイル名について
詳しくかかれていた方がいらっしゃったので、リンクをアップしておきます。Mercurialの文字コード設定
今回の勉強会では、LinuxもMacもWindowsもいらっしゃったので、UTF-8設定が必要でしたね。
同一ネットワーク内のリモートリポジトリの作成について
質問がありましたので、試しにやってみました。gitには、こういう時のためのリポジトリ作成のやり方「git init --bare」があるのですけどMercurialには無い様です。ちょっとネットで調べてみると、普通にhg initで作ったリポジトリに対して行える様です。まずはリモートリポジトリにするサーバーで普通にリポジトリを作ります。
hg initcloneやpush、pullなどはLinux等ではSSHで、Windowsでは普通のネットワーク参照で到達できます。LinuxでのSSHでの接続の例は以下の様になります。
hg push ssh://ユーザー@IPもしくはサーバー名//宛先ディレクトリscpとは違い、サーバー名とリポジトリディレクトリの指定の間の記号は セミコロンではなくスラッシュになります。
以下に作成できる構成のモデルを図示します。
まとめ
今回は、貴重な経験をすることができました。勉強会参加者の皆さんに感謝しなくてはなりませんね。また、こういった機会があればぜひ参加していきたいと思います。継続的デリバリー読書会 3 #CDStudy -浴衣とGroovy- 参加してきた
2012年7月7日に行われました、「継続的デリバリー読書会 3 #CDStudy -浴衣とGroovy-」に参加してきました。
募集ページ
twitterのまとめ
前回、 前々回に引き続き参加してきました。もうメンバーは固定になってきましたね。東京の方と、大阪の方がいらっしゃるのが、頭が下がります。「せっかく来ていただいた遠方の方に、来てよかったと思ってもらえるように」とか、ただの参加者なのに思います。その分、交流をして楽しい話をしたいとは思っているのですが…
今回は、第5章と第6章でした。前回と同じように、一部を輪読しながら、議論するという形です。
前談
そうそう、私事ですが、私は 製造業からSI屋さんに転職しました。理由は、 技術的にも成長したいというのと、 システムでお金を稼ぐ会社で、そのやり方を覚えたいという理由からです。今までいろんな経験をできた元の会社にも感謝していますし、拾ってくれた今の会社に感謝しています。今回は転職してから、現在会社で行っていることの議論ができる 初めての場でした。やはり前職に所属している時よりも、皆さんの話の内容がよく理解できました。私の中でこれは大きい変化です。
第5章 デプロイメントパイプラインの解剖学
ここでは、この書籍の最も大きな主題である、 デプロイメントパイプラインについて説明されている章です。デプロイメントパイプラインとは、 「ソフトウェアをバージョン管理から取り出し、ユーザーの手に渡すまでのプロセスを自動化して表現したもの」と書かれています。開発の中心には 継続的インテグレーションの流れがあり、それに加えてリリースの管理用ツールを用いて管理することで、プロセスの進んでいく様子を見ながらコントロールする形です。
この章で特におもしろかったのは、ユニットテスト、自動受け入れテスト、手動テストのお話でした。まず、ユニットテストですが、デプロイメントパイプライン上では、 ユニットテストだけでは足りないと、はっきり書かれています。そして次の自動受け入れテストをデプロイメントパイプラインに含むことによって、 「顧客の受け入れ基準を満たしているか確認する」と書かれています。これらをつなげる事によって、開発者が行った変更が顧客の要求を満たしていることも確認できるという事が常に言える訳です。加えて、 すべて自動化できるわけではなく、手動のテストも必要な所はある。」とも明記されていました。
この章のディスカッション時には、同じテーブルの皆さんと、会社内のバリューストリームマップ*1について話し合いました。皆さんとお話ししていた所、日本のモデルでは見積り時の提案→差し戻しの流れの辺りでひどい動線になるという認識を共有できました。また、@kyon_mmさんに、進んだプロセスの例を教えていただきました。キーは設計時にそれを満たす受け入れテストをセットで考える事かな。
第6章 ビルド・デプロイメントスクリプト
この章は、ビルドやデプロイに使うツールについて具体的にかかれている章でした。ここであげられていたのは以下のツールです。 これらのツールの中で、著者はBuildrを推していましたね。理由としては、RakeのRubyをDSLとして使う扱いやすさの上に、Maven的な要素をプラスしたもので、非常に扱いやすいとの事です。その横に、私の好きなGradleについても、「GroovyでDSLを書きたいならGradleでもいいだろう。」という形で書かれていました。こういったスクリプト言語で書くDSLもひとつの時代の流れなのかもしれません。
その後のディスカッションでは、他テーブルの方の例から、最も優秀だったビルド、デプロイの仕組みを聞くことができました。ツールはMicrosoftのTFSを使っているようです。ソースのコミットからユニットテスト、デプロイを自動で行っている仕組みを聞きました。TFSは有料ですが、そのツールを購入したチーム全体の決断は素晴らしいと思います。また、全員がうまく使っていこうという意識が働くはずですので、そういった事もみんなに浸透させるキーなのかなと思ったりもしています。オープンソースのツールだとオレオレツールになりがちなので。。。*3
最後に、@kyon_mmさんに、Jenkinsのデプロイメントパイプラインプラグインの例を見せていただきました。なかなか分かりやすい見た目で、おもしろそうでした。Jenkinsに対しての評価がまた上がりました。