社内開発者ポータルを活用したインナーソースの推進と技術的課題の解決
888 Views
August 23, 24
スライド概要
CEDEC 2024
https://cedec.cesa.or.jp/2024/session/detail/s6609d4c7012c9/
Microsoft MVP for Microsoft Azure
関連スライド
各ページのテキスト
CEDEC 2024 社内開発者ポータルを活用したインナーソースの推進と技術的課題の解決 株式会社バンダイナムコスタジオ 技術スタジオ 第3グループ オンラインテクノロジー部 サーバソリューションユニット DXセクション 八重樫 剛史 Takeshi Yaegashi 2024年08月23日(金)
自己紹介 • 八重樫 剛史 Takeshi Yaegashi • 株式会社バンダイナムコスタジオ (BNS) 技術スタジオ 第3グループ オンラインテクノロジー部 サーバソリューションユニット DXセクション テクニカルディレクター • 社内開発者向けのクラウドサービス導入推進 プラットフォームエンジニアリングのプロジェクトに従事 • Microsoft MVP for Microsoft Azure (2023, 2024) https://mvp.microsoft.com/ja-jp/PublicProfile/5005134 • Web (blog) X (Twitter) GitHub https://l0w.dev https://x.com/hogegashi https://github.com/yaegashi 2
本日のキーワード • インナーソース (InnerSource) • オープンソースの開発手法・カルチャーを組織内のプロプライエタリなソフトウェア開発で実践する取り組み • 社内のサイロを壊し、コラボレーションを加速して、車輪の再発明を防ぐ • 社内開発者ポータル (Internal Developer Portal, IDP) • 開発者の目的を達成するための最短経路 (ゴールデンパス) となる情報や機能を提供する社内のポータルサイト • Backstageのような本格的IDPフレームワークが存在するが、単純な情報共有Wikiサイトも立派なIDPである • プラットフォームエンジニアリング • 開発者の目的を達成するためのセルフサービス機能を実現するプラットフォームを設計・構築する技術領域 • プラットフォームエンジニアリングの多くはIDPの構築を伴う • プラットフォームを成功させるための組織設計論も含む: チームトポロジー [1] など 共通するコンテキスト → ソフトウェア開発における開発者体験 (DevEX)・生産性の向上 [1] https://pub.jmam.co.jp/book/b593881.html 3
ガートナー ソフトウェア・エンジニアリングのハイプ・サイクル 2023年 [1] 本日のキーワード • インナーソース • 社内開発者ポータル • プラットフォームエンジニアリング すべてがガートナーのハイプ・サイクル [2] に捕捉されており、今後ソフトウェア 開発の主流になりうる技術として注目され ていることを示す [1] https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20231204 [2] https://www.gartner.co.jp/ja/research/methodologies/gartner-hype-cycle 4
日本国内のエンジニアリングコミュニティの動向 • 今夏 Platform Engineering Kaigi 2024 [1] および InnerSource Gathering Tokyo 2024 [2] が相次いで開催 • 「プラットフォームエンジニアリング」「インナーソース」が互いに関連する技術領域として認識されつつある [1] https://www.cnia.io/pek2024/ [2] https://gatherings.innersourcecommons.org/tokyo-2024/ 5
本日のトピック • バンダイナムコスタジオのプラットフォームエンジニアリング • インナーソースのトレンドと推進コミュニティ • インナーソースのプラットフォームエンジニアリング 6
バンダイナムコスタジオのプラットフォームエンジニアリング
バンダイナムコスタジオのプラットフォームエンジニアリング + α • Bandai Namco DX Cloud Studios • DX = Digital Transformation (デジタル変革)、Devloper Experience (開発者体験) • コロナ禍をきっかけに始まった「クラウド上のゲーム開発スタジオ」を構築しようという取り組み • 開発者を顧客とする開発・テスト環境の提供にフォーカス • 例: GPU搭載VMによる仮想デスクトップやゲームアプリビルドのCI/CD環境などを提供する • Bandai Namco EX Cloud Project • EX = Existing (既存)・Extended (拡張)・Expanded (発展) • バンダイナムコグループで眠っている既存のクラウドサービス・サブスクリプションを最大限に活用する取り組み • 社内外のシステム管理者やステークホルダーと協力して DX Cloud Studios を実現する基盤を構築する • 例: Microsoft 365 E3 (バンダイナムコグループのほぼすべての従業員が所有) • 例: Visual Studio Professional with GitHub Enterprise (ゲーム開発エンジニアの大半が所有) 8
Bandai Namco DX Cloud Studios (2022) • CEDEC 2022「DX(開発者体験)の向上を目指すゲーム開発インフラの進化とDX(デジタル変革)」 • コロナ禍の在宅勤務の開始をきっかけとしてAzureでクラウド上のゲーム開発スタジオ構築を目指す • 新人研修ゲーム開発プロジェクトなどで活用実績を残したが、ほぼワンオペであったため規模拡大できず [1] https://cedec.cesa.or.jp/2022/session/detail/184 9
Bandai Namco DX Cloud Studios (2023) • CEDEC 2023「ゲーム開発インフラのDXを推進するCCoEとプラットフォームエンジニアリング」 • 自動化と運用体制の不備を反省してプロジェクトをリブート • 高度なセルフサービスが可能で実用的なクラウドインフラプラットフォームの構築 • Cloud Studio ＝ クラウドインフラ本体 → Azure Cloud Adoption Framework のベストプラクティスの参照と Infrastructure-as-Code (ARM/Bicep) の徹底 • Async Job Excecutor = 汎用タスクランナー → Cloud Studio をターゲットとした様々な管理自動化タスクの実行基盤 • Web App/API = クラウドインフラ管理ポータル → 開発者がセルフサービスで利用できる UI/UX により運用者の負荷を減らす Web App Static Web App Web API [1] https://cedec.cesa.or.jp/2023/session/detail/s642a0ffc4b8d7.html VM AVD Disk App Services Async Job Executor Users Automation Apps Cloud Studio (ARM) Database Azure Pipelines GitHub Actions AKS/ACI/ACA 10
DX Cloud Async Job Executor (汎用タスクランナー) • ユーザーがセルフサービスで様々な自動化タスクを実行できるシステム基盤を開発 • Web AppはAzure PaaSで実装、認証・認可にMicrosoft Entra IDを使用することで全従業員が利用可能 • タスク実行のバックエンドはGitHub Actions、Web AppがAPIで起動するためユーザーのGitHubアカウントは不要 • 2024/08/09 GitHub Actions Meetup Tokyo #4 「プラットフォームエンジニアリングのためのセルフサービス基盤の実装」 [1] [1] https://gaugt.connpass.com/event/324715/ 11
DX Cloud Web App (開発中の画面) • 開発用仮想マシンの作成・削除・メンテナンス、RDP接続などの操作がセルフサービスでできる • Microsoft Dev Box よりも多機能、 Azure Portal よりもシンプルで、かゆいところに手が届く使いやすいアプリを目指す 12
DX Cloud クラウドPC (Windows 11 Enterprise) • Microsoft 365 や社内サーバが利用可能な Windows 11 Enterprise デスクトップ • Azure Virtual Desktop によりWebブラウザやアプリ (PC・スマートフォン・タブレット) で接続可能 • Microsoft Intune「ポータルサイト」アプリでデバイス管理やアプリ自動インストールがセルフサービスで実施可能 13
DX Cloud Async Job Web App: ジョブ実行 (開発中の画面) • ユーザーはasyncjobリポジトリのYAMLで定義されたジョブを選択し、入力パラメータを指定して実行できる 14
DX Cloud Async Job Web App: ジョブ履歴 (開発中の画面) • ジョブを実行した履歴を確認できる ジョブ完了時にメールによる結果通知も行われる 15
DX Cloud Async Job Web App: ログ表示 (開発中の画面) • ジョブの実行ログを確認できる 現時点では実行完了したジョブのみ 16
参考: Microsoft Azure プラットフォームエンジニアリングアーキテクチャ • Microsoft Learn「開発者向けセルフサービス基盤を設計する」[1] • DX Cloud Async Job Executor の設計はこのドキュメントのリファレンスアーキテクチャとかなり似ている (偶然) • インナーソースや Backstage にも言及されている [1] https://learn.microsoft.com/ja-jp/platform-engineering/developer-self-service 17
Bandai Namco DX Cloud Studios (2024) • DX Cloud Studios 開発・展開のロードマップ • 2024/06 アルファテスト開始 → 限られた従業員を対象にして必要な機能の実装とテスト • 2024/10 ベータテスト開始予定 → より多くの従業員によるテスト、負荷対策、コスト集計機能実装 • 2025/01 正式サービス開始予定 → サービス運用チームを発足させる • 当面の目標 • 従業員が完全なセルフサービスで自分専用の開発環境となるクラウドPCを作ったり壊したりできるようにする → Windows 11 の Dev Home [1] を活用して Configuration-as-Code・使い捨て可能な開発環境を実現する → Linux コンテナにはかなわないが、10〜20分程度のサイクルでWindowsデスクトップを作ったり消したりできたら… • Microsoft Intune/Entra Join/SSE対応により既存のMicrosoft 365や社内のリソースが利用できるクラウドPCを実現する → Bandai Namco EX Cloud Project (後述) [1] https://learn.microsoft.com/ja-jp/windows/dev-home/ 18
バンダイナムコスタジオのプラットフォームエンジニアリング + α (再掲) • Bandai Namco DX Cloud Studios • DX = Digital Transformation (デジタル変革)、Devloper Experience (開発者体験) • コロナ禍をきっかけに始まった「クラウド上のゲーム開発スタジオ」を構築しようという取り組み • 開発者を顧客とする開発・テスト環境の提供にフォーカス • 例: GPU搭載VMによる仮想デスクトップやゲームアプリビルドのCI/CD環境などを提供する • Bandai Namco EX Cloud Project • EX = Existing (既存)・Extended (拡張)・Expanded (発展) • バンダイナムコグループで眠っている既存のクラウドサービス・サブスクリプションを最大限に活用する取り組み • 社内外のシステム管理者やステークホルダーと協力して DX Cloud Studios を実現する基盤を構築する • 例: Microsoft 365 E3 (バンダイナムコグループのほぼすべての従業員が所有) • 例: Visual Studio Professional with GitHub Enterprise (ゲーム開発エンジニアの大半が所有) 19
バンダイナムコスタジオとバンダイナムコグループ関連組織紹介 [1] • ビジネスユニット・事業会社 • 各ビジネスユニット・事業ごとに主幹会社 (BNE・BNAM・etc.) と多数の子会社(BNS・BNKEN・BBST・BNO・BNAL・etc.) が存在する • バンダイナムコスタジオ (BNS) はエンターテインメントユニット・デジタル事業に属する事業会社のひとつにすぎない • シェアードサービス会社 • 各事業会社が必要とする総務・人事・経理・財務・ITシステムなどの共通業務を集約 • バンダイナムコビジネスアーク (BNBA) 情報システム部が 10,000人以上の従業員が利用する基幹ITインフラを統括する (Active Directory, Microsoft 365, etc.) バンダイナムコ エンターテインメント (BNE) バンダイナムコ アミューズメント (BNAM) バンダイナムコ スタジオ (BNS) バンダイナムコ オンライン (BNO) バンダイナムコ研究所 (BNKEN) B. B. スタジオ (BBST) バンダイナムコ アミューズメントラボ (BNAL) バンダイナムコ ビジネスアーク (BNBA) [1] https://www.bandainamco.co.jp/group/ 20
Bandai Namco EX Cloud Project におけるバンダイナムコグループ基幹ITインフラの最適化 • バンダイナムコグループの基幹ITインフラを統括するBNBAと深く連携 • DX Cloud Studiosを推進するBNSにとって利用価値が高いが眠っているMicrosoft 365やMicrosoft Entraの機能を発掘 • BNSに基幹ITインフラ管理権限はないため、常にBNBAに対する依頼・提案により機能を有効化していく • Microsoft 365 E3 (全従業員) • Windows 11 Enterprise: クラウドPCサービス利用権 (Azure Virtual Desktop, Microsoft Dev Box, Windows 365) • Microsoft Intune (MDM): クラウドPC Windowsデバイス遠隔管理・セキュリティ対策・ソフトウェア配信 • Microsoft Security Service Edge: クラウドPCから社内Confluenceやファイルサーバなどへのゼロトラストアクセス • Visual Studio Subscription with GitHub Enterprise (エンジニア) • GitHub Enterprise Managed Users: Microsoft Entra IDからGitHub Enterpirseユーザー・チームをプロビジョニング(SCIM) • インナーソースの基盤となる共同開発プラットフォームとして Azure DevOps と共に整備 21
エンタープライズ (大企業) IT インフラ更新の困難を乗り越える努力 • エンタープライズにありがちなITインフラのアジリティ不足 • 前例のない機能利用や設定変更の要望を通すことが難しい • バンダイナムコグループのMicrosoft Entra IDはユーザーが1万人を超える巨 大なテナントであり保守的になることはやむを得ない • 対話と根回し • ステークホルダーを味方につけ時間をかけて説明し調整する努力が必要 • 自社の上位役職者に説明し、事業会社(BNS)としての正式な要望をITインフ ラ管理会社(BNBA)に申し入れしてもらう • クラウドベンダやSI担当企業からも支援を得る • 自分事とする姿勢を見せる • 要望した事柄を他人事とせず、自分でも十分に研究・検証して担当者に やってもらうべきオペレーションやリスク対処を一緒に考える • Microsoft 365 開発者プログラム [1] 実験用 Microsoft 365 サブスクリプション / Microsoft Entra ID テナント • 信頼関係が得られれば、アジリティはだんだん向上していく [1] https://developer.microsoft.com/ja-jp/microsoft-365/dev-program 22
バンダイナムコスタジオのプラットフォームエンジニアリング まとめ • Bandai Namco DX Cloud Studios • コロナ禍以降継続してきた「クラウド上のゲーム開発スタジオ」構築の取り組みを紹介 • GitHub Actions をバックエンドとする開発者のセルフサービス基盤の実装が完了 • 現在はアルファテスト段階であり本格的な採用実績はまだこれから、社内マーケティングが必要 • Windows Dev Home の活用で Configuration-as-Code と使い捨てできるクラウドPC環境のパラダイム実現を目指す • Bandai Namco EX Cloud Project • バンダイナムコグループの組織と既存クラウドリソース活用・発展の推進戦略を紹介 • 自ら手を動かして学び、社内システム管理部門だけでなく社外ベンダ・SIerも巻き込み推進することの重要性を強調 • Microsoft Intune や Microsoft SSE の評価・導入に目処がつき DX Cloud Studios の開発が加速する見込み • 今後のさらなる発展にご期待ください！ 23
インナーソースのトレンドと推進コミュニティ
インナーソースの紹介 • インナーソース (InnerSource) • オープンソースの開発手法・カルチャーを組織内のプロプライエタリなソフトウェア開発で実践する取り組み • 社内のサイロを壊し、コラボレーションを加速して、車輪の再発明を防ぐ • おすすめの講演資料:インナーソースで始める組織内オープンソース開発入門 [1] 1-2 InnerSource とは︖ 1-2 InnerSource で⽬指す姿 ● InnerSource は、企業内のソフトウェア開発にオープンソースの実践と ベストプラクティスと原則を適⽤したものです。 ● InnerSource ソフトウェアは、会社としてはプロプライエタリなものとなりますが、 内部にはオープンで、誰もが利⽤したり貢献したりできるようになります。 つまり ・・・ 今まで ⽬指す姿 サイロごとに閉じている 何をしているか⾃部⾨以外のことは知らない サイロを取り払い、コラボレーションが各所で発⽣︕ Open all artifacts! Welcome visitors! ・・・ を企業内で実践することです。 Dirk Riehle, Inner Source (Software Development), InnerSource Summit 2018 InnerSource Commons Japan [1] https://speakerdeck.com/yuhattor/innersource-learning-path-japanese https://www.youtube.com/watch?v=wL-SkKR1eZg [ 10 InnerSource Commons Japan 25 11
インナーソースのベネフィット • ソフトウェアの再利用の促進、車輪の再発明の防止 • 開発の透明性の向上 • 開発者とユーザーのやり取りのオーバーヘッド、摩擦の削減 • 開発者のコラボレーション、人材交流の促進 • 学習・研究用コードベースの構築 • プラクティスの標準化 • ナレッジベースの蓄積 • AIモデルのファインチューニングの材料 26
インナーソースの実践 • インナーソースを実践できるプラットフォーム: 企業・組織内のソフトウェア共同開発プラットフォーム • 共同開発プラットフォーム = Collaborative Development Platform, CDP • CDPの例: GitHub, GitLab, Azure DevOps, Bitbucket, Helix Swarm, etc. • コードリポジトリだけでなく、イシュー管理、プルリクエスト、CI/CDなどの 機能を備えるCDPを活用した、組織を横断するコラボレーションによる開発 • 「実はうちの会社もインナーソースできているのでは？」 • 「インナーソース」という用語を特に意識することなく、 CDPを活用してそれに近いことを実践してきた企業・組織はたくさんある バンダイナムコグループも例外ではない • 2024/08/08 開催 InnerSource Gathering Tokyo 2024 では 日本の企業・組織のインナーソース実践事例が多数共有された 27
インナーソースの関連技術・サービス・団体の歴史 年 できごと 1990 CVS 1994 Visual SourceSafe (Microsoft) 1995 Perforce (Perforce) 1998 "Open Source" という用語が定義される (Open Source Initiative) 1999 SourceForge.net サービス開始 2000 "Inner Source" という用語が初めて使われる (Tim O'Reilly) 2000 Subversion (CollabNet) 2005 Git (Linus Torvalds) 2006 Team Foundation Server (Microsoft) 2008 GitHub.com サービス開始 2011 GitLab.com サービス開始 2013 Visual Studio Online (現 Azure DevOps Services) サービス開始 2015 InnerSource Commons 設立 28
「インナーソース」という用語の成り立ちと表記方法 • "Inner Source" (2語) • 2000年に Tim O'Reilly が CollabNet を紹介する文脈で初めて使用した言葉 • CollabNet は Subversion のオリジナルの開発元 • 無料の書籍「Adopting InnerSource」で経緯が説明されている [1] • "InnerSource" (CamelCase 1語) • 検索性および商標の都合からこの表記が推奨されている • "Open Source" (2語) は一般語の並びであるため商標登録ができなかった [2] [1] https://innersourcecommons.org/ja/learn/books/adopting-innersource-principles-and-case-studies/ [2] https://github.com/jeffabailey/InnerSourcePatterns/blob/main/meta/innersource-spelling.md 29
インナーソース推進団体とコミュニティ • InnerSource Commons [1] • 2015年に設立されたインナーソースを推進する非営利団体 • 750の組織から3000人が参加するグローバルなコミュニティを擁する • InnerSource Commons Japan [2] • InnerSourceの価値基準を考える会 (全3回) → 日本企業でインナーソースの普及を図るための企画会議 • 2024/08/08 InnerSource Gatherning Tokyo 2024 → 日本のインナーソース実践企業による事例紹介 → インナーソース推進ソング「共創未来インナーソースマン」 [1] https://innersourcecommons.org/ [2] https://innersourcecommons.connpass.com/ 30
InnerSource Gathering Tokyo 2024 リフレッシュ！お楽しみ企画 [1] 共創未来インナーソースマン feat. InnerSource Commons コミュニティ [2] もし自分の作った組織の皆に使って欲しいレポジトリがあれば、 思い切って社内に公開してみませんか？README.mdと CONTRIBUTING.mdを書くところからはじめてみましょう。組織 の人からのフィードバックは小さなものでも嬉しいはずです。 InnerSource Commonsコミュニティメンバーがインナーソースの 第一歩を踏み出すための歌詞を作成し、それをKDDIアジャイル 開発センターの社員部活動「音KAG部」がうたにしました。 インナーソースとは、オープンソースのコンセプトと学びを、 企業が社内でソフトウェア開発に適用する試みです。 [1] https://speakerdeck.com/piyonakajima/reflesh-the-fun-project-innersource-gathering-tokyo-2024 [2] https://www.youtube.com/watch?v=8NOh_-iFLYc 31
共創未来インナーソースマン feat. InnerSource Commons コミュニティ 32
共創未来インナーソースマン 解説 • 「InnerSourceの歌を作ったら社内で俺の作ったレポジトリにPull Requestが飛んできた話」 [1] • インナーソースの成功のために重要なカルチャーや原則、ベストプラクティスを教えてくれる [1] https://speakerdeck.com/piyonakajima/reflesh-the-fun-project-innersource-gathering-tokyo-2024 [2] https://note.com/piyonakajima/n/nede085b85f9a 33
企業・組織でインナーソースを始めるためのガイド • インナーソースで始める組織内オープンソース開発入門 [1] • インナーソースの解説、文化原則・メリット・役割・実践手法など • 参加者全員にまず読んでもらうのに最適な資料 • インナーソースパターンブック [2] • 様々な組織で実績のあるベストプラクティスのパターン集 • 後述する「インナーソースポータル」パターンが存在する • GitHubを使用してInnerSourceプログラムを管理する [3] • Microsoft Learn のモジュール • GitHubに特化した推奨設定、リポジトリ構成のわかりやすい解説 • Managing InnerSource Projects [4] (英語) • 共同開発プラットフォームのインフラ構築や効果測定について論じる [1] https://speakerdeck.com/yuhattor/innersource-learning-path-japanese https://www.youtube.com/watch?v=wL-SkKR1eZg [2] https://innersourcecommons.org/ja/learn/books/innersource-patterns/ [3] https://learn.microsoft.com/ja-jp/training/modules/manage-innersource-program-github/ [4] https://innersourcecommons.org/learn/books/managing-innersource-projects/ 34
- https://speakerdeck.com/yuhattor/innersource-learning-path-japanese
- https://www.youtube.com/watch?v=wL-SkKR1eZg
- https://innersourcecommons.org/ja/learn/books/innersource-patterns/
- https://learn.microsoft.com/ja-jp/training/modules/manage-innersource-program-github/
- https://innersourcecommons.org/learn/books/managing-innersource-projects/
インナーソースのトレンドと推進コミュニティ まとめ • インナーソースの歴史と最新のトレンド、推進コミュニティの活動を紹介 • ガートナー ハイプサイクルでもトラッキングされる注目技術 • 日本のコミュニティの活動により日本語の情報・事例も充実してきている • 日本語の講演・解説資料・書籍の蓄積 • 多数の日本の企業・組織によるインナーソース導入の実績 • インナーソース推進ソングなど日本独自のコミュニティ活動 • InnerSource Gathering Tokyo 2024 イベントおよびセッションの録画・レポートに注目 • みなさんもぜひ自分の組織でインナーソースを始めてみてください！ 35
インナーソースのプラットフォームエンジニアリング
インナーソースの効果を最大化するプラットフォームエンジニアリング • インナーソースを実践できるプラットフォーム: 企業・組織内のソフトウェア共同開発プラットフォーム • 共同開発プラットフォーム = Collaborative Development Platform, CDP • CDPの例: GitHub, GitLab, Azure DevOps, Bitbucket, Helix Swarm, etc. • コードリポジトリだけでなく、イシュー管理、プルリクエスト、CI/CDなどの 機能を備えるCDPを活用した、組織を横断するコラボレーションによる開発 • インナーソースの効果を最大化するCDP構築 • 参加者を適切なIDで認証し、適切なアクセスの認可ができる → クローズドなソフトウェア資産を扱うため厳密なアクセス権限管理が必要 • 多数のプロジェクトの多数のステークホルダーが同時に参加できる → インナーソースは参加者の数が多ければ成功の可能性が高まる → エンジニアだけでなく単なる利用者も含め全員参加できることが望ましい • CDP構築のプラットフォームエンジニアリング • 企業・組織が大規模であるほど、インナーソースの効果を最大化するCDPの構 築は難しくなり、緩和策・妥協策が必要になる • プラットフォームエンジニアリング事例の多くはCDPを所与のものとしている が、インナーソースの文脈では無視することはできない 37
大規模エンタープライズにおけるインナーソースのプラットフォームの課題 ① • 理想 → 参加者全員が単一の共同開発プラットフォーム(GitHubなど)でインナーソースを推進 • 現実 → 参加者全員が利用できる共同開発プラットフォームがなくインナーソースを推進できない • 多くの組織で共同開発プラットフォームの分断が発生している • 特に利用料金がネックとなり、特定のプロジェクトや特定の職種のユーザー以外にアクセス権限が与えられないことが多い • 大規模エンタープライズではその規模と歴史的経緯から開発者プラットフォームが乱立しがち • 一部のユーザーしかアクセスできない共同開発プラットフォームは利用を敬遠されてしまう [Source] https://twitter.com/hogegashi/status/1798468330111857093 38
大規模エンタープライズにおけるインナーソースのプラットフォームの課題 ② • 大規模なエンタープライズに特有の多層化したインナーソースのスコープ • ソフトウェア資産ごとに公開範囲が限定される「エンタープライズ全体」「A会社のみ」「Aプロジェクトのみ」 • 多くエンタープライズではMicrosoft Entra IDなどで組織を反映したグループ階層を定義しているのでそれを活用する A会社 A事業部 A部 A課 B課 B会社 B事業部 C事業部 D事業部 B部 C部 D部 E部 C課 D課 E課 F課 Aプロ ジェクト Bプロ ジェクト Cプロ ジェクト 39
大規模エンタープライズにおけるインナーソースのプラットフォームの課題の緩和・妥協策 • 全ユーザーが参加できるインナーソースポータルの構築 • いわゆる内部開発者ポータル Internal Developer Portal (IDP)の追加により問題を緩和・妥協するアプローチ • ポータルはユーザーの数に関係なく低コストで運用可能なものを使用する • ポータルは組織内の共同開発プラットフォームにアクセスしてソフトウェアカタログを構築する • ユーザーが組織内のインナーソースプロジェクトを発見するための新たなビューを提供する 40
インナーソースパターン: インナーソースポータル • 「インナーソースパターンブック」にもインナー ソースポータルのアプローチの記載がある [1] • インナーソースポータルは組織内に存在するインナーソー スプロジェクトのインデックスを提供する • 組織内の潜在的なコントリビューターが貢献可能なイン ナーソースプロジェクトの存在を知るきっかけとなる • インナーソースポータルの参考実装としてSAPのWebアプリ 「Project Portal for InnerSource」が紹介されている [2] [1] https://patterns.innersourcecommons.org/v/ja/toc [2] https://github.com/SAP/project-portal-for-innersource 41
Managing InnerSource Projects: InnerSource Catalogs as an InnerSource Dedicated Environment • 「Managing InnerSource Projects」でGitHubの 「InnerSource Dedicated Environment」として 「InnerSource Catalogs」が提案されている [1] • インナーソースカタログのアプローチ • 定義: 可視性を高めたいリポジトリが、収集の目印とな るタグを自分につけて、インナーソースカタログに収 集される。 • 利点: 再利用を希望するリポジトリが一箇所に集まるの で、インナーソースの発見や効果測定が容易になる。 • 欠点: 多くの開発者は積極的に業務を離れてカタログ探 究に時間を割こうとはしない。また「カタログに含ま れる = インナーソース」という誤解が生じるリスクが ある。 [1] https://innersourcecommons.gitbook.io/managing-innersource-projects/innersource-tooling/github-strategy 42
大規模エンタープライズにおけるインナーソースポータルの要件 • 低コストで運用可能 • ユーザーの数に応じた追加ライセンスコストが発生しないことが望ましい • 組織内の全従業員をカバーできるID基盤に対応 • 開発者・利用者を問わず、潜在的なステークホルダーの全員参加を可能にしたい • ポータル利用にまつわる手続き的・心理的な障害を可能なかぎりなくす → ユーザーが普段使用するクラウドサービス(Microsoft 365など)と同じ既存ID基盤でSSOできるようにする → 新規ID基盤導入はアンチパターン: 多くの場合、ユーザーは新しいIDを使うのが面倒で足が遠のいてしまう • 組織内の多様な共同開発プラットフォーム(CDP: GitHub, GitLab, Azure DevOpsなど)との連携 • CDPはポータルを特別なユーザー・アプリとしてアクセスを許可する (GitHub App などを利用) • ポータルはユーザーに代わってCDP内を探索しインナーソースプロジェクトカタログを作成する • 詳細なアクセス制御手段 • エンタープライズ内の一部の組織・ユーザーにのみに公開したいという要件に対応する • ユーザーに負担のないポータル更新手段の提供 • 例1: リポジトリに設定するトピック・タグによりカタログへの記載・不記載をコントロールできる • 例2: リポジトリ内の特定のファイル (README.mdやcatalog-info.yamlなど) が自動的にカタログに記載される 43
大規模エンタープライズにおけるインナーソースポータルの Backstage による実装 公式サイト https://backstage.io デモサイト https://demo.backstage.io Spotifyが開発した「開発者ポータル構築フレームワーク」 2020年3月 Cloud Native Computing Foundation (CNCF) に寄贈されたオープンソースプロジェクトとなる 柔軟性の高いプラグインアーキテクチャにより高度な拡張・ カスタマイズが可能 → 大規模エンタープライズのインナーソースポータルの要件 を満たすことができる 44
Backstage の基本機能 • Core Features • Software Catalog → ソフトウェアだけでなくグループやユーザーの情報(Entity)をIntegrationsを通じて取得する • TechDocs → mkdocs形式の文書を閲覧可能にする • インナーソースポータル構築に必要な機能が最初から備わっている • Integrations • AWS S3・Azure DevOps・Bitbucket・Datadog・Gerrit・GitHub・GitLab・Gitea・Google GCS・LDAP • さまざまな開発者プラットフォームやデータソースに対するデータ取得手段を提供する • Authentication • Auth0・Atlassian・Microsoft・Bitbucket・Cloudflare・GitHub・GitLab・Google・Okta・OneLogin・VMware • Azure Easy Auth・Google IAP・OAuth2 Proxy のようなプロキシ型の認証にも対応している • Backstageのユーザー認証結果からユーザーEntityへのマッピングを行う (sign-in resolver) • Permission • BackstageにサインインしたユーザーによるEntity操作の可否を試行の都度判定する • 認可判定のコードを統一できる Permission Framework を備える 45
Backstage Software Catalog: 組織のグループ・ユーザー情報 (Entity) 収集と認証統合 • Microsoft Entra ID や GitHub Enterprise など複数のデータソースから組織のグループ・ユーザー情報 (Entity) を収集 • ユーザー認証結果から対応するユーザー Entity の解決 (sign-in resolver) 46
Backstage Software Catalog: プロジェクト登録 • リポジトリのトップの catalog-info.yaml ファイルに情報を記載すると定期的に Backstage が収集・登録してくれる • 検索しやすくするために適切な metadata を設定し spec.owner でプロジェクトオーナーの連絡先を明示する apiVersion: backstage.io/v1alpha1 kind: Component metadata: name: 876-devstage title: Bandai Namco DevStage DevOps description: Bandai Namco DevStage DevOps tags: - backstage - devops - azure-container-apps - azure-developer-cli annotations: github.com/project-slug: AAAAAAAA/876-devstage backstage.io/techdocs-ref: dir:. links: - url: https://devstage.sites.local title: DevStage (production) icon: dashboard type: production - url: https://devstagedev.sites.local title: DevStage (development) icon: dashboard type: development spec: type: website owner: user:me/ZZZZZZZZ.bandainamco.co.jp 47
Backstage TechDocs: プロジェクトドキュメント生成 • リポジトリに含まれる MkDocs 形式[1]のドキュメントをインナーソースポータル内で表示 • catalog-info.yaml の anotation.backstage.io/techdocs-ref で指定した場所の mkdocs.yml ファイルを読み込む site_name: DevOps for Backstage on Azure Container Apps plugins: - techdocs-core nav: - Introduction: index.md - Local development: local_development.md - Azure deployment: azure_deployment.md - Architecture: architecture.md - How to contribute: contributing.md [1] https://www.mkdocs.org/ 48
バンダイナムコグループ向けインナーソースポータルの Backstage による実装の概要 • Backstage Web App DevOps • Azure Container Apps によるクラウドネイティブな実装と運用 • 様々なデータソースからユーザー・グループカタログを生成 • Microsoft Entra ID (ME-ID) ユーザー・グループ情報 (ほぼ全従業員をカバーする) • GitHub Enterprise ユーザー・チーム情報 (エンジニアのみ) • オンプレミス Active Directory ユーザー・グループ情報 (対応予定) • 様々な開発者プラットフォームからプロジェクトカタログを生成 • GitHub Enterprise Cloud (指定のGitHub AppをインストールしたOrg/Repoが対象) • Azure DevOps Services (指定のME-IDサービスプリンシパルをアクセス許可したOrg/Repoが対象) • オンプレミスGitLab (対応予定) • 厳密なアクセスコントロールの実現 (計画中) • GitHubリリースノート・アセットダウンロードの提供 • TechDocs (MkDocs github-release-assets plugin) 49
Backstage Web App DevOps • dx2devops-backstage-containerapp [1] • Backstage を Azure Container Apps でクラウドネイティブに運用するためのプロジェクト • Bicep および Azure Developer CLI による IaC を徹底し将来的には SaaS 化した Backstage の実現を目指す [1] https://github.com/yaegashi/dx2devops-backstage-containerapp 50
Microsoft Entra ID (ME-ID) からのユーザー・グループカタログ生成 • 基本的な方針 • Microsoft Graph PowerShellスクリプトでME-IDからUser/Groupカタログファイルを生成しGitHubリポジトリに格納 • Backstageサイトごとにapp-config.yamlのlocationsにより必要なカタログファイルをGitHubリポジトリから読み取る • 他のデータソースと重ならないように名前空間を分ける • BackstageのmicrosoftGraphOrg Integrationを使わず、自作スクリプトでカタログ生成する理由 • ME-ID管理者権限がないためBackstageにUser.Read.Allのような強い権限を与えるアプリ登録が作れない • BackstageからMicrosoft Graphの直接アクセスがなくなるためセキュリティが向上し負荷対策にもなる • スクリプトの作成は大して難易度が高くなくカタログ記載内容に大きな柔軟性が得られる • オンプレミスADのようなクラウドから直接アクセスできない情報ソースの統合にも応用できる 51
Microsoft Entra ID (ME-ID) から生成したユーザー・グループカタログYAMLの例 apiVersion: backstage.io/v1alpha1 kind: User metadata: namespace: me name: ZZZZZZZZ.bandainamco.co.jp title: 八重樫 剛史 Takeshi Yaegashi description: テクニカルディレクター annotations: graph.microsoft.com/user-type: Member microsoft.com/email: [email protected] graph.microsoft.com/user-job-title: テクニカルディレクター graph.microsoft.com/user-id: 759b0071-ba18-4cc1-9a88-ff1b90a35c82 graph.microsoft.com/user-sam-account-name: yaegashi graph.microsoft.com/user-principal-name: [email protected] spec: profile: email: [email protected] displayName: 八重樫 剛史 Takeshi Yaegashi memberOf: - 938f6261-cad8-42dc-bb28-357f2c3ab465 apiVersion: backstage.io/v1alpha1 kind: Group metadata: namespace: me name: 938f6261-cad8-42dc-bb28-357f2c3ab465 title: ＤＸセクション annotations: microsoft.com/email: [email protected] graph.microsoft.com/group-id: 938f6261-cad8-42dc-bb28-357f2c3ab465 spec: profile: email: [email protected] displayName: BNS-技術スタジオ第３グループオンラインテクノロジー部サーバーソ リューションユニットＤＸセクション type: business-unit parent: 23a88184-a126-47b8-8885-303e7b276f6f children: [] 52
柔軟なアクセスコントロールの実現 (計画中) • インナーソースポータル内でプロジェクトの公開範囲を設定できる機能 • 大規模エンタープライズでは一般的な要件 • Entity の効率的な可視性判定が可能な Backstage Permission Policy を開発中 • カスタムの sign-in resolver によりユーザーが所属する推移的なグループのリストを作って claims に追加する [1] • spec.visibleTo でその entity が「見える」ユーザーやグループの entityRef を指定可能にする apiVersion: backstage.io/v1alpha1 kind: Component metadata: name: 876-devstage title: Bandai Namco DevStage DevOps description: Bandai Namco DevStage DevOps tags: [...] annotations: github.com/project-slug: AAAAAAAA/876-devstage backstage.io/techdocs-ref: dir:. links: [...] spec: type: website lifecycle: experimental owner: user:me/ZZZZZZZZ.bandainamco.co.jp visibleTo: - group:me/23a88184-a126-47b8-8885-303e7b276f6f [1] https://backstage.io/docs/auth/identity-resolver/#custom-ownership-resolution 53
GitHubリポジトリ リリース情報・アセットダウンロードの提供 • GitHubリポジトリのリリース情報をBackstage TechDocsに変換するmkdocsプラグインの開発 [1] • 各リリースのMarkdownドキュメントをTechDocsで表示しアセットファイルをダウンロード可能にする • GitHubにアクセスのない非開発者のユーザーにもリリースノートと成果物を簡単に提供できるようになる → 共有開発プラットフォームの分断問題を部分的に解消 [1] https://github.com/yaegashi/mkdocs-github-release-assets-plugin 54
インナーソースのプラットフォームエンジニアリング まとめ • 大規模なエンタープライズにおけるインナーソース導入の課題 • 共同開発プラットフォーム (CDP) の分断が発生しやすい • ソフトウェア資産ごとに組織内の公開範囲設定が必要 • 課題の緩和・妥協策としてのインナーソースポータル • インナーソースポータルは社内開発者ポータル (IDP) の一種 • エンタープライズ内のCDPに散らばったインナーソースプロジェクト情報を集約する • オープンソースIDPフレームワークBackstageの紹介 • Backstageでインナーソースポータルを構築するプラットフォームエンジニアリングの実例 → Web サービスとしての DevOps 体制構築 → Microsoft Entra ID からの組織カタログの構築 → 柔軟なアクセスコントロール機能の実現 (計画中) → GitHubリリースノート・アセットダウンロードの提供 (MkDocsプラグイン開発) 55
まとめ
本日のまとめ • 3つのキーワードおよびトピックについてお話させていただきました • キーワード • インナーソース (InnerSource) • 社内開発者ポータル (Internal Developer Portal, IDP) • プラットフォームエンジニアリング • トピック • バンダイナムコスタジオのプラットフォームエンジニアリング • インナーソースのトレンドと推進コミュニティ • インナーソースのプラットフォームエンジニアリング 57
本日のまとめ • これまでのプラットフォームエンジニアリングの取り組みについて • 理想のプラットフォームを求める理論や実装が先行した状態になっており、あやうさを感じている → 「使われないプラットフォーム」を生み出すアンチパターン • バンダイナムコグループ内の宣伝やマーケティング、導入のファシリテーションにより注力していきたい • これからのDXセクション・プラットフォームチームの活動の進捗および結果については、 様々な機会をとらえて随時報告していく予定です • 今後もどうぞご期待ください！ 58
Thank You!! 59