Indeed が急成長する中で、沢山の課題が生まれましたが、中でも特にリリース工程は、取り組みがいのあるものでした。ほぼ手動の工程はスケールできず、ボトルネックとなってしまいました。なので、私たちは独自のソリューションの開発を決めました。私たちが工程を自動化するなかで学んだ教訓は、ソフトウェアの質と開発者の善意を保っていきたいと考える、他の急成長中の組織も応用できるものとなりました。
私たちが辿った道のり
私たちのソフトウェアリリースの工程は、以下のように四つの主な目標があります。
- どの機能がリリースされるのか理解していること
- プロダクト間、チーム間での依存性について理解していること
- リリース候補の中にあるバグを素早く修正すること
- 追跡、分析、反復利用を可能にするため、リリースの詳細を記録すること:
そして、私たちの工程は最終的には以下のようになりました。
この工程は分かりやすかったのですが、多くの作業を必要としました。どんな状況だったかと言うと、4 件の新規機能を持つ 1 件のソフトウェアリリースに対し、100 回分のクリックと Git のアクションが必要でした。1 件の新規機能につき、およそ 13 回分のアクションが工程に追加されました。
こうした工程の確認を通して、私たちは、４つの主な問題を見つけ出しました。
- リリース管理に時間がかかりすぎた
- リリースの中身が正確には何なのかを理解しにくかった
- 手動のステップが多すぎたため、エラーが発生する可能性が高かった
- リリースをきちんと扱える知識を持つのはシニアマネージャーだけに限られていた
そうして、私たちは気づきました。自動化がもっと必要だ、と。
単純化すれば良いじゃない？
もちろん、工程を自動化するよりも、ただ単純化することもできました。しかし、私たちのもつ工程は、無くしたくない二次的な利益がありました。
データ 工程が与えてくれる多くのデータと指標のおかげで、継続して改善を重ねることが可能
履歴 工程があるので、何がいつリリースされたかを追跡することが可能
透明性 複雑ではあるものの、工程のおかげで各ステップを検証することが可能
自動化までの道
私たちは、工程の多くを自動化し、オーバーヘッドを減らせることに気づきました。そのために、既にあるソリューションをもっと上手に、賢くまとめる必要がありました。
私たちの工程は、以下の複数のシステムを使用しています。
- Atlassian JIRA: 課題管理と追跡
- Atlassian Crucible: コードのレビュー
- Jenkins: リリース候補のビルドとデプロイ
- Gitlab: ソース管理
- 様々なビルドや依存性の管理ツール
これらのツールを置き換える代わりに、これらツールが各自コミュニケーションをとれるように、統一されたリリースシステムを作り上げることにしました。この統一したリリースシステムを、管制塔を意味する
Control Tower (コントロールタワー) と呼ぶことにしました。
Control Tower の機能を表すスライドショー
依存性の管理ツールとの統合によって、リリースマネージャー（RM）がライブラリ・アップデートを通して入ってくる新しいコードの追跡を出来るようになりました。RM は素早くコードの相互依存性を評価し、リリース内の変更の進捗を確認することができます。最後に、RM が全て確認した後、 Jenkins を通してビルドの実行が可能になります。
Control Tower のメイン画面からは、RM が全ての関連システムの詳細を確認することができます。変更は JIRA のイシューによってまとめられ、各変更項目はCrucible のコードレビュー情報と Git のレポジトリ・ロケーションのリンクを含んでいます。
自動化することで、リリース工程の中で必要だった人間同士のやりとりを劇的に減らしました。以下の画像は、グレイの色がついたボックスそれぞれが、削除された手動のステップを表しています。
自動化をすすめた後では、必要なクリックや Git のアクションの回数を、100 回以上から、15 回未満まで減らしました。新規機能を追加するのも、13 回のアクションを必要とするだけで、余分な仕事を増やすことがなくなりました。
Control Tower に興味を持った方は、是非 Indeed Eng テックトークをご覧下さい。Control Tower について、32:45 ごろから説明しています。
私たちが学んだこと
統一されたリリースシステムを作り上げる過程で、私たちはいくつか大切なことを学びました
教訓その１：
自動化すべきは欲しい工程でなく、既にある工程
私たちが最初にリリース工程の自動化に着手した時、私たちは、ついエンジニアがそういう状況でしてしまうことをしました。それは、始める前に、工程を可能な限り理解できるように、工程を学ぶ、ということでした。それから、またエンジニアがやりがちなことですが、それを改善しようとしました。
自動化を進める中で工程を修正する、ことは当然です。けれど、例え問題があったとしても既にテスト済みの稼働する工程のほうが、格好よく見えるテストされてない工程よりも好ましい、と言うことを私たちは学びました。自動化の最初の試みは、開発者たちが新しいやり方に馴染みがなかったので、反発を受けました。
教訓その２：
自動化は想像以上に有意義である
多くの人が工程を「自動化」と聞くと、人間による意思決定を削除して、設定したら後は忘れてしまうようなものだと考えがちです。しかし、場合によっては工程から人間のやりとりを削除できないこともあります。技術的に難しすぎる場合や、正しい結果になるのをきちんと確かめるために、人間の目でチェックしたい場合もあります。そういった状況でも、自動化が役立つのです。
場合によっては、自動化はデータを集めて表示し、人間が決断を下すスピードを上げてくれるのです。何かを選択する際に人間の手が必要な際にも、より良いデータを提供することで、さらなる情報に基づいた決断を下しやすくなる、ということに私たちは気づきました。
人間と機械のアクションの適切なバランスを決めるのは、自動化にとっての鍵となります。機械学習の技術を取り入れることで、人間による意思決定をさらに加速させるような改善も、将来行えるようになるでしょう。
教訓その３：
何がなんでも透明性が大事
エンジニアは、非効率なものを好みませんが、謎も同様に嫌います。「何故」「どうやって」などの洞察を与えることなく、全て行ってしまう、ブラックボックス化した工程は避けたいと考えました。
私たちは、できる限りログを取り、メッセージを使用して、十分な透明性を提供しています。どんな工程が実行されたか、そして何故それが実行されたかを、開発者が検証できるようにすることで、彼らが自動化のソリューションを信頼し、受け入れやすくしました。また、ログは、何か不具合が発生するようなことがあれば役立ちます。
そして、これから
新しいシステムの環境が整ったとはいえ、私たちは、これすらも改善できると考えています。次なるステップも、密かに取り組んでいるところです。
課題のステータス、完了したコードレビュー、ビルド／テストのステータス、そしてその他の外部の要素を監視できるアルゴリズムを、現在私たちは開発しています。リリースの準備ができた機能を、プログラムで理解することができるシステムを開発できるのです。そして、自動で適切なマージリクエストを作成し、リリース工程を進める事ができるのです。これは、さらに機能の作成と本番に送り出すまでの時間を削減してくれます。
機械学習の技術を利用して、意思決定のプロセスで使用する膨大な量のデータを取り込むことができます。これはリスキーなデプロイを指摘し、さらにテストに時間を費やすべきか、最小の監視だけでデプロイが可能かどうかを教えてくれるのです。
私たちのリリース管理システムは、顧客が望む品質を維持しながら、ソフトウェアのアウトプットを増やすための、重要なステップです。このシステムは、あくまでステップであり、最終的なゴールではありません。継続して工程を改善していくことで、そして進んで行く中で学ぶことで、私たちは、「さらに多くの求職者と仕事の橋渡しをする」という、最終的なゴールを目指しているのです。