Jenkins

2016/01/03

技術的負い目の記事がすごい

技術的負い目の記事がすごいのでリンクしておく。

【元ネタ】
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ

たくさんの負のレガシーがあり、しかも本番稼動中であり、バックアップ容量も多い。
そう簡単にリファクタリングしにくい。
そんな中で色んな対応をされている。
以下、自分が今後参考にしたいためにメモ。

【1】JDKが古い。

古いJDKはセキュリティホールもあるだろうから危険。
性能要件も低いだろう。

→JDK6からJDK8へバージョンアップ。
 Gradleでビルド環境を作る。
 ライブラリの依存関係はMavenリポジトリから探し、Gradleで依存関係管理させる、と。

【2】コード重複率も多く、デッドプログラムも多い。

長年運用したシステムは、デッドプログラムが多い。
でも、リスクがあるから、デッドプログラムをうかつに消去できない。

→リファクタリング、Jenkinsで単体テスト自動化、Sonarでソース解析、Githubフローで開発プロセス改善で30万行を削除。
 その結果、その後の機能改善もやりやすくなった、と。

【3】エラーログ件数が3000件以上もあり、エラーが常態化している。

この状況もよくある。
エラーログが全く使いものにならないから、本来の障害を検知しにくいし、代わりのエラー検知の手作業が増えてしまい、システム運用のコストが大きくなる。

→エラーログ件数のグラフ化して見える化。
 エラー件数が多いエラーをパレート分析して、1つずつ対処していく。
 ログレベルをFatal~Debugまで整理。
 エラーログから検知した内容は、ChatWorkに通知する。
 その結果、一日平均50件ほどまで減らすした、と。

【4】デプロイによってシステムが一時的に壊れる

古いシステムほど、リリース作業のプロセスもデプロイツールも古いままなので、手間がかかりやすい。
その分、リスクも大きい。

→Tomcatを停止する前に、ロードバランサーにワーカーを切り離させる。
 trunkのみでの運用をやめ、プルリクエストベースの開発プロセスとした。
 Tomcatの起動後にアプリケーションがリクエストを処理できるようになるまで待機する処理を入れた。
 リリース内容はChatWorkに通知する、と。

他にも、認識されていない単一障害点、ワイルドなバッチ処理など、たくさんあって、技術とプロセスの両方で改善されたテクニックやプラクティスがすごく参考になる。

| | コメント (0)

2014/10/17

RedmineとGitLabを連携すると、RedmineをGitHub化できるか

RedmineとGitLabを連携することで、RedmineをGitHub化できるのではないか、というアイデアをメモ。

【元ネタ】
Redmine/GitLabと連携したい - Void of Knowledge

akipiiさんはTwitterを使っています: "多分Jira→Redmine、GitLab→Stash、Jenkins→Bambooに対応付けられるはず。Redmine+Git+GitLab+Jenkinsを総合的に利用した少人数チームでのプロジェクト管理のベストプラクティス http://t.co/oKsAiKfioV"

RedmineをGitHub化するアイデア: プログラマの思索

長沢さんの「モダンなチーム開発環境のフリー利用可能な資料」が素晴らしい~プルリクエストはJiraにあってRedmineにない機能: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

Atlassian製品による「No Ticket, No fork!」: プログラマの思索

【1】GitLabはGitHubを真似たオープンソースのGitリポジトリ管理ツール。
ブランチ管理やプルリクエストがすごく簡単にできる。

このGitLabとRedmineを連携できれば、RedmineをGitHub化できるのではないか。
つまり、Redmineで不足しているGit連携機能をGitLabで代替できるのではないか。
トピックブランチ、プルリクエスト、git-flowモデルをGitLabで実現し、Issue管理はRedmine、というように、使い分けて運用するのだ。

ちょうど、アトラシアンのツールが、チケット管理はJira、Git管理ツールはStashで使い分けているのと同じ。
アトラシアンのツールの例を考えると、RedmineにGit管理機能を追加して機能追加するのではなく、チケット管理とGit管理は別々のツールで実現して、相互連携した方が良いのかもしれない。

【2】但し、GitLabを使う場合に注意すべき点はいくつかある。

一つは、RedmineユーザとGitLabユーザが同一になるように設定すること。
つまり、チケット登録できるユーザとGitへコミットできるユーザは一致させた方が、運用しやすい。
できれば、Jenkinsユーザも同一にできれば、運用がより楽になる。

Redmine・Gitlab・Jenkins のログインパスワードの管理が大変になったので OAuth 化した - すえひろがりっっっっ!

2つ目は、GitLabで設定したGitリポジトリをRedmineでも閲覧できるように設定すること。
RedmineのGitリポジトリは、bareリポジトリしかサポートしていないので注意。

GitLabとRedmineを連携させる - Qiita

GitLabとRedmine連携 CentOS 6.5編

3つ目は、GitLabのIssueをRedmineのチケットで置き換えるような設定にしておくこと。
そうすれば、チケット管理はRedmineに統一できるから、Redmineの優れたワークフロー管理やチケット集計機能が使えるようになる。

Redmine/GitLabと連携したい - Void of Knowledge

GitLabとRedmineを連携してみるの巻 - アルパカDiary

色々考えてみる。


| | コメント (0)

2014/04/08

「チーム開発実践入門」が発売されている

チーム開発実践入門」が発売されているので、目次をリンクしておく。

チーム開発実践入門──共同作業を円滑に行うツール・メソッド:書籍案内|技術評論社

目次
第1章:チーム開発とは
第2章:チーム開発で起きる問題
第3章:バージョン管理
第4章:チケット管理
第5章:CI(継続的インテグレーション)
第6章:デプロイの自動化(継続的デリバリー)
第7章:リグレッションテスト

目次をみると、Gitのワークフローとして、git-flow, GitHub-flowが紹介されている。
チケット駆動開発も紹介されているが、特に、継続的デリバリーの章が興味深い。

ちょっと分からなかったことは、ブートストラッピング(Bootstrapping)、コンフィグレーション(Configuration)、オーケストレーション(Orchestration)という言葉は、継続的デリバリーのパターンなのかな?

ここ数年、開発環境の周囲は大きな技術革新が生まれている。
チケット駆動開発もその一つの流れに入っているが、「チーム開発実践入門」は、最近のクラウド技術や継続的デリバリーの部分も最新の内容が詰め込まれているみたい。
読んでみたい。

| | コメント (0)

2014/04/03

最近、ツールとプロセスを組合わせたソフトウェア開発手法の本が増えている

最近、ツールとプロセスを組合わせたソフトウェア開発手法の本が増えているように思う。
読みたい本は「チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (WEB+DB PRESS plus)」と「GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)」かな。
まだ読んでないけど、リンクしておく。

【元ネタ】
『チーム開発実践入門』という本を書きました - ikeike443のブログ

GitHub実践入門──Pull Requestによる開発の変革:書籍案内|技術評論社

【読書感想文】GitHub実践入門 ~Pull Requestによる開発の変革を読み終えました。 | メモ帳代わりのブログ

【書評】 GitHub実践入門 ~Pull Requestによる開発の変革 | IDEA*IDEA

GitHub実践入門を読んでGitとかGitHubについて考えた - 未来のいつか/hyoshiokの日記

【元ネタ2】
GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)の目次:

第1章:GitHubの世界へようこそ
第2章:Gitの導入
第3章:GitHubを利用するための準備
第4章:Gitを操作しながら学ぶ
第5章:GitHubの機能を徹底解説
第6章:はじめてのPull Request
第7章:Pull Requestが送られてきたら
第8章:GitHubと連携するツールとサービス
第9章:GitHubを利用した開発フロー
第10章:会社でGitHubを使おう

【感想】
Redmineによるタスクマネジメント実践技法」「チケット駆動開発」の2冊を出版した後、もはや「チケット駆動開発」というアイデアはソフトウェア開発では当たり前だと思う。
では、今後は、ソフトウェア開発プロセスはどんな方向へ進化すべきなのか?

僕が思うに、バージョン管理やリリース作業を単に自動化するだけでなく、その背後にあるワークフローをツールの一機能にしてしまうことで、変更管理プロセスをツールに取り込んでしまう傾向があるように思う。

【1】GitHubが優れている点は、PullRequestが、従来のパッチのやり取りをWeb上でお手軽にできるようにしただけでなく、そのワークフローをコミッタやパッチ作成者が意識しなくても、変更管理できるようになり、後からそのやり取りを追跡できる仕掛けが整ったこと。

【1-1】従来のパッチのやり取りは、コミッタとパッチ作成者が、メールにパッチを添付して、メールに引用文をつけて返信しながらやり取りしていた。
だから、やり取りが長くなるほど、メール本文も長くなるし、どのパッチが最新なのかも分かりづらい。
また、コミッタが管理しているソースのtrunkもどんどんバージョンアップしていくから、パッチ作成者もその流れに追随していかなければならない。
だから、パッチを作成するタイミングと取り込むタイミングがずれてしまうと、せっかく作ったパッチが無意味になってしまう可能性がある。

【1-2】GitHubでは、PullRequestのワークフローは意外に厳格だと思う。
少なくとも、コミッタが気に入らなければ、PullRequestされたパッチをコメント付きで却下できる。
また、パッチ作成者は、trunkから最新版のソースを取り込んで同期しながら、パッチを育てることもやりやすい。
Gitの優れたブランチ管理やマージ機能だけでなく、そのパッチの取り込み方法も、一つの変更管理にしてしまっているのが上手いと思う。

【2】また、リリース作業についても、最近のクラウド技術を使って、かなり高度な手法によって従来の問題を解決しようとしている。
キーワードは「ブルーグリーン・デプロイメント」と「Immutable Infrastructure」。

DevOps時代の開発者のための構成管理入門(終):継続的デリバリ/デプロイを実現する手法・ツールまとめ (1/2) - @IT

DevOps時代の開発者のための構成管理入門(終):継続的デリバリ/デプロイを実現する手法・ツールまとめ (2/2) - @IT

Immutable Infrastructure~デプロイメントをめぐるシステムインフラの管理~ | NTTデータ

[Agile]継続的デリバリ vs 継続的デプロイ | Ryuzee.com

Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏(前編) - Publickey

Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏(後編) - Publickey

「Blue-Green Deployment」とは何か、マーチン・ファウラー氏の解説 - Publickey

「Immutable Infrastructure(イミュータブルインフラストラクチャ)と捨ててしまえるコンポーネント」 チャド・ファウラー氏 - Publickey

【2-1】従来の本番リリース作業は、とにかく大変だ。
本番リリースの作業中は、システムを停止するために、ユーザの業務は止まってしまう。

モジュールのデプロイも手作業でやっていると、間違ったバージョンや壊れたモジュールをリリースしてしまう危険もある。
アプリケーションサーバーの再起動が必要なので、システムは一時止まってしまう。
アプリケーションサーバーが2個以上あるならば、ロードバランサーから切り離したりする手順も増える。
手作業のリリース作業ほど危険なものはない。

一番大変なのは、データのバックアップや、本番データへの移行作業だ。
一度データを流し込んでしまった後に失敗すると、そのリカバリー作業はとても大変だ。
長く使っている業務システムほど、大量のトランザクションデータをため込んでいるので、初期化して入れ直す羽目になると、1日以上かかってしまう時もある。

普通の業務システムは、会計システムや発注システムと連動しているから、自動仕訳処理や請求・入金処理、発注処理が開始するまでにシステムを稼働させなければ、ユーザの業務そのものに大きな悪影響を与えてしまう。

【2-2】そんな従来の大変なリリース作業も、本番環境をクラウド化してしまえば、複数の本番環境を準備することで、リリース作業を楽にするだけでなく、移行作業も楽にしてくれる。

(引用開始)
ブルーグリーン・デプロイメントでは商用システムを2組用意して、ブルーとグリーンとを、切り替えることで新しいアプリケーションをデプロイメントしていきます。通常、切り替えは上位のルーターやロードバランサ―、DNSなどで実施するので、デプロイメントに失敗した場合、すぐにロールバックができます。
ただし、商用システムを2組用意するため、コストがかかります。最近ではクラウドコンピューティングをうまく使い、必要なときにだけ、もう1組の商用システムを構築できるため、コストを抑えることができるようになりました。
(引用終了)

(引用開始)
Immutable Infrastructure(Immutable Serverとも呼ばれます)はインフラ管理の新たな手法です。Immutableとは「不変な」という意味です。Immutable Infrastructureでは、その名の通り、一度作成したサーバー(インフラ)は設定変更などを行わず、不変なものとして扱います。デプロイメントのたびに、新しいインフラを構築し、既存のインフラは不要になった後に廃棄します。そのため、クラウドの利用が前提となります。
これにより従来型のデプロイメントで問題となりやすかった環境差分や変更の蓄積による設計書などに記載されない修正がなくなり、毎回クリーンなインフラを扱うことができるメリットがあります。それにより、デプロイメントが失敗する可能性を下げることができます。
このようなインフラ管理ができるようになってきたのもIaaSを中心としたクラウド技術やInfrastructure as Codeなどの技術の成熟に伴い、コンピューターリソースを瞬時に非常に低いコストで扱うことができるようになったためです。
(引用終了)

【2-3】ブルーグリーン・デプロイメントは、全く同じ本番環境が2個あることが大前提。
その前提のもとに、片方にリリースして、スモークテストなど十分にテストした後、ロードバランサーやDNSなどを最新バージョンの本番環境へ切り替えること。

以前なら、全く同じ本番環境を2個もそろえるのは、サーバー機器の購入もあるから、コストがかかり過ぎてありえなかった。
でも、今では、仮想サーバー上に本番サーバーや本番運用中のシステムが載っているは普通だろう。
つまり、ハードはほとんど無料に近く、ソフトウェアライセンスのみ費用がかかっていることになるから、格段に安くなるはず。
そこから発展して、複数の仮想サーバーを用意しておけば、リリース作業はより安全に運用できる。

ブルーグリーン・デプロイメントの手法は、特にDR対策(Disaster Recovery:災害復旧対策)で大きな威力を発揮するだろうと思う。
最近は、内部統制やBCP(事業継続計画)の観点から、インフラチームはDR対策を講じた本番構成を考えるのが当たり前だ。
DR対策では、全く同じ機器構成で本番環境を作らなければならないので、ブルーグリーン・デプロイメントの手法も適用できるだろう。

ディザスタリカバリとは 【 DR 】 【 Disaster Recovery 】 - 意味/解説/説明/定義 : IT用語辞典

【2-4】Immutable Infrastructureは、リリースのたびに、旧バージョンの本番環境は捨てるというサーバーの使い捨ての手法だ。
この手法が実現可能なのも、仮想サーバに本番環境が載っていて、システムの複製やシステムの再現が以前よりも楽になっていることだろう。

従来はパッチを当てまくったリリース作業が多くるなるたびに、本番環境が汚れていき、日付入りのファイルやフォルダが増えてどれを消したらよいか分からなくなったり、無駄なディスク消費が発生することもあった。
一方、Immutable Infrastructureのリリース手法を使えるならば、毎回クリーンな本番環境を使えるし、最新データの移行作業に専念できる利点もある。

ただし、Immutable Infrastructureの手法を採用するには、Infrastructure as Codeのように、サーバー環境構築の設定プログラムから自動生成できることが最低条件にある。
そうでなければ、本番環境を使い捨てにしていく手法は採用できないからだ。

クラウドを前提とした設計手法が最近は必須になってきていると感じる理由は、このリリース作業の自動化が大きな鍵を握っているからだろうと思う。

【3】クラウド技術と密接に連携した本番リリース作業の自動化は、今一番、技術革新が激しいところだと思う。
僕はクラウド技術に詳しくないので、この辺りは色々探っていきたいと思う。

| | コメント (0)

2013/12/17

JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例

JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例を@tkusukawaさんが公開されていたのでメモ。

【元ネタ】
JenkinsによるLinuxサーバの設定変更管理(yggdrasil)の徹底 - Qiita [キータ]

Home ・ tkusukawa/yggdrasil Wiki ・ GitHub

日々是精進。: yggdrasilを使ってみました。

ALMiniumによる yggdrasilサーバの構築: くすろぐ

Cacoo - yggdrasilの構成図

【1】JenkinsによるLinuxサーバの設定変更管理(yggdrasil)の徹底 - Qiita [キータ]の記事がとてもよくまとまっているので、分かりやすい。

yggdrasilとは、Linuxサーバの設定ファイルをSVNでバージョン管理するためのコマンド(SVNのラッパー)。
Apacheの設定ファイルhttpd.confをSVN管理したい時、.svnなどの余分なファイルができてしまうので、yggdrasil サーバーに設定ファイルを同期した後に、SVNリポジトリへコミットする。

ygg check コマンドを使えば、対象サーバーとSVNリポジトリの設定ファイルのDiffを確認できる。
そのコマンドをJenkinsで定期的に動かし、差分が発生したら、メールで通知する仕組みを説明している。

本番サーバーの環境構築で嫌な問題は、設定ファイルが開発サーバーと違うために、ファイル名に日付を入れてバックアップしがちでゴミファイルが増えてしまうこと。
更には、どの設定ファイルが正しく動いていたのか分からなくなるために、サーバーのリプレース作業でゴミファイルを削除した後に必ず本番障害が発生しやすい問題もある。

yggdrasilの開発や導入は、その問題意識を持っている状況から生まれたようだ。

(引用開始)
【問題は概ね変更の中にある】

サーバの設定変更の問題が月日が経ってから発覚した、という経験はないでしょうか?
例えば、HDDの残量低下のアラートを受けてトレンドを確認したところ一ヶ月以上前に突然増加し始めていた、というような問題です。

ソフトウェア開発でバージョン管理システムを使っていると、試行錯誤した場合でも、どの部分をどう変えたのかを全て差分確認し、修正してみたけど結局は修正する必要が無かった箇所や、デバック用に入れたコードの戻し忘れをコミット前にきっちりチェックすることが出来ますよね。

サーバ設定の試行錯誤でも同様の手法が使えたら素晴らしいと思いませんか?
これを実現するのが yggdrasil になります。
全ての設定ファイルがSVNの リポジトリに反映されていれば 、設定ファイルの変更箇所を漏らさず確認することが出来ます。
意図しない設定変更は事故の元です。
明示的にコミット操作を要求することで変更に対する責任を明確にし、意図していない設定変更が混入することを回避できることになります。
(引用修了)

JenkinsによるLinuxサーバの設定変更管理(yggdrasil)の徹底 - Qiita [キータ]では、異常を見張って正常性を維持してくれる有能な執事:Jenkinsを使うことで、本番サーバーとSVNリポジトリの設定ファイルを同期するようにチェックする運用を強いる。

【2】「問題は概ね変更の中にある」という言葉はとても意味深い。
IT技術の本質は、常に変更が発生する点にある。
変更が必ず発生するという前提条件の元で、変更したがために、あるべき姿から少しずつ離れて、ある限界を超えると障害となって初めて現れる。

バージョンアップしないシステムやソフトウェアは、死んだ状態に等しい。
昨今は、ハードウェアやサーバーの性能向上、WindowsOSのバージョンアップが激しいため、3年おきにシステムリプレースないしハードウェアリプレースという無駄な作業が発生しがち。

その時に、過去に動いたシステムは変えずにハードウェアだけそのまま移行する(リホスト)はとても簡単な作業に思えるが、実際は、設定ファイルのゴミ掃除があったり、JavaやOracle、MySQLなどのミドルウェアのVerUpのために、プログラムのリコンパイルが発生したりする。
すると、システムの回帰テストの作業工数が発生し、うまく動かない機能が必ず出てくる。

例えば、昨今は、Windows7以降はIE11がデフォルトになってしまったために、クライアントアプリが正常表示しなかったり、正常動作しないケースがある。
こういう保守作業は、SIやベンダーにとってもあまりお金にならないし、ユーザも安定稼働するために無駄なお金を使うので、正直嫌なものだ。

いわゆるレガシーマイグレーションの落とし穴については以前書いた。

レガシーマイグレーションという名のシステム移行はデスマーチになりやすい: プログラマの思索

システム移行の概念として、リビルド・リライト・リホスト・ラッピングの違いは抑えておくべき。

【3】サーバーの設定ファイルもバージョン管理しようという発想は、昨今のDevOpsで叫ばれている「Infrastructure as Code」にもつながる話だろう。

下記のBlogの内容が素晴らしい。

Infrastructure as Code - naoyaのはてなダイアリー

従来は、環境構築の手順書をExcelやVisioなどで作り、有識者でレビューした後に、環境を作り、構築テストを行なっていた。
だから、実際に作った後に初めて分かる障害も多かった。

でも、Chefのようなツールを使って、環境構築の手順そのものをプログラム化してしまえば、いつでも誰でも環境を再現できるようになる。
そして、環境構築プログラムそのものをコードレビューできるし、GitHubに入れて、Pull Requestを受け付けるようにすれば、複数人でテストしたソースをマージすることもできるようになる。
さらには、テスト自動化と継続的インテグレーションも入れれば、環境構築そのものもプログラミングと同じく、アジャイルに開発できる。

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

Chefのメモ: プログラマの思索

Chefで構築するRedmine環境: プログラマの思索

今後、DevOpsやクラウドは環境構築で必須の概念になるにつれて、クラウドデザインパターンというインフラ方式設計のベストプラクティス集も必要な知識になるだろうと思う。

クラウドデザインパターン~インフラ方式設計のベストプラクティス集: プログラマの思索

今後も考えてみる。

| | コメント (0)

2013/12/11

Jenkinsビルド後の処理でRedmineにチケット登録ができるJenkinsプラグインredmine-posttask-plugin

Jenkinsビルド後の処理でRedmineにチケット登録ができるJenkinsプラグインredmine-posttask-pluginの記事が公開されていたのでメモ。

【元ネタ】
Jenkinsビルド後の処理でRedmineにチケット登録ができるプラグインを作った話 - Qiita [キータ]

KokawaTakashi/redmine-posttask-plugin ・ GitHub

taskadapter/redmine-java-api ・ GitHub

(引用開始)
Jenkinsの「ビルド後の処理」に、「ビルド失敗時にRedmineにチケット登録をする」処理を追加できます。
(毎ビルド常にチケット登録する事も可能です)

ビルド結果の通知をメールではなくRedmineに登録してほしい場合や、ビルド失敗時の対応がSCM外にも発生する場合など、ジョブの実行結果に対する対応をRedmineに蓄積しておきたい場合に使う事を想定しています。
(引用終了)

上記の記事に書かれている通り、Jenkins上でビルド処理のジョブが失敗した時、Redmineへチケット登録する。
アーキテクチャとしては、Redmine REST APIを使っているみたい。

効果としては、Jenkinsのジョブが失敗した時、メール通知だけでなく、Redmineにもチケットが起票されるので、その後の障害対応がやりやすくなることがあるだろう。
ジョブ失敗のタイミングでチケットが起票されるので、障害の対応履歴がチケットに残り、その後のリリース作業や保守作業で参考になるだろう。

チケットにビルド失敗の履歴が蓄積されれば、その後の是正対策も取りやすくなるはず。
つまり、チケットはPMBOKで言う「組織のプロセス資産」(教訓)でもある。

| | コメント (0)

2013/09/01

日経Systems2013年9月号にRedmineの記事が掲載されました

日経Systems2013年9月号にRedmineの記事が掲載されました。

【元ネタ】
日経BP書店|雑誌バックナンバー - 日経SYSTEMS2013年9月号

日経SYSTEMS - 9月号の「検証」で、プロマネツールのRedmineの導入の勘所を書きました。一読いただければ分かるように、「いかにしてメンバーに使ってもらうか」が今回のメインテーマです。その意味では、10年近く前に別の雑誌で書いたグループウエア導入についての記事に共通点を感じました。システムの利用を促すには工夫が必要です。 (矢口)

Twitter / akipii: ツールを入れるとプロセスも組織も変わる。 RT @NikkeiSystems: 9月号の「検証」で、プロマネツールのRedmineの導入の勘所を書きました。その意味では、10年近く前に別の雑誌で書いたグループウエア... http://fb.me/2j53Jdiui

日経Systemsにredmineの記事を書きました: プログラマの思索

日経SYSTEMS 2012.10 - 情報技術建築家日記

記者の眼 - 「新3種の神器」で開発現場を改革しよう:ITpro

第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索

日経Systemsは2011年7月号にもRedmineの記事を@sakaba37さんと執筆させて頂きました。
それから2012年、2013年と継続的にRedmineの記事を掲載されています。

品川Redmine勉強会で日経Systemsの記者の方が参加されていて、お話を伺った所、読者アンケートを取った結果では、Redmineの読者評価がいつも高いそうです。
第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索にも書きましたが、おそらく日本のSIの現場でRedmineを使っている事例が多いのでしょう。

その理由を推測すると、いくつかあげられると思う。
ITSの高機能化やSVN・Gitなどの構成管理ツールの普及、そしてJenkinsのようなビルド管理ツールの普及という
ソフトウェア開発を支援する基盤が揃ってきたこと。
そして、ソフトウェア開発の案件の短納期・低コストへの流れ。
それらの問題に対して、ITSを使ったチケット駆動開発に興味を持ち、実際に現場に導入されているのだろう。

だが、ITSと言えば、Redmineだけでなく、Tracもあるし、有償ならばJiraやMSのTeamFoundationServer、IBMのRationalTeamConcertもある。
色んなツールの中でRedmineの普及が目立つ理由は、おそらく、日本のSIの開発現場では開発支援ツールそのものに投資する環境でないため、無償のツールの選択肢としてRedmineが選ばれているのではないか、と思う。

もし、お金に物を言わせる環境があれば、サポートもあり、テスト管理やメトリクス集計など豊富な機能を持つJiraやTFSがお勧めだろう。
コミュニティで聞くと、開発ツールに投資してくれる会社では、JiraやTFSなどを導入しているという話をよく聞く。

普通の開発現場では、新しいツールを導入するための投資費用を出してくれる所は少ない。
LAMPの経験があれば、インストール作業はそれほど難しくない。

そして、Redmineならば、ネット上にたくさんのノウハウが転がっている。
チケット駆動開発はTracから生まれたが、Redmineで育まれ、そして他のITSでも同様に運用できる手法。

チケット駆動開発の面白さは、アジャイル開発への適用が一番と思うが、それ以外にも、GitやJenkins、TestLinkなどの他ツールと連携して開発の効率化を試すこともできる。
他にも、ITSの豊富な機能を生かして運用保守・ヘルプデスク管理・資産管理・工数管理などの社内業務にも適用することが出来る部分だと思う。

チケット駆動開発のエッセンスは「チケットをXPのタスクカードのように扱う」という一点だけなのに、そこからたくさんの運用方法が生み出されている所が面白い。

特に、Redmineはオープンソースのプロジェクト管理ツールなのに、RESTやメールによるチケット自動登録などの機能もあるおかげで、いろんな運用の可能性を秘めている。
この辺りのノウハウも考えていきたい。

【追記】

9/12(木)午後に、@sakaba37さんとチケット駆動開発に関する講演を行います。
今日ものある方はぜひご参加下さい。

【告知】「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」を講演します: プログラマの思索

| | コメント (0)

2013/08/17

Jenkinsの使い道

7月にJenkins勉強会があり、@kazuhito_mさんの資料が公開されていたのでリンクしておく。

Jenkinsの使い方は参考になる。
感想はまた後で。

【注】
僧侶「仁斤」さんとは、Jenkinsのことだそうです(笑)

| | コメント (0)

2013/08/10

Antを見直すpart2

Antに関する記事をメモ。

【参考】
Antリファクタリングカタログ: プログラマの思索

Antを見直す: プログラマの思索

【1】AntとGroovyを組み合わせる

下記の記事では、MySQLへ画像ファイルをBlobデータとしてInsertするとき、Antをバッチスクリプトとして作り、Insert処理はGroovyで実装する。

Groovy + AntでBlobデータ投入ツールをさっと作る | SDアドバイザーズ開発室から

この手法が面白い点は、Antと言うタスク指向のビルドスクリプト内部で、条件分岐やループ処理をGroovyで自由自在に実装できること。
つまり、Antビルドスクリプトをバッチ処理のように使える。

他にも下記の事例があるみたい。

Antスクリプト内でGroovyを利用する - No Programming, No Life

ant中からgroovyを呼び出す~あれこれ~ - プログラマ的京都生活

最終的にはDSLのような考え方に通じるだろうと思っている。

groovyの可能性: プログラマの思索

DSLの使い道は継続的デリバリ~AntやMavenからGradleへ: プログラマの思索

【2】AntではCVSタスクは普通に使えるのに、SVNはデフォルトでは使えない。
 AntでSVNコマンドを使うには、svnantタスクを使えばいい。

svnantのtask一覧

SVNのチェックアウト、エクスポート、コミットなどもAntのタスクで使える。

| | コメント (0)

2013/07/28

実践反復型ソフトウェア開発を読む part3~再現可能なビルド管理

実践 反復型ソフトウェア開発」は何度読み直しても参考になる。
今まで暗黙的に行なってきた作業に、きちんとした名前が付与されることで、その作業の意味を捉え直すことができるからだ。
多分、ソフトウェア工学の中でも開発プロセスに興味がある人にとっては必須の本だろうと思う。

実践 反復型ソフトウェア開発」の内容は、構成管理・ビルド管理・障害管理・テスト管理の4つの分野に大きく分けることができる。
第4章「構成管理とブランチの戦略」の部分は以前まとめたので、今回は、ビルド管理についてメモ書き。

【参考】
実践反復型ソフトウェア開発を読む part1~ブランチの戦略: プログラマの思索

実践反復型ソフトウェア開発を読む part2~マージの戦略: プログラマの思索

【1】ビルドの再現可能性

ビルドの重要な性質は、再現性または再現可能性、反復可能性。
つまり、いつ誰がビルドしても、同じようなモジュールを作れること。

WF型開発では、プロセスという工程の品質を再現させることに注力する。
そのために、属人化を廃し、作業手順を標準化する方向に走って、ソフトウェア開発からクリエイティビティをなくした。

でも、ソフトウェア開発における再現性の対象は、ビルド管理であるべき。
プログラミングや設計ではなく、ソースがあれば、いつ誰でも同じモジュールを作れることの方が大切だ。

【2】ビルドの種類

ビルドには幾つかの種類がある。
まずは、ビルドタイミングや品質に関する観点。

(1)CIビルド、継続的な統合ビルド
 必要に応じて、1日に数回ビルドして、自動テスト(オートメーション)も走らせる。
 ビルドエラーが発生すれば、すぐに障害票を起票して、即修正する。

(2)デイリービルド、日次ビルド
 1日1回、普通は夜間にビルドする。
 すべてのオートメーションを実行する。

(3)ウイークリービルド、週次ビルド
 週1回ビルドする。
 テストチームにリリース可能な製品を渡す。
 開発チームは、Testableな品質を保証するのが前提。
 品質OKなら、テストチームは受入テストを実施する。

 ビルドをテストチームにリリースする前に、テストチームによるテストが実施できる品質かどうか判定するテスト、つまり、スモークテスト(またはBVT)を実施するのが普通。
 スモークテストは主要な受入テストケースによるテストが多いだろう。

(4)マイルストーンビルド
 ユーザにリリース可能な製品を渡す。

次は、ビルドの手順に関する観点。

(1)フルビルド、完全ビルド
 全ソースをビルドする。
 普通は、各種コンポーネントを組み合わせて最終モジュールをビルドするので、全てのコンポーネントもビルドするとなると、ビルド時間がとてもかかるのが普通。

(2)インクリメンタルビルド、部分ビルド
 前回のビルド時から修正されたソースとそれに依存するファイルのみをビルドする。
 ビルド時間を短縮できる。
 但し、ビルドブレークが多発して、ビルドの再現性が落ちる場合、フルビルドに戻す。

(3)クリーンビルド、リビルド
 前回のビルドで生成された中間ファイルを全て削除して、ビルドする。
 ant cleanなどの処理に相当する。
 クリーン後にインクリメンタルビルドするなら、フルビルドと同じ。

 リビルドは、ビルドを再実行すること。
 VisualStudioの機能では、ビルドのメニューを選択するとインクリメンタルビルド、リビルドのメニューを使うとフルビルドのように使い分けることができるようだ。

ビルドの準備と管理

Visual Studio でのプロジェクトとソリューションのビルドおよびクリーン

(4)並行ビルド、分散ビルド
 マルチスレッド化したビルド処理が並行ビルド。
 複数のマシンで複数のビルドを並行して走らせるのが分散ビルド。
 いずれも、ビルド時間を劇的に短縮できるのが利点。

 並行ビルドは、AntならばParallelタスクを使うと良いらしい。

 Jenkinsでは、分散ビルドをマスター・スレーブ方式で実現している。
 
第3回 Hudsonによるチーム間の連携:Hudsonを使ったアジャイルな開発入門|gihyo.jp … 技術評論社

Jenkinsによる継続的インテグレーションのススメ(3) ~Jenkinsで分散ビルド~

【3】ビルドブレークとソフトウェアあんどん、XFD

ビルドブレークとは、不衛生なソースがコミットされてビルドが壊れる事象。
ビルドブレークが起きるということは、出荷可能な最終成果物が作れなくなったと言う意味であり、早急に直さなくてはならない。
でも、いつもすぐに分かればよいが、すぐに検知できない時もある。

トヨタ生産方式のように、自動車の製造ラインが止まった時に使われるパトランプ(あんどん)を光らせて、すぐに検知できるような仕組みが良い。
ソフトウェア開発に適用した場合、ソフトウェアあんどんやXFDの例がある。
実際にXFDを使うと、結構目立ってしまい、他の開発者の作業を中断させてしまうので、全員で直すだけでなく、再現しないように気を付けるようになるようだ。

第4回 プラグインを使う:Hudsonを使ったアジャイルな開発入門|gihyo.jp … 技術評論社

あるいは、ビルドエラーを検知したら、メールで全員に配信するだけでなく、JenkinsからRedmineへ検知メールを発行して、チケット自動登録する仕組みを作っても良いだろう。

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

【4】ビルド手順

ビルドには、複数の構成があり、構成ごとにビルド手順が違う。
例えば、JavaのWebシステムであっても、JDKのバージョンやRDBのバージョン、アプリケーションWebサーバのバージョンという構成内容によって、ビルド方法は微妙に変わる。
だから、複数のバージョンの組合せによるビルドモジュールを作り、それらの回帰テストが必要になってくる。
Windowsアプリならば、OSのバージョンやVisualStudioのバージョンによって、複数の組み合わせによるビルドが発生するため、ビルドや回帰テストがより一層大変になるはずだ。

Jenkinsでは、マルチ構成プロジェクトという機能を使えば、JDKやOSのバージョンの組み合わせの設定を作れば、同じビルド手順でビルドしてテストできる。
この方法を使えば、特定のOSやJDKのバージョンに依存するバグを見つけ出すこともできる。

第5回 高度なプロジェクトタイプ:Hudsonを使ったアジャイルな開発入門|gihyo.jp … 技術評論社

【5】継続的インテグレーション(CI)の種類

継続的インテグレーションの意義とその効果については以前書いた。

継続的インテグレーションを再考: プログラマの思索

継続的インテグレーションにも幾つかの種類がある。

(1)コミットビルド、軽量ビルド
 継続的にビルドする。
 普通はコミットするたびにビルドする。

(2)2次ビルド、重量ビルド
 時間がかかるビルド。
 フルビルドないしインクリメンタルビルド。

(3)段階的ビルド
 コミットビルドが通過したら2次ビルドを実行する。

2012/07/29 Jenkins ユーザ・カンファレンス 2012 東京 satta-4 : 複雑な多段階ビルドに対処する: 事例紹介 #juc2012 #juc2012_satta - Togetter

CIでは、ビルドの頻度があまりにも多いので、ビルド時間を短縮するために、並行ビルドや分散ビルドの仕掛けが必須だろう。
Jenkinsの分散ビルドの機能を使いこなすのは、CIの運用で必須になってくるだろう。

また、並行ビルドや分散ビルドの仕組みは、ビルド処理がバッチのジョブ処理に似ている性質を意味している。
つまり、複数のビルド処理を時系列につなげることで、ジョブフロー図として扱うことができる。

Jenkinsをジョブ管理ツールとして使うアイデア: プログラマの思索

Jenkinsをバッチ監視ツールとして運用する事例: プログラマの思索

Jenkinsの場合、Build Pipeline Pluginを使うと良いだろう。

Build Pipeline Plugin - Jenkins - Jenkins Wiki

kakakikikekeのブログ: 【Jenkins】Build Pipeline Pluginを使ってみた

Jenkinsでビルド・パイプラインを構築する - プログラマになりたい

この発想は、ビルドの時刻表を列車の時刻表に見立てて、ビルドを定期的かつ定刻にリリースする運用につながる。
これを「実践 反復型ソフトウェア開発」では、リリーストレインという概念で説明している。
つまり、ジョブフロー図の運用と同じだ。

【6】バディビルドの自動化

CIでビルドエラーのフィードバックが早く検知できるのは良いことだが、本来は、コミット前に教えてほしいものだ。
そのために、コミット前にサンドボックス上で事前にビルドするバディビルドが必要になる。
丁度、バディビルドがコミットビルドに相当するだろう。

最近はGitのような優れたバージョン管理が普及したので、サブブランチ上で事前にバディビルドするのがトレンドだろう。
つまり、ホットフィックスブランチやフィーチャブランチ、トピックブランチ上で修正してビルドが通過するまで開発者が責任を持つように開発プロセスを回す。

実際のビルド処理の流れとしては、ビルドマシンが下記を自動実行するイメージ。
下記のフローの利点は、マージ作業そのものも全てが自動化されるので、大変楽になること。

開発者がサブブランチへコミット
→ビルドマシンがコミットを検知して、バディビルドと自動テストを実施
→ビルドもテストもOKなら、ビルドマシンがサブブランチから親ブランチへポートしてコミットする

JiraとBamboo、Bitbucketを持つAttlasian製品では、ブランチ上に開発者がコミットしたら、後はビルドマシンが自動実行してくれるようだ。

GreenHopper を使用した Bamboo と Bitbucket の自動化

Atlassian製品による「No Ticket, No fork!」: プログラマの思索

Jenkinsで上記の処理を実現したい場合、コミットフック処理のスクリプト内で、サブブランチのバディビルドと自動テストを実施し、結果OKなら親ブランチへポートする処理を書けばよいだろう。

この発想は、チケット単位にトピックブランチを作って作業し、最終コミット時にtrunkへマージしてチケットをCloseする運用につながる。
つまり、チケット駆動開発ならば「No Ticket, No Fork」の運用ルールに相当するだろう。

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索

GitHubならば、全てが自動化されているわけではないが、PullRequestという処理が上記の処理に似ている。

PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み: プログラマの思索

【7】ビルドの品質

ビルドモジュールを区別するために、MD5チェックサムを計算する運用もある。
Jenkinsならば、ファイル指紋の機能に相当するだろう。

第3回 Hudsonによるチーム間の連携:Hudsonを使ったアジャイルな開発入門~ファイル指紋|gihyo.jp … 技術評論社

Fingerprint - 日本語 - Jenkins Wiki

ファイル指紋を使う状況は例えば、ビルドモジュールを手作業で本番環境にデプロイする場合、持参したモジュールが本当に正しいモジュールなのかチェックする時に使える。

CIビルドは頻繁に実施するので、どのビルドがテストに耐えうるのか、分かりづらい。
そこで、CIビルドの中でより多くのテストにパスしたビルドを昇進させて色付けするやり方が、ビルドのプロモーション。
つまり、テストチームが受入テストを実施できる品質のビルドにラベルを付ける。
Jenkinsならば、Promoted Builds Pluginを使って、上流ビルド・下流ビルドを作る運用があるだろう。

第4回 プラグインを使う:Hudsonを使ったアジャイルな開発入門~ビルドプロモーション|gihyo.jp … 技術評論社

Promoted Builds Plugin - Jenkins - Jenkins Wiki

Promoted Builds Plugin - おこらない日記

| | コメント (0)