2015/01/11法政大学外濠校舎にて開催されたJenkins User Conference 2015に参加をしてきました。僕はJenkinsを知って、利用をし始めてからもう5年は経つかとは思いますが、もう開発フローにおいてJenkinsは無くてはならないツールの一つになってきているように思いました。そのため、単純なビルドの自動化だけではなく更に複雑な開発フロー・運用フローの一部としてJenkinsを導入した実績についての講演が多かったように思います。
バザールのような開発者コミュニティ
基調講演でjenkins開発の第一人者である@kohsukekawa氏は、開発者コミュニティを中東のバザールのようだと表現されていました。確かに、様々なプラグインが日夜作られ先日その数は1000件を突破したとのこと。また、jenkinsをベースにしたサービスやソリューションが登場。Amazon Web ServiceやGoogle Cloud Platform、Dockerを始めとしたテクノロジー系のカンファレンスのほとんどではjenkinsを開発・運用フローに含めた構成が紹介されたりと、利用者側も多種多様な活用方法が見られてそのバリエーションは大きな広がりを見せているとのことでした。
「バザールのような」と言うことで、様々な物が揃っていてうまく活用すれば便利な機能やノウハウに出会える可能性は高いかもしれないのですが、外側から見た人としては何が行われているのかがわかりにくいと言う状態でもあるようです。
運用フローの中にJenkins
JenkinsといえばCI(継続的インテグレーション)を実現するアプリケーション・サービスでしたが、その需要はビルドやテストだけではなくデプロイ等を含んだ継続的デリバリーにも活用されるようになっているそうです。しかし、デプロイは環境によっては関連しているミドルウェアの依存性解決、他のサーバーやアプリケーションとの連携、また時にはユーザー(開発者・デプロイ担当者)の承認が必要だったりと複雑なフローが求められることが多いとのこと。そこで@kohsukekawa氏が開発されているプラグインがworkflow-plugin。
jenkinsci/workflow-plugin · GitHub
その機能をざっと書き出すと、
- groovyをベースとしたDSLでビルドに関する設定を記述することができるので、jenkinsの設定をバージョン管理することができる
- groovyのソースコードをjenkinsの内部で動くリポジトリで管理をすることで、ビルドタスクをジョブを超えて再利用することができる
- 条件分岐や繰り返しなどの制御構文を利用することができる
- チェックポイントを設置しておくことで、ビルドに失敗をしてもチェックポイントの途中からやり直すことができる
- masterで動作しているjenkinsの動作が停止をしても、slaveのプロセスが残っていればチェックポイントを活用して再開をすることができる
- 対話的なインターフェースを提供することもできるので、ユーザーの入力によって処理の変更を行うことができる
詳細はドキュメントを読んだり試したりするのが一番かと思いますが、複雑なワークフローにも耐えかつ拡張性のあるプラグインとなっているようです。
はてなにおけるjenkinsの活用事例
@nobuoka氏の発表による株式会社はてなにおける活用事例と、はてなが開発・運用を行っている「少年ジャンプルーキ」におけるjenkinsの運用事例紹介を拝聴しました。株式会社はてなと言えば、Perlによるサービス開発がメインとのことで、jenkinsはtypescriptのコンパイル、javascriptやcssのminifyなどで利用をされているとのこと。
また、少年ジャンプルーキでは開発途中のアプリケーションについてもDockerを利用してレビュー環境を構築することで、非プログラマーや遠隔地で作業をしている人に対しても現在の状態を公開できる仕組みを実装されたとのこと。
Github EnterpriseでPull Requestを作ることで、jenkinsがビルド・テスト・テスト環境の構築などを行うフローが完成しているそうです。また、デプロイについては現在は半分手動とのことでしたが、workflow-pluginの導入による自動化も検討されているとのことでした。
Cookpadにおけるjenkinsの導入事例
Cookpadでは「Jenkins」氏ではなく、おにぎりの国から来た「おむきんす」氏が継続的インテグレーションを実現しているとのこと。こういったギャグは素敵ですね。
登壇者の高井氏曰く、「普通の利用方法」を行っているとのことでした。普通とはやるべきことをやり、常にそうあるようにすること。
jenkinsというか、CIが与える価値として3つの事柄を挙げておられました。一つ目は「意図しない変更を予防すること」。開発者の変更によって、意図していない副作用が発生してテストに失敗をしたとしてもすぐに発見、修正を行うことができることでした。そして、その状態をキープするためにはCIが失敗をしても気にしないと言った状態を許さないようにしなければならないとのこと。
2つ目は再現可能で自動化されていること。何度実行しても同じ結果が得られるようにしなければなりません。そのためには、例えばデプロイされている物とjenkinsの成果物が紐付いていないなどの状態は避けるべきということでした。
最後はリソースや情報を集約されていること。アセットの作成やテスト結果を保存しておき、可視化などを利用してあとから分析できる状態を作っておくことで、フロー改善やサービス改善に繋がります。
CIは価値を生み出す行為ですが、その価値をチームメンバーで守って行かなければなりません。
Infrastructure as a CodeにおけるJenkinsの役割
最後の講演は、株式会社サイバードの@Altsencturelyと@megadreams14による発表。Chefとjenkins、そしてAWSを連携してスケールアウトの自動化/高速化を実現したと言うお話。
もともとChef-Serverを利用していたそうですが、cookbookが肥大化、密結合になってしまいメンテナンスが困難になったことやスケールアウトに時間がかかってしまう問題が発生していたそう。それは、本来構成管理ツールであるChefを、AWSのサービス設定やOSの準備と言ったProvisioning Toolchainで言うところのBootstrapingレイヤやOrchestrationレイヤの仕事もさせてしまっていたから。
そこで、デプロイやスケールアウトを管理する部分をjenkinsに変更、各タスクをジョブに割り振りジョブのフローを利用することで実行状態の可視化や失敗した箇所の発見、またcookbookの疎結合化などメンテナンス性の向上や実行時間の短縮化を実現したとのことです。
参加をした感想
2年前に開催されたカンファレンスにも参加をした際も導入事例の話は多かったように思いますが、「Androidアプリのビルド方法」や「導入実現までに何を行ったか」などと言ったビルド用のツールとして、あるいはどうやって周りに情報を共有したのかと言ったノウハウが多かった気がします。
それが、今回はビルドだけではなくもっと大きな開発・運用フローの一部に組み込んだ事例紹介が多くありました。それだけ、jenkinsのでポテンシャルと言うか可能性と言うかが知られ、認められまた求められてきたということでしょうか。また、今ではプロジェクトにCIを取り入れる際にはjenkins以外にはtravis ciやcircle ciを始めとしたクラウドサービスがいくつも選択肢として存在しています。
オンプレミスで立ち上げることができ、オープンソースでプラグインによる拡張が活発なjenkinsはそう言ったクラウドサービスのCIとの良い差別化ができているな、と思いました。
今回はデプロイや運用についてjenkinsが有効利用できる、実績があるということが分かったのでチームで展開・実践を行いたいです。
今後に向けて
今回のカンファレンスの基調講演を始め各講演内容は非常に良いものが多く、その分運営の不手際などが目立ったのがアレでした。今後もより良いカンファレンスの開催を期待しまた、イベントの主催を行うこともある自分への戒めとしてちょっとまとめておきます。
- イベントの開始時間はしっかりと確認をしておいてもらいたいです。直前にTwitterで回ってきたので気がつくことができましたが、基調講演に参加できなくなるところでした。
- 無線LAN関連の情報展開をお願い致します。帰る直前になってSSIDとパスワードの張り紙が一番大きいホールの壁に貼られていることに気が付きました。
- 各発表の質疑応答は発表終了後にまとめて行うようにルール化しておいて貰いたかったです。発表途中で質疑が入ってしまうことがあって、聞いている側としてはちょっと微妙でした
しかし、非常に良い内容の講演が多く楽しい時間を過ごすことができました。また次回のイベント開催を期待いたします。
