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

最近、ツールとプロセスを組合わせたソフトウェア開発手法の本が増えているように思う。
読みたい本は「チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (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】クラウド技術と密接に連携した本番リリース作業の自動化は、今一番、技術革新が激しいところだと思う。
僕はクラウド技術に詳しくないので、この辺りは色々探っていきたいと思う。