BI WORLDWIDEがデプロイを1日10回に増加させた方法

BI WORLDWIDE（BIW）は、人々にインスピレーションを与え、測定可能なビジネス成果を提供します。インスピレーションを受けた従業員は問題を解決し、価値を創造します。インスピレーションを受けた営業担当者はリスクを取り、機会をつかみます。そしてインスピレーションを受けたチャネルパートナーや顧客は、常にあなたのブランドを選びます。私たちは、ビジネスを動かす人々によってのみ達成できる卓越した成果を知っている世界中の優れた企業と協力しています。

BIW Corporate Product Development Team（CPD）は、数年前に作成された大規模なレガシーコードベースを扱っていました。彼らは、オンプレミスインフラストラクチャへの手動テストと手動デプロイを排除（または少なくとも大幅に削減）することを目指していました。メンテナンスのバックログ、非効率性、組織間の可視性の問題がありました。目標は、ツールチェーンの複雑さを取り除くことで運用効率を達成することでした。

同社はまた、シングルテナントのコード変更駆動型ソリューションという以前のアーキテクチャを更新し、マルチテナントの構成駆動型ソリューションにアップグレードしようとしていました。レガシーアプリケーションのインストールパターンは、VMにデプロイする前に顧客のニーズに合わせて調整できる（そして調整される）フォークからインストールすることでした。このパターンは顧客に柔軟性を提供しましたが、非効率的で、メンテナンスとアップグレードに時間がかかりました。

「それらのコード変更をすべて適用するのは非常に時間がかかりました」とBI WORLDWIDEのプロダクトアーキテクトであるAdam Dehnel氏は述べています。「その結果、新しいリリースをそれらの異なるインストールに適用するのはかなりのプロセスだったため、リリース頻度が低くなりました。そのため、各リリースに『すべての機能』を入れようとし、プロセスがさらに遅くなりました。」

Corporate Product Development Teamは、2014年にCVSを使用しながらGitソースコード管理を検討しました。当時、9か月のリリースサイクルを達成し、さらに数か月かけてコードを顧客インストールに配布してアップグレードしていました。このテンポは、市場への提供ペースと顧客リクエストへの対応能力に影響を与えていました。

このパターンに対処するため、プロダクトアーキテクチャチームはプロセスを再考する指示を受けました。基本的にすべてを更新しモダナイズすることです。当時、プラクティスとツールは整っていましたが、ビジネスを差別化する機能ではないアイテムに時間を費やしていました。チーム間のコミュニケーション不足、組織内ワークフローの非効率的なメカニズム、個別化されたツールセットなど、典型的な問題に直面していました。

これらの課題を解決するための初期の動きの1つは、ソースコントロール管理のためにCVSからGitに移行することでした。この移行に必要なモダナイゼーションの取り組みにより、「Gitへの苦痛な移行」を経験しました。GitHubへの最初の移行が完了すると、BIWはビルド、テスト、デプロイプロセスの自動化を検討し始めました。この最初の実装として、チームはGitHubがJenkinsと通信し、次にCheckmarx + WebInspect、さらにJiraとConfluenceを使用してフルライフサイクルマイクロサービスを管理するツールチェーンを構築しました。これらのツールは正しい方向に向かっていましたが、組織はツールチェーンの複雑さに関する課題に直面し続け、バグレポートの紛失、絶え間ないコンテキストの切り替え、組織全体でのツールの違いを経験しました。

CPDチームは、現在のツールセットおよび競合他社に対してGitLabの機能を評価し、次のイテレーションを達成するためにGitLabを選択しました。グループはツールチェーンを簡素化するために削除できるツールを検討し始めました。以前のGitツールからGitLabへの移行は苦痛なく、GitLabへの移行の結果としてコラボレーションとリリースペースの即座の改善が見られました。

BIWのCPD内の開発、QA、UX、DevOpsチームは2017年からGitLabを使用しています。2018年6月には、追加の開発グループがGitLabイシューですべての機能、ストーリー、要件、ユースケースを簡単に追跡できるように移行を開始しました。次の目標は、継続的なバグトラッキングを含め、将来の機能開発リクエストとディスカッションのコラボレーションハブとしてGitLabを複数の新しい内部チームに拡大することです。

「GitLabは現在Rancherクラスター上で実行されており、AWS Aurora Postgres + Elasticsearchを使用して実行しています。そして最近、マイクロサービス用の（別の）RancherクラスターからAmazon EKSに移行し、WebアプリケーションもCloudFrontにプッシュしています」とDehnel氏は説明します。「このデプロイはすべてGLパイプラインから実行されています。私たちは継続的デリバリーの一部のアプリケーションで、しっかりとしたCIワークフローにいます。2020年に向けて、すべてのマイクロサービスとマイクロエクスペリエンスの継続的デプロイに向けて推進し始めています。この移行をより少ない作業でより一貫性のあるものにするために、GitLab Kubernetesインテグレーションと機能強化を活用したいと考えています。」

同社は最近、AWSでインストールを実行している人のために、レガシーモノリスインストールをスキャン（最初はSAST + 依存関係、ただしまもなくDAST機能も使用予定）してデプロイするためにGitLabパイプラインを使用し始めました。このセットアップとGitLabパイプラインで実行されているマイクロサービスの間で、SAST/依存関係スキャンの最初の4日間でチームは300回以上のスキャンを実行しました。このスキャンにより、チームは以前特定されていなかった脆弱性を特定し、今後の状況を修正することができました。GitLabのパイプラインにより、レガシーかモダナイズされたかに関係なく、全員がアプリケーションスキャンとデプロイに同じツールを使用できます。

Dehnel氏は、まだいくつかの従来の方法を使用していることを認めていますが、現在では元のGit以前のペースである9〜12か月ごとのリリースから、ほぼ毎日リリースを経験するチームがあります。BIWはGitLabパイプラインを使用してレガシーモノリスをAWSにデプロイしています。それらのパイプライン内で、自動化されたインフラストラクチャプロビジョニング、Infrastructure as Code、自動化されたセキュリティテスト、アプリケーションデプロイを実行しています。

同社にとっての究極の成果は、Corporate Product Development Teamが全員同じ場所で作業していることです。運用インフラストラクチャチームは現在、同じプラットフォームから作業し、ソフトウェア開発ライフサイクルに同じ製品を使用しています。チームは、もはやツールのデイジーチェーンを回避するのではなく、すべての自動化ツールを同じ場所にプッシュしています。