GitLab好きのAzureユーザーに朗報！あなたのAzure OpenAIをつかって、GitLabでAIを使う方法とメリットをご紹介.pptx
- 1. 1 Tsukasa Komatsubara | tkomatsubara@gitlab.com GitLab 好きの Azure ユーザーに朗報！ あなたの Azure OpenAI をつかっ て、 GitLab で AI を使う方法と メリットをご紹介
- 2. © 2024 GitLab Inc. This presentation and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this presentation and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
- 3. 3 ● 自己紹介 ● ソフトウェア開発、サービス開発における課題 ● GitLab のご紹介 ( 一瞬だけ MCP サーバーのご紹介 ) ● GitLab の AI 機能のご紹介 ● デモ ○ 1.GitLab Duo Self-Hosted + Azure Open AI ○ 2.AI + Azure Kubernetes Service を活用した” Dev Performance Ops” と “ Dev Sec Ops” 本セッションのアジェンダ
- 4. 4 Tsukasa Komatsubara Ecosystem Senior Solutions Architect at GitLab アスキー入社後アスキーネットワークテクノロジーへ出向。マイクロソフトジャパン社の 依頼で日本語版「 Microsoft Digital Dashboard( 後の Microsoft Sharepoint Portal Server) 」開発に参加。 Outlook 用のアドオン ( セルフサービスでダッシュボードレイア ウトを作る機能 ) を担当。 VB で、約 2 万行のコードに膨れ上がる。いま思えばひどいコ ードでした。 その後、メールサーバーの開発元「 Sendmail, Inc. 」へ入社。「 Sendmail Mailstream Manager 日本語化」開発なんちゃってリーダー ( 実質はエースの A 君のお陰 ) 。 思い出深いのは、 PDF 添付ファイル攻撃 ( たぶん、これ) が世界中で大騒ぎした日の夜中 に検出モジュールを開発し、翌朝社内展開、その日に米軍需大手 Raytheon 担当チームに バトンタッチ & デモ & その日の夕方に即販売締結に結びついたこと。 linkedin.com/in/t-komatsuba twitter.com/GL_Tsukasa gitlab.com/tkomatsubara メッセージ： スーパーソフトウェアデベロッパーになってください。
- 6. 6 ボスは赤矢印で、なにかあればとっさの判断をします この体制で、敵から守り、全員が遅れないようにします 病気や高年齢のオオカミ 若く、最強の戦士 若く、最強の戦士 弱い / 子どものオオカ ミ みなさんは この「ボス」 です
- 10. 10 なぜ？
- 11. 11
- 12. 12 加えて DX 対応 / 新規機能 / セキュリティ対応 どうしますか？
- 14. 14 GitLab のご紹介
- 15. GitLab Inc. ご紹介 会社 - 2014 年法人化 - 66カ国以上にまたがる1,630名以上の従業員 - All-remote：オフィスを持たない - 毎月の製品（オンプレ）リリースと GitLab.com（ SaaS ）の提供 - 2021 年 10 月 Nasdaq 上場（ $GTLB ） 広範な普及 - 100,000以上の組織 - 3000万以上のユーザ 強固なコミュニティ - 2011 年設立 - オープンソースモデル - 3,000名以上のコードコントリビュータ
- 16. 「作るものを間違えない」ように、情報を管理・いつでも追えるように Web API 公開 User API 実装 API 方式の調査 目的、ビジネス戦略 テーマの進捗 過去経緯 表題 PM 設計資料 テスト結果 ソースコード CI/CD 実行結果 スケジュール 管理表 Operator 実装方法詳細 ソースコードの 差分 - レビュー結果 - CI/CD の成否 - 承認記録 脆弱性検出 結果 Team Leader Security Team Developer Biz Team Leader Infra Team Developer Developer 16
- 17. 単一プラットフォームによる DevSecOps ・リードタイムなしに新規プロジェクト開始 ・メンバー間での認識の同期 ・プロセス全体（工程横断）の分析レポート ・デフォルトでのセキュリティの組込み Office ツール スケジュール表 テーマ タスク タスク テーマ タスク ソース コード ビルド、テスト 自動実行 自動テスト 結果 設計資料 = SSOT 何をやるか、どうやるのかを管理しておくと、 AI 駆動開発がやりやすい 脆弱性 チケット管理 ツール Git リポジトリ CI/CD ツール Wiki ツール SAST ツール SBOM ツール DAST ツール はデータの流れ セキュリティス キャンツール群 ツール間連携による DevSecOps ・新規にプロジェクトがすぐに立ち上がらない ・メンバーごとに見える情報量の違い ・工程間を横断したプロセス分析ができない ・セキュリティ問題の手戻り、対応遅れ セキュリティ担当 PM 開発者 PM 、 ビジネスオーナ 開発者 セキュリティ担当 対 BO 用 WBS BO ：ビジネスオーナ ー
- 18. GitLab を MCP サーバーとして使うモジュールが登場 ( オフィシャルじゃないこれとかこれと か ) オフィシャル版が出る ( かも ) 時のために、 GitLab へナレッジと履歴を貯めるべき！ ロードマップ（エピック、子エピック、マイルストーン） エピック イシュー マージリクエスト ソースコードの差分 レビュー記録 マージ前の CI/CD パイプライン 承認結果 テスト結果 マージ後の CI/CD パイプライン 手動対応が必要なチ ェック項目 過去の経緯、議論 目的、背景 ビジネス戦略 進捗状況 PM Team Leader Developer
- 19. 今登場しているMCPサーバーのご紹介 ( GitLab UX開発チーム ) - Claude Desktopでどうぞ https://gitlab.com/fforster/gitlab-mc p 他たくさん
- 20. 20 いずれ来る、悪意のある AI の”振る舞い”による脆弱性埋め込み攻撃に備える ! 合言葉は、「コードを書いたら、すぐスキャン！」しれっと潜り込む脆弱性を排除 SAST Static Application Security Testing ： ソー スコードを解析することで脆弱性を検出。 例： SQL インジェクション 依存関係スキャン パッケージマネージャ（ Maven 、 Gems な ど）の依存関係を解析することで、既知の ライブラリの脆弱性を検出。 例： CVE-2017-5638 (Apache Struts2) ライセンス コンプライアンス パッケージマネージャーの依存関係を解析 し、プロジェクトのポリシーに從った承認 済みや非許可のライセンスを検出。 例： AGPL ライセンス DAST Dynamic Application Security Testing ： 起 動中の Web アプリ（レビュー用でも）のラ ンタイム脆弱性を検出。 例： CSRF Web API Fuzz 起動中の Web API にランダムなリクエスト を発行。 例： 500 INTERNAL SERVER ERROR Secret Detection コミットしたコードに含まれる資格情報、 シークレット、パスワードなどをチェック し、機微な情報の漏洩を検出。 例： AWS Key Coverage Guided Fuzz ホワイトボックス的に関数、メソッドにラ ンダムな引数を渡し、実行。 例： ArrayIndexOutOfBoundsException (Java), Heap-Buffer-Overflow (C++) コンテナスキャン Dpkg や rpm などのパッケージマネージャ を解析し、コンテナ内の既知のライブラリ の脆弱性を検出。 例： Heartbleed, ShellShock 静的スキャン ランタイムスキャン 動的スキャン
- 21. Code Quality Browser Performance SAST Dep Scanning Container Scanning DAST License Mgmt Tests (e.g. jUnit) Secret Detection ガンガン走る、 GitLab 製スキャン + 他社スキャン！いずれ来る AI 製スキャン も！
- 22. 22 GitLab の AI 機能 のご紹介
- 23. © 2024 GitLab Inc. The Solution 最も包括的な AI 搭載 DevSecOps プラットフォーム GitLab Duo チャット エピック イシュー ディスカッション サマリー イシューの説明の 生成 マイルストーン 自動テスト コードのプッシュ マージリクエストサマリー マージリクエストの作成 テスト生成 根本原因分析 コード説明 マージコミットメッ セージ 承認 マージ の承認 リリース スキャン 脆弱性の説明と脆弱性の修正 共同作業とレビュー デプロイ AI インパクト ダッシュボード コードレビューサマリー ディスカッションサマリー ディスカッション サマリー コードの作成 コード提案 コードの作成
- 24. GitLab Copyright 2023 AWS Bedrock GitLab Self-Hosted Model Architecture はこれ GitLab.com AI Gateway Self-Managed LLMs (vLLM) GitLab Self- Managed 3rd party Model APIs Prompt Engineering IDE Integration UI Integration LLM provider ownership GitLab ownership (MVP) Customer ownership Self-Managed AI Gateway Claude 3 Mistral Mistral Azure AI Service GPT ( 予 ) Google Vertex AI Gemini Support Model Matrix Claude 3 LLM Model
- 25. GitLab ： DevOps/DevSecOps/DevPerformanceOps のベストプラクティスの組み込み Manage Plan Create Verify Package Secure Release Configure Monitor Protect マージリクエス トとブランチの 作成 自動ビルド 自動テスト コラボレーション レビュー 承認 コードの push コード修正 デプロイした アプリのレビュー イシューの割当 セキュリティ スキャン リリース マージ 受け入れ デプロイ エピック マイルストーン イシュー クリーンなコードだけをマージ 安全な場所で開発し、いくらでも失敗して良い 25
- 26. 26 DEMO
- 27. 27
- 28. 28
Editor's Notes
- #1: https://www.ai-driven.dev/ 12:10-12:50 40分
- #2: Please note all content past this point is related to upcoming products, features, and functionality. These items are subject to change and this content should not be used for planning or purchasing purposes. However we have taken great care to present a realistic roadmap that we actively use with our customers to show them the direction we are going with Duo and the future of software development.
- #15: ※これだけ別Theme（変えると色がおかしくなる）
- #16: 先ほどのスライドの右側を少しじっくり書いたもの。 さらっと次へ。
- #17: ＜メッセージも書き込む＞ 情報が分断されている状態と情報がまとまってコラボレーションできている状態を明記する。
- #23: 包括的なAI搭載DevSecOpsプラットフォーム。 このプラットフォームでは、ソフトウェア開発ライフサイクル全体が単一アプリケーションに統合されています。チームはAIを活用して、計画からデプロイに至るワークフロー全体で生産性を高めることができます。 また、このプラットフォームにはバリューストリーム主導の考え方が採用されています。具体的には、可能な限り最速のサイクルタイムで、顧客ニーズに基づいた顧客価値を創造するという考え方です。
- #25: 今回主に使う、ロードマップ、バーンダウン/アップの画面を使うタイミングはここですよ。メインブランチ、フィーチャーブランチの流れはこれ、というイメージも伝える。 テスト用のブランチ等、どんどんつくって、試みを実施できる。だめなら捨てればよい。マージさえしなければ、安全、ということも伝える) DevOpsには組織文化の変革も必要です。 GitLabを使えば、DevOpsのベストプラクティスへの近道を歩むことができます。 この図は、プロジェクトの計画から実際のソフトウェアデリバリとデプロイまでの古典的なプロセスを示しています。 Epics、つまりマイルストーンを形成するためには、GitLabのコアオブジェクトであるIssueが必要です。Issueは、作業の記録を残し、課題を提出し、開発すべき機能の詳細を定義するために使われます。 そして、レビュアーがあなたの修正したソースコードをレビューし、MR をメインブランチにマージする前にマージリクエストを受け取ります。 雖然DevOps還需要組織文化的改變。用了GitLab就能走，直到DevOps最佳實踐的近路 這個圖案說明了，從專案計劃到實際的軟體交付、部署的經典流程。 為了組成Epics、或milestones，這就需要我們GitLab的核心物件，Issue。用於留下作業紀錄、提交問題、定義需要開發的功能的細節。 然評審人評審你修改的原始碼，得到Merge Request的許可之後才讓MR合併到主branch。 Here you can see the core stages of the devops lifecycle, you have planning, code creation, all the way through to monitoring. And also shown, are are just some of the tools that can be potentially used at each stage. And this chaining together of tools, comes at the cost of integration complexity You need resources to design, build, and maintain the integrations, manage upgrades, and establish HA and DR for each one. They are brittle and can fail. Setting up a new project, or troubleshooting and optimizing an existing project, becomes difficult and is too slow for todays demands And the toolchain only serves to reinforce silios that you are trying to break down in the name of DevOps. Instead of teams being able to collaborate together, their different tools put them in indifferent workspaces.