GREEにおけるJenkins, その4
okazakiこんにちは、エンジニアの岡崎(@watermint)です。
今回は、先日行われたJenkinsユーザカンファレンスで発表した内容をもう少し掘り下げて紹介していこうと思います。今回のカンファレンスでは、「開発者とディレクターの視点を変えていく方法」と題してJenkins初期導入時のこつ、その後の運用の改善について説明していきました。今回は特に初期導入の部分についてもう少しご紹介します。
Jenkins導入のコツ
Jenkinsを導入したいがなかなか進まないという経験をお持ちの方は多くいらっしゃると思います。CI(継続的インテグレーション)のようなツール群は一度回り始めれば必要不可欠とも思えるような仕組みを持っていますが、利用経験の無い方からすると得られるメリットのイメージが既存の仕事のやり方やワークフローを変えるコストをなかなか超えることが出来ないために積極的になれないということが多いようです。
実際のところ、ワークフローをかえるというのはかなり大きなコスト／時間がかかる作業です。また、組織の規模や仕事の規模に応じてその複雑さは大きく変化します。
JenkinsのようなCIツールを開発ワークフローに導入する際においては十分に時間をかけて導入したほうが良いでしょう。
一般に、何かのツールやワークフローへの習熟度は時間経過とともに緩やかに高くなります。この習熟度は個人としての習熟度もあるでしょうし、組織としての習熟度も同様にあるでしょう。未熟なうちに強引に導入を進めた場合、そもそもJenkinsにどういうジョブを作ればワークフローを完成できるのかが個人・組織の中で決められずJenkinsを使うこと自体が目的となってしまい、無駄なジョブが量産され、結果的にそれらのジョブはどこからも参照されていないという状況に陥ります。
小さなことからこつこつと
GREEではGREEにおけるJenkins, その1でも紹介しましたが、iOSやAndroidのネイティブアプリビルドから導入を始めました。
ネイティブアプリのビルドは、ビルド手順が開発が進むにつれ複雑化し、XcodeバージョンアップやAndroid SDKバージョンアップなどの外的要因によっても日々手順をメンテナンスしていく必要があります。iOSやAndroidのビルドを正確に実行して実行バイナリを作るというのは徐々にある意味職人芸のような境地に陥ってしまいますが、エンジニアの本来の仕事はビルドではありません。
このような種類の仕事は開発ワークフローのなかでは比較的独立性が高く、もともと機械化がしやすい分野です。一方で、antやmake、xcodebuildなどコマンドラインでのビルドが出来るようにするには環境の確認や、ビルド手順の再確認など地味で面倒な作業です。この作業に根負けしてJenkins導入をあきらめてしまうことも少なくはないでしょう。
その場合では、まずは簡単なデプロイ作業を組み込んでみるとか、最後のパッケージングだけを管理するとかすぐ出来そうなところを見つけて「この作業はJenkinsに任せる」ということを体験してみてください。小さな成功体験を積み重ねることによって習熟度があがり、徐々に複雑なワークフローを構成できるようになりますし、チームや組織もJenkinsの存在を受け入れる準備が出来上がっていきます。
次回も引き続き導入について解説しようと思います。お楽しみに。