こんにちは、鈴木です。
社内で継続的デリバリー勉強会の第二回を行いました（第一回レポートはこちら）。
継続的デリバリー勉強会 Vol.2
勉強会の内容
勉強会は以下のメニューで行いました。
- 前回のおさらい
- ソフトウェアデリバリーのアンチパターン
- ワンクリックデプロイのデモ
- ディスカッション
前回のおさらい
継続的デリバリーの勉強会は全 3 回を予定しているシリーズものです。
参加者の中には前回参加していない人もいるため、前回の内容を簡単におさらいしました。
前回は継続的デリバリー自体を知ってもらうために、デプロイメントパイプラインについて解説しました。
デプロイメントパイプラインとは、ソースコードをコミットしてからユーザに価値を届ける（本番環境にデプロイする）までのプロセスを表したものです。そして、継続的デリバリーはこのパイプラインを可能な限り自動化していくことで価値を生み出していく活動になります。
あとは前回のディスカッションで出たトピックに対する取り組みの進捗を共有しました。
ソフトウェアデリバリーのアンチパターン
書籍には多くのアンチパターンが書かれていますが、その中からいくつかをピックアップして紹介しました。
良くあるアンチパターンとして、長いデプロイ手順が存在し、それを手作業で入力していく、というものがあります。
手作業が多いと作業時間も多くなり、またミスも発生しやすいものです。
そのような状況が続くと、デプロイ職人（その人がいないとデプロイできない人）を生み出しかねません。
ソフトウェアデリバリーに関するアンチパターンに陥らないためには、きちんと自動化を行い、その部分を作りこむ（品質を高める）ことが重要です。
そして、自動化などの良い習慣は、可能な限り初期の段階で取り入れることが重要です。
それらの良い習慣は、アプリケーションやデリバリープロセスの設計に影響する場合があるためです。
また、良い習慣の恩恵を受けることができる期間も長くなります。
ワンクリックデプロイのデモ
Jenkins を利用してワンクリックデプロイをするデモを行いました。
特筆すべき点としては、Jenkins API を利用してジョブの作成を行うスクリプトを準備したところです。
社内の多くのシステムでのフローを振り返ったところ、必要なジョブは複数必要ということがわかりました。
そして、Jenkins のジョブを作成して正しい設定を行うことは、なかなか大変です。
そこで、プロジェクト名などの基本的な情報を入力すれば Jenkins に必要なジョブを登録してくれるスクリプトを準備しました。
これによって、デモも非常にスムーズに行えました。
ディスカッション
最後にディスカッションを行いました。
テーマは今回発表した内容を中心に、疑問点や実現するときにどのような壁があるのかを話し合いました。
ディスカッションはチームに分かれて行い、最後に各チームで話し合った内容を発表しました。
その中で印象に残っているものをいくつか紹介します。
デプロイ職人が別の形の職人として出現する？
ワンクリックデプロイを実現すれば、誰でもワンクリックでデプロイすることができるようになります。
それはデプロイ職人の問題（その人しかデプロイできない、問題発生時に対処できない）を解決します。
しかし、デプロイ職人は消えても、別の種類の職人が発生しないだろうか、という指摘がありました。
例えば、Jenkins などを利用してワンクリックデプロイを実現したとします。
しかし、Jenkins を深く使えば使うほど、その設定内容は複雑になってしまいます。
すると今度は Jenkins 職人なる人が出現するのではないか、何か問題が発生した場合にその人しか対処できなくなるのではないか、という指摘です。
なかなか難しい問題です。「こんな風にやってるよ！」などありましたら、ぜひ教えてください。
ワンクリックデプロイを実現したとして、デプロイ内容によってどれをクリックするか変わるのか？
ワンクリックデプロイを実現するということは、手作業で行っていた内容をスクリプトなどに置き換えるということです。
そしてそのスクリプトはテーブル定義変更の有無や、メンテナンス表示（システム停止）の有無などによって分かれるのか、という指摘がありました。
別の言い方をすると、どのような場合でも一つのデプロイスクリプトで対応できることが理想だが現実問題としてできるのか、という指摘です。
まとめ
今回もディスカッションでは有益な話ができました。
課題や疑問として指摘された内容も、すぐに答えがでないか、導入するときに注意する必要があるものばかりでした。
今回話し合えたことにきちんと向き合い、今度の取り組みを進めたいと思います。
