GREEにおけるJenkins, その5

こんにちは、エンジニアの岡崎(@watermint)です。
今回も前回に続き初期導入のお話です。

どんどん水平展開する

Jenkins導入初期で、いくつかジョブが動き始めるようになったら類似のプロジェクトにどんどん水平展開していくのが最も簡単な方法です。Jenkinsには既存のジョブをコピーして新しいジョブを作る機能がありますので、これを積極的に使いましょう。

GREEでの導入事例ではまず最初に、iOSネイティブアプリのビルドに導入し、ある程度安定して運用が出来上がった段階から、新規開発機能向けのgitブランチを追いかける別のジョブを作る等まずは類似のプロジェクトへの展開を最初に行いました。

同様に、PHPのコードをテスト＆品質チェックするプロジェクトも最初に作ったジョブをベースにコピーして各種プロジェクトで利用しています。PHPのJenkins上での環境整備についてはPHPでTDD&CIワークショップ、Jenkins + PHP の各種プラグインパート資料が参考になります。

標準化をするか否か

このようにジョブをどんどんコピーしていくと、微妙な差異が生まれるなど弊害が出始めます。経験的には、Jenkinsを使うプロジェクトが5〜10プロジェクトを超えたあたりでこのようなジョブを標準化しようという話が持ち上がり始めます。
これは全く個人的な経験によるベストプラクティスなのでどのような組織にも当てはまるかは断言できませんが、少なくとも導入初期での標準化は見送った方が良いと思っています。
標準化することは確かに、メンテナンス性や品質保証のうえでアドバンテージが生まれるので否定する立場の人が少なく、ではやろう。という話になります。ところがいざ作業をはじめて見ると標準化のための敷居というのはとても高いことがあります。
導入初期に標準化を見送るべきとする理由は次のようなものです。

1. 開発環境への依存性排除が非常に難しい

個別のプロジェクトが抱えている開発環境への依存性排除は非常に難しく、面倒な作業です。開発環境に導入されているツール群の有無およびバージョン、リリースのための開発者証明書、ディレクトリ構成など差分を埋める努力には地道かつ手間のかかる作業をこなさなければなりません。

2. 各プロジェクトの開発ワークフローを標準化することが難しい

標準化を進めるにあたって、各プロジェクトの開発ワークフローを標準化することは難しい作業です。Aさんが作業した次に、Bさんがその成果物を受け取って作業する。など、開発プロジェクトには暗黙的なワークフローが出来上がります。よく似ていると感じている開発ワークフローでもプロジェクトチームごとの作業スタイルや文化の差により標準化は意外にも難しく、折り合いを付けることが難しい場合があります。

3. 最初にJenkinsを導入したプロジェクトが進化を止めてしまうこと

多くの場合、最初にJenkins導入を試みたチームがこれらの標準化に深く関わることになりますが、標準化のためにいろいろ制約事項を設定します。その一方で、自分たちのやろうとしていた新しい試みを封印してしまうことがあります。

4. 標準化すること自体が目的となってしまい、より良い開発ワークフローを構築できなくなる

標準化には比較的長い時間と、多くの労力が必要であるためその作業に集中することで徐々に標準化自体が目的となってしまうことが多く見受けられます。標準化が目的ではないことは最初は分かっているつもりでも徐々に目的が入れ替わっていくことをに気づくのは意外にも難しく、かなり意識的に働きかけをしないと目的と手段の逆転は防げません。

以上のような理由からも、少なくともJenkins導入初期には標準化を見送り、組織のなかでJenkinsの成熟度が上がるまで（たとえば1年程度）は、プロジェクトごと、チームごとの生産性向上のために努力すると、組織における普及期にも大きな財産となるのではないでしょうか。
では次回もお楽しみに。