2012-12-31

CentOS リポジトリ　追加

linux CentOS

覚書のための記述です。CentOS6.2 x86_64で行っています。

追加するリポジトリ

EPEL、RPMforge

参考にしたページ

RPMforgeリポジトリ導入(RPMforge)
CentOS 外部レポジトリの追加(EPEL)

手順

yum-prioritiesのインストール

yum -y install yum-priorities

すでにyumに設定されているCentOSのデフォルトのリポジトリの優先度をもっとも優先に設定しておきます。

CentOS

vi /etc/yum.repos.d/CentOS-Base.repo

CentOS 外部レポジトリの追加(EPEL)

[base]
priority=1
[updates]
priority=1
[addons]
priority=2
[extra]
priority=2
[centosplus]
enabled=1
priority=2
[contrib]
enabled=1
priority=2

EPELの導入

RPM

http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/epel/5/x86_64/

rpm

yum

vim /etc/yum.repos.d/epel.repo

[epel]
enabled=1
priority=3

RPMforgeの導入

http://pkgs.repoforge.org/rpmforge-release/

x86

rpm

yum

vim /etc/yum.repos.d/rpmforge.repo

[rpmforge]
enabled=1
priority=4

おわり

とりあえずこれで使っていこう。

2012-12-18

Groovy ではてなダイアリー書く Gradle で準備する #gadvent2012

Groovy アドベントカレンダー

G*な皆さん、こんにちは！
G* Advent Calendar 2012、12/19担当の@nightmare_timです。前日は、@hideokuさんの、 Geb で JavaScript のテストをしてみた　#gadvent2012でした^^
今年は、６月に転職という大きな波をくぐり抜け、やっと生活が落ち着いてきた感じがあります。ばたばたは相変わらずですけども、こうやってG* Advent Calendar 2012に参加できるのもうれしく思います。では、始めます。

今回のテーマ

今回のテーマは、「Groovyではてなダイアリーを書く」です。ぶっちゃけ言うと、ただ HTMLBuilderを使ってHTMLを生成するだけなんですが(^^;本当はHatenaAPIとかを使って自動でアップデートまでやりたいとこですが、まずはコードで原文書いてそれをGitやMarcurialで管理したいのもあって、ローカルで作成手順を作りました。
きっかけは、以前行われた SCMBC NAGOYAの時に、@irofさんが言われていた「Groovistだったら閉じタグのHTMLなんか面倒でしょ？」という発言をお聞きして、「ほう」と思ったことが始まりです。（もう８カ月も前の話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 2012

a(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{      
    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('}');      
}

pre要素の中に、mkp.yieldで囲った文章を列挙し、brもつける必要があります。また、シングルクォーテーションやダブルクォーテーションはバックスラッシュでエスケープする必要があります。

ヘッダー要素

h5('ヘッダー要素')

注意点

改行をしっかり入れる

はてなダイアリー

br();

閉じ中括弧の後に書かない

コンパイル

    }br();    //エラーになります

記事全体

当記事の全体をgistに上げておきます。
ファイル全体

ビルド

HTMLと違ってGroovyコードは実行してHTMLコードを出力します。構文間違いなどはコンパイルエラーとして吐き出してくれるので、間違いが少なくなるのは間違いないのですが、やっぱり何度もやるのは骨が折れます。そこで Gradleさんの出番ですね！

行いたいこと

決まった構文が入ったGroovyファイルを用意する。
（手動で）HTMLBuilderを使って本文を書く。
Groovyを実行してHTMLファイルを作成する。
作成したHTMLファイルの改行を取り除く
チェック用のhtml要素とbody要素を抜いたコピペ用を作る。

作成したスクリプト

長くなりそうなので、リンクと使い方だけ説明しておきます。
作成したGradleスクリプトのbitbucket:Mercurialリポジトリ
上記リポジトリをクローンしてください。クローンすると以下のようなGradleスクリプトができます。

└── hatenadiarymakescript      
    ├── build.gradle      
    └── gradle_mkdir.gradle

以前作成した Gradle　標準ディレクトリ構造　自動作成をここでも使用しています。ただし、build.gradleの外部参照として定義してあります。手順は以下の様になります。

GradleにGroovyファイルを準備させる。

gradle ready

ディレクト

本文を書く
Groovyの実行、改行の除去、チェック用HTMLとコピペ用ファイルを生成する。

gradle hdmake

hatenadiary.html    hatenadiary.hd

はてなダイアリー

はてなブログ

※実行確認はLinuxで行っています。

タスクはもちろん以下のコマンドでも確認できます。

gradle tasks

特に、gradle hdmakeをこまめに実行して確認していくと、バグやエラーを発見しながら書いていく事ができます。

課題

はてなダイアリーに自動で上げれない。
画像が貼れない。
Amazonなどのアフィリエイトは使用できない。
その他複雑な事はできない

今のところこれらは手動で…

まとめ

Gradleスクリプトはケーススタディのために別で記事にしようと思います。次は@bikisukeさんですね^^楽しみです！今年もあっという間でしたが、皆さん、よいお年をお過ごしくださいm(_ _)m

2012-12-08

cronを試してみました

linux

ちょっとcronに触る機会ができたので、メモしておきます。試すのは最も単純な、ログインユーザーでログインユーザー実行のスクリプトを定期実行するパターンです。

まずはcrondのインストール、起動を確認する

cronの実行可能かどうかを調べます。

# /etc/rc.d/init.d/crond status 
crond (pid xxx) を実行中...

と表示されれば、使用可能です。動いていない場合は、 chkconfig等で crondが自動で起動する様にしてください。

自動起動したいスクリプトを準備する

今回はテスト用に、現在時刻をtest.txtに吐くだけの簡単なスクリプトを準備しました。
ファイル名:getdate.sh

#!/bin/bash 
#現在時刻日付をtest.txtに出力する。 
date > test.txt

上記ファイルを以下のパスに置いておきます。

/home/ユーザー/getdate.sh

実行権限の付与を忘れずに。

$ chmod 755 /home/ユーザー/getdate.sh

自動実行の設定をする

自動実行の設定をします。 crontabで設定ファイルを記述します。

$ crontab -e

以下の様に設定ファイルを記述します。この記述に使われるのは、標準のテキストエディタですので、基本viです。

#メール処理は行わない 
MAILTO="" 
 
#以下スケジューリング 
#分　時　日　月　曜日　コマンド 
#毎分 毎時 毎日　毎月　全ての曜日　にgetdate.shを実行する 
0-59 * * * * /home/ユーザー/getdate.sh

分や時の指定の書き方は cronの設定ガイド：実行時間指定の書き方に詳しく書かれています。
記述をするとcronファイル読み込みプロセスが毎分読み込みしてくれるようで、すぐ実行が開始されます。
ちなみにこの自動実行は、設定したユーザーがログインしている間だけでなく、他のユーザーでログインしているときもずっと実行され続けます。
便利ですね！

参考リンク

cronの設定ガイド
crontabの書き方

2012-10-20

継続的デリバリー読書会５参加してきた #CDStudy　

開発ライフサイクル

１０月１４日に継続的デリバリー№５が行われましたので、参加してきました。
募集ページ
 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 クロージング
今回は、割とプログラミングというよりは、インフラに近い内容だった感じがしました。ですがとても重要な事で、開発チームとして様々な役割の人と連携しなくてはならない事もよくわかりました。

１０章　アプリケーションをデプロイ・リリースする

今回は@nobusueさんと@akuraruさんと同じテーブルで議論しました。この章で印象的だったのは、ブルー・グリーン・デプロイメントとカナリアリリースです。
ブルー・グリーン・デプロイメントとは、システムを２系統以上並行稼動させて、デプロイ時に１系統にインストールし、テストを行います。新システムへの移行は、ユーザーをその系統に向かわせる様ロードバランサ等で制御するだけで可能です。。そして、もし何か起こったら、すぐロードバランサで経路を新システムでない系統に戻し、新システムで何が起こったかをじっくり確認するというわけです。絵にするとこんな感じですね。

f:id:nightmare_tim:20121020182734p:image:w500

カナリアリリースは、上記のブルー・グリーン・デプロイメントの仕組みや、アプリケーション内の制御でもいいのですが、一部のユーザーをテスト的に新システムを使用してもらい、ある程度の期間をおいて全ユーザー向けに切り替える仕組みですね。考えてみると、業務系のシステムだけでなく、多くのインストールして使うOSやツール何かも、アルファ版等でこういったやり方をやっていますね。
こういったインフラ系の話は@nobusueさんの得意とする所で、いろいろとためになるお話がありました。ブルー・グリーン・デプロイメントは私の印象では、「金持ちの仕組み」と思ってしまったのですが、クラウドを使うと安くなるとか（AWSではロードバランサ機能がある）、企業によっては３系統以上持っているとか、実例を聞くことができました。@nobusueさんありがとうございました。

f:id:nightmare_tim:20121014153529j:image:w360

１１章基盤と環境を管理する

この章は主にアプリケーションを実行するOSやネットワーク環境などのお話でした。私たちが開発するアプリケーションは、基盤無しでは動かない物であり、その環境はすでにお客様の元にあるか、新規で準備するのか、それはアプリケーションのスコープによって違うとは思います。継続的デリバリーにおいては、こうした基盤に関する事も、スクリプト化して、バージョン管理にあげる事が書かれています。
私たちのテーブルの議論では、環境を構築する「自動化」の話がよく語られました。ここでよく出てくるツールといえば、 chefや puppetなどがよく話されますね。puppetの方が歴史が古く、資料が多く残っているが、記述する設定は多い様です。chefの方が記述量が少ない様ですが、Rubyの環境に依存する様です。こういったツールが出てくると、サーバー管理の増設が楽になりますね。また、仮想化やクラウドの話をした際、管理対象のサーバーを楽に立ち上げるツールはあっても、間のネットワークやロードバランサ等の設定スクリプトが自動化できない、もしくは機種依存が強いという話題にもなりました。

f:id:nightmare_tim:20121014170327j:image:w360

１２章　データを管理する

これも大事な話ですね〜。データの移行は多くのシステムで起こることですし、私自身最近DBに触れることが多くあり、気になる内容です。
書籍の中では、「データ移行を自動化する」とか「データベースをバージョン管理し、ロールフォワードスクリプトとロールバックスクリプトを作成する」などの手法が書かれています。これは特に、「止めれない仕組み」に対して有功と考えます。また、継続的デリバリーのように頻繁にデリバリーを行うなら、止められる仕組みであってもそういったスクリプトが必要だと思います。個人的には、新システムに対応したデータ書き込みトランザクション発生時に、旧データベースを更新する仕組みが一番いいと思っています。また、書籍の中ではテストデータをバージョン管理すべきともかかれていました。
議論では、変更に強いテーブル設計にするために、「間にVIEWをはさんでおく」とか、「汎用カラムを作っておく」とかの話になりました。やっぱりそういったケースは稀にあるんですねぇ。汎用テキスト１とか。。。

f:id:nightmare_tim:20121014182826j:image:w360

まとめ

今回も楽しめました。開発のtobeモデルを少しずつ紐解いていく感じで、勉強になります。いよいよ次回が最終回！その後、別の書籍にやるのか、報告会をやるのか、いずれにせよ楽しみにしています。何か自分の仕事と絡めていろいろ試してみたいな〜。
↓↓お楽しみなおやつ達↓↓

f:id:nightmare_tim:20121020182708j:image:w360

2012-09-24

継続的デリバリー読書会 4 参加してきた #CDStudy　

開発ライフサイクル

９月２２日に継続的デリバリー№４が行われましたので、参加してきました。
募集ページ
 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さんは^^

７章　コミットステージ

コミットステージでは、開発時のソースコードのコミット時に何を行うべきか？というお話でした。ここで関わってくる重要な要素としては、ユニットテストがあるでしょう。私たちのテーブルの議論は以下のようになりました。テーブルメンバーは私と@kyon_mmさん、@mau0824さんです。

f:id:nightmare_tim:20120922160121j:image:w360

また、@kyon_mmさんにテストの分類について詳しく説明してもらいました。

f:id:nightmare_tim:20120924001405j:image:w360

上のホワイトボードはまだ書きかけの状態の図なんですが、私自身が非常にためになったのは、開発したコードのメインブランチへのマージは、既存システムを網羅したユニットテスト群を通過した後に行うという事です。作成したコードのユニットテストに関しては作成者の責任において行われるべきであり、それをメインブランチへマージする前には、他のシステムへの影響を踏まえて、あらかじめ作成してあるユニットテスト群をくぐらせるという事ですね。

８章　自動受け入れテスト

受け入れテストは最も顧客に近いところで、最も変更の多い所です。また、見積りとの兼ね合いも難しい所です。私たちのテーブルの議論は以下の様になりました。

f:id:nightmare_tim:20120924001702j:image:w360

私は特に見積りとテストの兼ね合いが気になっていたので、その辺を重点的に話を聞いていました。例えば、「客先から予算の関係でテストを削ること」を求めらた場合、その説明の難しさという事を感じました。品質とコストと納期、その全てが揃ってこそ価値ある製品が納入できるとは思っていても、人と人（企業と企業）の考え方の違いによって差が生まれてしまい、自分たちの品質方針が守れなくなってしまう事もあるかもしれません。
また、@kyon_mmさんにまたホワイトボードで熱く語っていただきました。

f:id:nightmare_tim:20120922171027j:image:w360

ユーザーストーリーとかハッピーパスは、アジャイルやXP界隈で出てくる単語ですね。ここでは、右上に書いてあるピラミッド型のテストの重点度の図が、私にとってツボでした。ユニットテストが一番下にあって、上のテストを支えているように見えるこの図は、開発者目線の図であると、@kyon_mmさんは言っていました。加えて客先が求めているのは、一番上の受け入れテストを重点に考えるはずだから、形状はまったく逆になると。なるほど。忘れがちですが真理ですね。こういう点からも受け入れテスト、大事ですね。ここまで自動化する価値があるという事ですね。

９章　非機能要件をテストする

これも難しい問題ですね。私が気になったのは、非機能要件は標準化されているか？という点です。最近私は仕事上BIとかデータベースに触れることが多く、パフォーマンスチューニングという点でも今後関わっていく可能性があります。私達のテーブルの討論結果は以下の様になりました。

f:id:nightmare_tim:20120924001907j:image:w360

ここでも、いいお話が聞けました。ユニットテストをうまく使ってDAOのレスポンスタイムを計測するテストプログラムを組み、極端にレスポンスが悪いプログラムを確認しておくと。なるほど！そうすれば継続的デリバリープロセスにも組み込めますね。昨今、DBMSが充実していてデータベースエンジニアとしてSQLの処理速度を確認する事は容易でも、統合自動化プロセスの一環として使用できるようにするには、これもありかなと思いました。

まとめ

この勉強会「継続的デリバリー読書会」ですが、書籍にかかれていることが参考になるのはもちろんですが、継続的デリバリーがシステム開発プロジェクトのライフサイクルの多くに関わっているので、他の方の例をいろいろ聞くことができる点でもすばらしいと思います。私は最近ドタバタしていて勉強会の参加が２ヶ月ぶりくらいでしたが、やっぱりモチベーションが上がりました。次回も楽しみにしています。

2012-09-17

仲間内の勉強会でMercurialについて話してきた

SCM

書くのがずいぶん遅くなりましたたが、８月２５日に仲間内の勉強会で分散バージョン管理Mercurial＋フリーでオープンなリポジトリBitbucketについて発表及び軽いワークショップを行って来ました。私自身、１時間半の長い時間をもらって話すのは初めての事で、それなりに準備していったつもりでしたが、ワークショップ部分でつまづきがありました。

内容

導入
分散バージョン管理について
図を交えてMercurialの使い方について説明
簡単なワークショップ

基本、以前参加させて頂いた SCMBC NAGOYAの内容を思い出しながら行いました。完成度はとても及びませんけれども。

発表資料

Mercurialコマンドの紹介 from Tsutomu Takeuchi

失敗

ネットワークがつながらずデモが出来なった。

Wimax

ルーター

BitBucketの共同開発者の考えを理解していなかった。

「プライベートリポジトリにつき共同開発者４人」

１アカウントにつき、共同開発者４人

Linuxで作ったファイル名が、日本語のファイル名だったため、Windows環境の方が文字化け

などなど、いろいろと失敗しました。ただ、話を聞いてくださった方達が、「ああいったハプニングはあって当然、むしろ楽しい」と言っていただけたのがありがたかったです。

フォロー

Mercurialの日本語ファイル名について

詳しくかかれていた方がいらっしゃったので、リンクをアップしておきます。
Mercurialの文字コード設定
今回の勉強会では、LinuxもMacもWindowsもいらっしゃったので、UTF-8設定が必要でしたね。

同一ネットワーク内のリモートリポジトリの作成について

質問がありましたので、試しにやってみました。gitには、こういう時のためのリポジトリ作成のやり方「git init --bare」があるのですけどMercurialには無い様です。ちょっとネットで調べてみると、普通にhg initで作ったリポジトリに対して行える様です。
まずはリモートリポジトリにするサーバーで普通にリポジトリを作ります。

hg init

cloneやpush、pullなどはLinux等ではSSHで、Windowsでは普通のネットワーク参照で到達できます。LinuxでのSSHでの接続の例は以下の様になります。

hg push ssh://ユーザー@IPもしくはサーバー名//宛先ディレクトリ

scpとは違い、サーバー名とリポジトリディレクトリの指定の間の記号はセミコロンではなくスラッシュになります。
以下に作成できる構成のモデルを図示します。

f:id:nightmare_tim:20120917174252p:image:w360

まとめ

今回は、貴重な経験をすることができました。勉強会参加者の皆さんに感謝しなくてはなりませんね。また、こういった機会があればぜひ参加していきたいと思います。

2012-07-15

継続的デリバリー読書会 3 #CDStudy -浴衣とGroovy-　参加してきた

開発ライフサイクル勉強会

２０１２年７月７日に行われました、「継続的デリバリー読書会 3 #CDStudy -浴衣とGroovy-」に参加してきました。
募集ページ
 twitterのまとめ

 前回、前々回に引き続き参加してきました。もうメンバーは固定になってきましたね。東京の方と、大阪の方がいらっしゃるのが、頭が下がります。「せっかく来ていただいた遠方の方に、来てよかったと思ってもらえるように」とか、ただの参加者なのに思います。その分、交流をして楽しい話をしたいとは思っているのですが…
今回は、第5章と第6章でした。前回と同じように、一部を輪読しながら、議論するという形です。

前談

そうそう、私事ですが、私は製造業からSI屋さんに転職しました。理由は、技術的にも成長したいというのと、システムでお金を稼ぐ会社で、そのやり方を覚えたいという理由からです。今までいろんな経験をできた元の会社にも感謝していますし、拾ってくれた今の会社に感謝しています。
今回は転職してから、現在会社で行っていることの議論ができる初めての場でした。やはり前職に所属している時よりも、皆さんの話の内容がよく理解できました。私の中でこれは大きい変化です。

第５章　デプロイメントパイプラインの解剖学

ここでは、この書籍の最も大きな主題である、デプロイメントパイプラインについて説明されている章です。
デプロイメントパイプラインとは、「ソフトウェアをバージョン管理から取り出し、ユーザーの手に渡すまでのプロセスを自動化して表現したもの」と書かれています。開発の中心には継続的インテグレーションの流れがあり、それに加えてリリースの管理用ツールを用いて管理することで、プロセスの進んでいく様子を見ながらコントロールする形です。
この章で特におもしろかったのは、ユニットテスト、自動受け入れテスト、手動テストのお話でした。まず、ユニットテストですが、デプロイメントパイプライン上では、ユニットテストだけでは足りないと、はっきり書かれています。そして次の自動受け入れテストをデプロイメントパイプラインに含むことによって、「顧客の受け入れ基準を満たしているか確認する」と書かれています。これらをつなげる事によって、開発者が行った変更が顧客の要求を満たしていることも確認できるという事が常に言える訳です。加えて、すべて自動化できるわけではなく、手動のテストも必要な所はある。」とも明記されていました。
この章のディスカッション時には、同じテーブルの皆さんと、会社内のバリューストリームマップ*1について話し合いました。皆さんとお話ししていた所、日本のモデルでは見積り時の提案→差し戻しの流れの辺りでひどい動線になるという認識を共有できました。また、@kyon_mmさんに、進んだプロセスの例を教えていただきました。キーは設計時にそれを満たす受け入れテストをセットで考える事かな。

第６章　ビルド・デプロイメントスクリプト

この章は、ビルドやデプロイに使うツールについて具体的にかかれている章でした。
ここであげられていたのは以下のツールです。

Make
Ant
NAntとMSBuild
Maven
Rake
Buildr*2
Psake

これらのツールの中で、著者はBuildrを推していましたね。理由としては、RakeのRubyをDSLとして使う扱いやすさの上に、Maven的な要素をプラスしたもので、非常に扱いやすいとの事です。その横に、私の好きなGradleについても、「GroovyでDSLを書きたいならGradleでもいいだろう。」という形で書かれていました。こういったスクリプト言語で書くDSLもひとつの時代の流れなのかもしれません。
その後のディスカッションでは、他テーブルの方の例から、最も優秀だったビルド、デプロイの仕組みを聞くことができました。ツールはMicrosoftのTFSを使っているようです。ソースのコミットからユニットテスト、デプロイを自動で行っている仕組みを聞きました。TFSは有料ですが、そのツールを購入したチーム全体の決断は素晴らしいと思います。また、全員がうまく使っていこうという意識が働くはずですので、そういった事もみんなに浸透させるキーなのかなと思ったりもしています。オープンソースのツールだとオレオレツールになりがちなので。。。*3
最後に、@kyon_mmさんに、Jenkinsのデプロイメントパイプラインプラグインの例を見せていただきました。なかなか分かりやすい見た目で、おもしろそうでした。Jenkinsに対しての評価がまた上がりました。

まとめ

この読書会は、毎回毎回、とても勉強になります。まず、主催の@kyon_mmさん初め、参加している方達の質と人柄がいいと言えると思います。いつも楽しく議論させていただきありがとうございます。これからの人生において、こういった経験は非常に役に立っていくと思います。

*1:プログラム開発におけるプロセスを、動作と期間で図示した図

*2:ビルドアール

*3:もちろん、そういったツールを試していろいろ学んでいくのは素晴らしい事です。

追加するリポジトリ

参考にしたページ

手順

おわり

今回のテーマ

GroovyでHTMLを書くHTMLBuilder

ヘッダー情報等の決まった構文部

本文

色付き文字

リンク

箇条書き

表組み

pre要素

ヘッダー要素

注意点

記事全体

ビルド

行いたいこと

作成したスクリプト

課題

まとめ

まずはcrondのインストール、起動を確認する

自動起動したいスクリプトを準備する

自動実行の設定をする

参考リンク

タイムテーブル

１０章 アプリケーションをデプロイ・リリースする

１１章 基盤と環境を管理する

１２章 データを管理する

まとめ

タイムテーブル

７章 コミットステージ

８章 自動受け入れテスト

９章 非機能要件をテストする

まとめ

内容

発表資料

失敗

フォロー

Mercurialの日本語ファイル名について

同一ネットワーク内のリモートリポジトリの作成について

まとめ

前談

第５章 デプロイメントパイプラインの解剖学

第６章 ビルド・デプロイメントスクリプト

まとめ

１０章　アプリケーションをデプロイ・リリースする

１１章基盤と環境を管理する

１２章　データを管理する

７章　コミットステージ

８章　自動受け入れテスト

９章　非機能要件をテストする

第５章　デプロイメントパイプラインの解剖学

第６章　ビルド・デプロイメントスクリプト