いつでも完成品を 継続的インテグレーション
はじめに
エクストリームプログラミングには様々な良い経験則、習慣(ベストプラクティス)がある。その中でも有名なのは継続的インテグレーションだろう。
ここでは継続的インテグレーションが確立されるまでの流れに注目し、説明しようと思う。
いつでも完成品を
そもそも継続的インテグレーション(Continuous Integration)という単語から何を行うかが想像できるだろうか? 正直な話、私が初めてこの単語を聞いたとき、全くと言っていいほどピンと来なかった。
Continuousは時間的、空間的にに途切れなく続いているといった意味合いで、Integrationは統合、完成を表す。[いつでも完成品(or 統合)を]と言い換えれば少しイメージしやすくなるのではないか。完成品とはソフトウェアを指す。
どういった経緯があったのか?
[継続的インテグレーション]の流れを知るのにちょうどよい資料があるのでそれを見て行こう。
彼はデボン。継続的デリバリを実践している。彼はDevOpsマスターだ。
でも彼は常に優秀であったわけではない。彼の成長を見て行こう。
アジャイルソフトウェア開発のコンサルティングを行っているcPrimeという会社の資料だ。この資料では開発工程の変遷をデボンという人物の成長に見立てて説明している。
CIとはContinuous Integrationの略で、CDとはContinuous Deliveryの略だ。Continuous Deliveryは継続的デリバリと呼ばれている。先ほどと同じように言い換えると[いつでもお届け]といった感じだろうか。もちろんここで届けらるのはソフトウェア(もしくはソフトウェアによって提供されるサービス)だ。
DevOpsは、、、「開発者と運用者が仲良くして、お客様にとって有用なソフトウェアの機能を、1日に10回実装できるくらいに効率のいいチーム作ろうね」みたいなスローガンだと思ってもらえばいい。CD/DevOpsに関しては今回特に触れない。
赤ちゃんデボン ソースコードの管理
ソフトウェア開発は複数人で行う。ソースコードを各自で作成、編集し、それぞれが作ったものをまとめていくわけだが
- どのプログラムのファイルが最新で、最後に誰がいじったか分からない
- メンバーが作業用フォルダ、ファイルなどを作るのでフォルダが汚くなる
- それぞれのメンバーが作成したファイルを最後にまとめるのが面倒だ
といった問題が出てくる。上記の問題を解決するために出てきたのがバージョン管理システムだ。これを使うことによって、だれがどのファイルを編集したかが分かるほか、個々の作業環境を分割したり、成果物となるソースコードのまとめたりするのが楽になる。
幼児デボン 構築の自動化
ソースコードを[動くソフトウェア]として構築(ビルド)するのも手間がかかる。ソースコードを[動くソフトウェア]にするには
などの作業が必要である。構築作業を簡略化するために作られたのがビルドツールだ。ビルドツールで作業をあらかじめ定義しておくことで、構築作業を自動化できる。さらにビルドツールでは以前に同じ作業を行った場合はその作業を省略したり、ある作業がどの作業に依存しているかを確認してビルドの成否判断を報告してくれたりする。
少年デボン テストの自動化
構築ができたからと言ってそれが完成品となるわけではない。テストが必要だ。テストも繰り返しの作業が多い。
- プログラムが正しいかどうか判断するため複数のデータを入力し動きを確認する
- プログラムを変更した際に、予想外の変更が無いかどうか再度テストする
特にプログラムを変更した後のテストは同じことの繰り返しがほとんどだったりする。テストを自動化するために使うのがテスティングフレームワークだ。テスティングフレームワークを使ってテスト内容を定義しておくことで、テストを短時間で繰り返し行うことができる。またこのテスティングフレームワークはビルドツールから呼び出すことができるので、構築、テストをスムーズに行うことができる。
青年デボン いつでも完成品を (継続的インテグレーション)
ソースコード作成、構築、テストが完了すれば完成品と呼べるようなソフトウェアが出来る。各工程で作業を効率化するためのツールが生まれたが、これだけでは解決されない問題がある。
- バージョン管理システムを使っても、まめに管理をしなければ個々が管理するソースコードの中身が大きく乖離してしまい、ソースコードをまとめるのに非常に時間がかかる
- ビルドを自動化しても、それぞれの開発者が利用しているライブラリのバージョンや、開発環境などが異なる場合、うまく構築できずソースコードを書き直す必要が出てくる
- テストを自動化しても、要件や設計内容を意識してテストを設定しなければ、抜け漏れが多くなり見逃す欠陥(バグ)が増える。発見が遅れれば大変なことになり、もちろんソースコードを書き直す必要が出てくる
ソースコードが大きければ大きいほど問題が複雑になり、工程の後になれば、なるほど出戻りが大きい。ウォーターフォール型では[設計]がすべて終わった後に[開発]、[開発]がすべて終わった後に[テスト]といった手順で行う。そうすると必然的に大きな単位のソースコード取り扱う事になるため、複雑化し、各工程の人員も異なるので見逃しが起こりやすい。
プレゼントBOXのアイコン素材 | FLAT ICON DESIGN -フラットアイコンデザイン-
これを防ぐために考えられたのは小さな単位の機能ができたらすぐ、ソースコードを統合、自動化されたビルド、テストを行うといったやり方だ。一連の作業を小さな単位で行うことによって問題の発見を早め、かつ[動くソフトウェア]、つまり完成品を常に用意しておく。これが継続的インテグレーションである*1。
継続的インテグレーションツール
こまめに完成品を作るのは容易な作業ではない。[開発]、[構築]、[テスト]を何度も何度も繰り返さなければならない。1日に1回どころか、1日に複数回このサイクルを回すときだってあるはずだ。そうすると以下の要望が出てきても不思議ではない。
- 特定の時間や、ソースコードを統合したときなど、任意のタイミングで自動化されたビルド、テストを手作業(自動化ビルド実行するためのコマンド入力)無しで行いたい。
- 複数人が自動化されたビルド、テストを行っていても問題ないようにしたい。
- ビルド、テストの成否結果、実行ログなどを分かり易い形で閲覧したい。
そのために継続的インテグレーションツールが出てくるわけだが、ここまでの説明からこのツールの設計意図や機能などは想像するに難しくないだろう。これを使えば[開発]、[構築]、[テスト]にかかわる作業がよりスムーズになるはずだ*2。
まとめ
- ソースコードの管理のためにバージョン管理システムが出てきた
- ビルドツール、テスティングフレームワークなどの自動化ツールも作られた
- しかしこれらだけではソースコードの複雑さに起因する問題は防げない
- ビルド、テストを頻繁に行い、完成品を用意するという考えが生まれた
- [開発]、[構築]、[テスト]のサイクルを継続的インテグレーションツールで楽にする
*1:アジャイルソフトウェア開発の手法の多くでは開発対象の機能を小さな単位に分け[設計]、[開発]、[構築]、[テスト]を短い期間(1~2週間)で行い、それを繰り返す。こういった手順の背景には継続的インテグレーションの要素が含まれていると考えられる
*2:もちろんこれらを使いこなすための技術や、チームとしてのルールが必要だ