事例

構成管理計画を立てて実行する

ここまでGitやMavenについて色々と書いてきましたが、ビルド職人は構成管理の計画を立てて実行することが最大の仕事です。 ここで、とある大規模開発の構成管理はどうやったかを例として、ここまでに書いた内容をおさらいしたいと思います。

1. 前提条件

• 開発ロケーションは社内、ニアショア1拠点、オフショア2拠点の計4拠点
• ソフトウェアレイヤーは以下のとおり

2. チーム分け

以下のようなチーム編成としました。

• ソフトウェア基盤、業務共通： 社内（アーキテクトチーム（DBA含む））
• サブシステム１： 社内（業務チーム）
• サブシステム２： オフショア１
• サブシステム３： オフショア２
• サブシステム４： ニアショア

ソフトウェア基盤と業務共通がアーキテクト１チームで製造する構成となっており、先に述べた形とは違いますが、 アーキテクトチームにDBAが含まれているので、業務共通は実質DBAが一人で見ていると思ってください。

3. 全体構成

構成管理の全体概要図です。 クラウド上のサーバにJenkinsを立ち上げ、サイトリポジトリからソースを取得してMavenでビルドを行い、このときにSonarQubeのDBへCheckstyle、Findbugs、JUnitの結果を保存し、 SonarQubeをCIに組み込みました。

また、お客様実行環境へビルドしたソフトウェアをデプロイする場合は、ビルド職人によりJenkinsへ要求を出し、 ベースリポジトリからソースを取得してMavenでビルドを行っています。 本番環境へのデプロイを行う場合は、ライブラリ管理（Maven Archiva）にデプロイモジュールを保存し、本番環境へデプロイしたモジュールは過去に遡っていつでも即座に取得可能となっています。

今回は特には触れませんが、実行環境へのデプロイはJenkinsからリリーススクリプトを叩いて自動化しています。

4. 内部構成

構成管理を内部的に回すための開発時の内部構成図です。 ここまでに書いた内容を網羅していると思います。

まず、ビルド職人がベースリポジトリを作成し、サイトリポジトリをforkします。 開発を開始する前に、マスタブランチへマージを行うためのブランチをバージョンブランチとして作っておきます。 開発が始まる前に、開発者へは以下の２つのルールの徹底をお願いしておきます。

• 開発用のブランチを切る場合は、バージョンブランチを親とする。
• 開発が終わってリモートリポジトリにpushしたら、バージョンブランチに対してプルリクエストを送る。

１つ目のお願いについては、ビルド職人がブランチを切り、このブランチで開発をしてください。というお願いもできますが、これをやってしまうとビルド職人の負荷が上がって作業的に回らなくなる可能性が出てくるためやめましょう。

これで開発の準備はできたので開発者に開発をしてもらいましょう。

最後にベースリポジトリにサイトリポジトリをマージする手段がプルリクエストとマージとがあります。 これは、Jenkinsを使っているかいないかの違いです。

Jenkinsを使用してビルドを行えば、変更履歴にコミットログとそのときに変更したソース一覧が出てきます。 なのでJenkinsを使用しているときはマージで良いです。 Jenkinsを使用していないプロジェクトはプルリクエストを履歴とするようにすれば、いつ何を入れたかがすぐに判るようになります。 ただし、プルリクエストのログはマージログも一緒に出てしまい、余計なものが含まれるのでこの点は注意してください。