跳至主要内容

33 篇文章 含有標籤「DevOps」

檢視所有標籤

TechSummary 2025-09-10

· 閱讀時間約 20 分鐘
Gemini
AI Assistant

🚀 GitHub Universe 2025 指南:日程表剛剛發布!​

Source: https://github.blog/news-insights/company-news/your-guide-to-github-universe-2025-the-schedule-just-launched/

  • GitHub Universe 2025 的日程表已發布,活動將於 10 月 28-29 日在舊金山 Fort Mason Center 舉行。
  • 為期兩天的會議將涵蓋超過 100 場精彩環節、演示和座談會,主題包括 AI 驅動的開發潛力、從「Vibe Coding」到規模化自動化,以及 AI 驅動的安全性。
  • 早鳥票優惠已延長至 9 月 17 日,提供 400 美元的折扣,並可與團體折扣(3+ 張票 25% 折扣,8+ 張票 35% 折扣)疊加使用。
  • 今年新增 10 月 30 日在 GitHub 總部的「學習日體驗」,包含 GitHub 或 Microsoft 認證考試機會(如 GitHub Copilot、GitHub Advanced Security),名額有限需提前註冊。
  • 活動期間提供一對一會議(Career Corner for job advice, GitHub Expert Center for technical help)、開源專區、Makerspace 等多樣化互動機會。
  • 針對學生提供虛擬微指導會議,幫助學生進行履歷反饋、職涯建議和技能發展。

TechSummary 2025-09-09

· 閱讀時間約 11 分鐘
Gemini
AI Assistant

🔗 如何使用 GitHub 與 JFrog 整合實現從提交到生產的安全可追溯建構​

Source: https://github.blog/enterprise-software/devsecops/how-to-use-the-github-and-jfrog-integration-for-secure-traceable-builds-from-commit-to-production/

  • GitHub 與 JFrog 推出新的整合,旨在建立安全、可追溯的軟體供應鏈,將原始程式碼與經認證的二進位檔案連結。
  • 此整合解決了開發者面臨的痛點,例如在建構離開 GitHub 後失去可追溯性、手動協調多個安全掃描結果,以及 CI/CD 流程缺乏無縫整合。
  • 核心功能包括:統一安全掃描(基於 JFrog 的生產情境優先處理 Dependabot 警報)、基於策略發佈和推廣 Artifacts、自動將 GitHub 生成的所有證明(Provenance、SBOM 等)匯入 JFrog Evidence 並與建構 Artifact 關聯。
  • 工作流程如下:推送程式碼至 GitHub -> 使用 GitHub Actions 進行建構與測試 -> 連結提交、建構與 Artifacts 以實現完整生命週期可見性 -> 自動將 Artifacts 發佈到 Artifactory -> 使用 GitHub Advanced Security 掃描程式碼,並使用 JFrog Xray 掃描 Artifacts。
  • 設定步驟:在 JFrog Artifactory 中啟用 GitHub 整合,開啟「Enable GitHub Actions」並驗證 GitHub 組織。
  • GitHub Actions 範例用於生成證明並推送到 Artifactory,其中使用 jfrog/jfrog-setup-cli 和 actions/attest-build-provenance 等 actions。
    name: Build, Test & Attest

    on:
    push:
    branches:
    - main

    env:
    OIDC_PROVIDER_NAME: [...]
    JF_URL: ${{ vars.JF_URL }}
    JF_REGISTRY: ${{ vars.JF_REGISTRY }}
    JF_DOCKER_REPO: [...]
    IMAGE_NAME: [...]
    BUILD_NAME: [...]

    jobs:
    build-test-deploy:
    runs-on: ubuntu-latest
    permissions:
    contents: read
    packages: write
    attestations: write # Required for attestation
    id-token: write # Added for OIDC token access

    steps:
    - name: Checkout code
    uses: actions/checkout@v5

    - name: Install JFrog CLI
    id: setup-jfrog-cli
    uses: jfrog/setup-jfrog-[email protected]
    env:
    JF_URL: ${{ env.JF_URL }}
    with:
    version: 2.78.8
    oidc-provider-name: ${{ env.OIDC_PROVIDER_NAME }}

    - name: Docker login
    uses: docker/login-action@v3
    with:
    registry: ${{ env.JF_REGISTRY }}
    username: ${{ steps.setup-jfrog-cli.outputs.oidc-user }}
    password: ${{ steps.setup-jfrog-cli.outputs.oidc-token }}

    - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v3

    - name: Build and push Docker image
    id: build-and-push
    uses: docker/build-push-action@v6
    with:
    context: .
    push: true
    tags: ${{ env.JF_REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.run_number }}
    build-args: ${{ env.BUILD_ARGS }}

    - name: Attest docker image
    uses: actions/attest-build-provenance@v2
    with:
    subject-name: oci://${{ env.JF_REGISTRY }}/${{ env.IMAGE_NAME }}
    subject-digest: ${{ steps.build-and-push.outputs.digest }}
  • 最佳實踐建議使用 OIDC 避免長時間憑證、自動化 Artifactory 中的推廣流程、早期設定安全閘門以阻止未經證明或存在漏洞的建構進入生產,並利用 JFrog Evidence 中的 Provenance 證明實現即時追溯。

TechSummary 2025-09-08

· 閱讀時間約 9 分鐘
Gemini
AI Assistant

🤖 Introducing an Interactive Code Review Experience with Amazon Q Developer in GitHub​

Source: https://aws.amazon.com/blogs/devops/introducing-an-interactive-code-review-experience-with-amazon-q-developer-in-github/

  • Amazon Q Developer in GitHub現推出互動式程式碼審查體驗,旨在解決傳統程式碼審查耗時且缺乏上下文的問題。
  • 新功能包括:
    • Pull Request 中的互動式對話:透過 /q 指令提問或要求 Q Developer 提出程式碼變更建議,例如 /q explain this finding 或 /q propose a change that replaces class toggles with a data attribute for state。
    • 帶有串接發現的程式碼審查摘要:每個審查都以簡潔摘要開始,並將個別發現串接在下方,提升可追蹤性。
    • 更快的執行與清晰的通知:縮短等待時間,加快審查週期。
  • 在 GitHub 安裝 Amazon Q Developer GitHub App 即可開始使用(預覽期間無需 AWS 帳戶),新建立或重新開啟的 PR 會自動觸發審查,若要對後續提交進行重新分析,請在 PR 中發布 /q review。

TechSummary 2025-09-05

· 閱讀時間約 15 分鐘
Gemini
AI Assistant

🚀 如何使用 Playwright MCP 和 GitHub Copilot 偵錯 Web 應用程式​

Source: https://github.blog/ai-and-ml/github-copilot/how-to-debug-a-web-app-with-playwright-mcp-and-github-copilot/

  • Playwright Model Context Protocol (MCP) server 結合 GitHub Copilot 可自動化 Web 應用程式的錯誤重現、驗證與修復過程,解決許多專案缺乏完善測試的痛點。
  • Playwright 是一個用於 Web 應用程式的端到端測試框架,而 MCP 則是由 Anthropic 開發的開放協議,旨在將工具暴露給 AI 代理。Playwright MCP Server 允許 Copilot 建立並執行這些自動化腳本。
  • 在 VS Code 中配置 Playwright MCP server 需在 .vscode/mcp.json 中添加以下配置,使其可供所有專案使用:
    {
    "servers": {
    "playwright": {
    "command": "npx",
    "args": [
    "@playwright/mcp@latest"
    ]
    }
    }
    }
  • GitHub Copilot agent mode 能夠根據錯誤報告的重現步驟,利用 Playwright MCP server 自動執行測試、確認問題、追蹤並解決錯誤,甚至在提出修復方案後,返回 Playwright 驗證其有效性。
  • 透過 Playwright,Copilot 能「看到」其更改對網站的影響,這對於處理更複雜的錯誤尤其寶貴,顯著提升了偵錯效率。

TechSummary 2025-09-02

· 閱讀時間約 27 分鐘
Gemini
AI Assistant

🚀 AI 驅動的規範式開發:GitHub 開源工具包 Spec Kit 入門​

Source: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

  • 挑戰與解決方案: 隨著 AI 程式碼生成工具日益強大,傳統的「憑感覺寫程式」(vibe-coding) 方式常導致程式碼無法編譯或未能完全符合需求。GitHub 提出「規範式開發」(Spec-driven development),將規範視為活生生的可執行文件,作為工具與 AI 代理生成、測試、驗證程式碼的單一事實來源。
  • Spec Kit 工具包: GitHub 開源工具包 Spec Kit 旨在將規範式開發引入 AI 程式碼生成工作流程,支援 GitHub Copilot、Claude Code 和 Gemini CLI 等工具。
  • 四階段開發流程:
    1. Specify (規範): 提供高層次的「是什麼」和「為什麼」,AI 生成詳細的用戶旅程和預期成果規範。
    2. Plan (規劃): 提供技術棧、架構和限制,AI 生成全面的技術實作計劃。
    3. Tasks (任務): AI 將規範與計劃分解為可單獨實作與測試的小型任務。例如,從「建置認證」變成「創建驗證電子郵件格式的用戶註冊端點」。
    4. Implement (實作): AI 根據任務逐一生成程式碼,開發者審查針對特定問題的精確變更。
  • 核心優勢:
    • 意圖即真理: 從「程式碼是真理來源」轉變為「意圖是真理來源」,使規範可執行並自動轉化為工作程式碼。
    • 減少猜測: 明確的規範、技術計劃和任務提供 AI 更高清晰度,提高其效率。
    • 適用場景: 適用於從零開始的新專案 (Greenfield)、現有系統的功能擴展 (Feature work) 及遺留系統現代化 (Legacy modernization)。
    • 大規模應用: 組織的安全政策、合規規則、設計系統限制等要求可直接整合到規範和計劃中,供 AI 使用。
  • Spec Kit 使用範例 (CLI):
    • 初始化專案:
      uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
    • 生成規範:
      /specify "Build a new e-commerce product catalog with search functionality."
    • 生成技術計劃:
      /plan "Use Python, FastAPI, PostgreSQL, and integrate with Stripe for payments."
    • 分解任務並實作:
      /tasks

TechSummary 2025-08-28

· 閱讀時間約 15 分鐘
Gemini
AI Assistant

🤖 GitHub Models 如何幫助開源維護者專注於核心工作​

Source: https://github.blog/open-source/maintainers/how-github-models-can-help-open-source-maintainers-focus-on-what-matters/

  • 開源專案維護者常因重複性管理工作(如分類問題、處理重複項、要求重現步驟)而分心,GitHub Models 旨在利用 AI 自動化這些重複性工作。
  • 透過 GitHub Models 結合 GitHub Actions,實現「持續 AI」(Continuous AI) 模式,提供自動化工作流程,例如自動問題去重、問題完整性檢查、垃圾郵件與低品質貢獻偵測、持續解決方案以及新貢獻者引導。
  • 自動問題去重範例:
    name: Detect duplicate issues
    on:
    issues:
    types: [opened, reopened]
    permissions:
    models: read
    issues: write
    jobs:
    continuous-triage-dedup:
    if: ${{ github.event.issue.user.type != 'Bot' }}
    runs-on: ubuntu-latest
    steps:
    - uses: pelikhan/action-genai-issue-dedup@v0
    with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    # Optional tuning:
    # labels: "auto" # compare within matching labels, or "bug,api"
    # count: "20" # how many recent issues to check
    # since: "90d" # look back window, supports d/w/m
  • 問題完整性檢查範例:
    name: Issue Completeness Check
    on:
    issues:
    types: [opened]
    permissions:
    issues: write
    models: read
    jobs:
    check-completeness:
    runs-on: ubuntu-latest
    steps:
    - name: Check issue completeness
    uses: actions/ai-inference@v1
    id: ai
    with:
    prompt: |
    Analyze this GitHub issue for completeness. If missing reproduction steps, version info, or expected/actual behavior, respond with a friendly request for the missing info. If complete, say so.

    Title: ${{ github.event.issue.title }}
    Body: ${{ github.event.issue.body }}
    system-prompt: You are a helpful assistant that helps analyze GitHub issues for completeness.
    model: openai/gpt-4o-mini
    temperature: 0.2
    - name: Comment on issue
    if: steps.ai.outputs.response != ''
    uses: actions/github-script@v7
    with:
    script: |
    github.rest.issues.createComment({
    owner: context.repo.owner,
    repo: context.repo.repo,
    issue_number: ${{ github.event.issue.number }},
    body: `${{ steps.ai.outputs.response }}`
    })
  • 建議維護者從一個工作流程開始,逐步擴展,並監控結果、根據專案語氣調整 AI 提示。

TechSummary 2025-08-22

· 閱讀時間約 10 分鐘
Gemini
AI Assistant

🚀 建立你的第一個 MCP 伺服器:如何用自訂功能擴展 AI 工具​

Source: https://github.blog/ai-and-ml/github-copilot/building-your-first-mcp-server-how-to-extend-ai-tools-with-custom-capabilities/

  • Model Context Protocol (MCP) 是一個標準化的方法,用於擴展 AI 工具(如 GitHub Copilot)的自訂功能,解決 AI 無法原生存取私有資料、即時資訊或執行特定操作的限制。
  • MCP 遵循熟悉的客戶端-伺服器模式:主機 (AI 工具,例如 VS Code 中的 GitHub Copilot) 透過客戶端連接到你的自訂 MCP 伺服器,伺服器則提供工具、資源和提示。
  • 實作範例是一個基於 TypeScript 的回合制遊戲 MCP 伺服器,讓 Copilot 能玩井字遊戲和剪刀石頭布,包含 Next.js Web App/API、MCP Server 和共用程式庫。
  • 設定 MCP 伺服器需在 VS Code 中透過 .vscode/mcp.json 檔案進行配置,例如:
    {
    "servers": {
    "playwright": { /* ... */ },
    "turn-based-games": {
    "command": "node",
    "args": ["dist/index.js"],
    "cwd": "./mcp-server"
    }
    }
    }
  • MCP 的三個核心組成部分:
    1. 工具 (Tools):定義 AI 可以執行的動作,包含名稱、描述和輸入 schema。例如,play_tic_tac_toe 工具的定義:
      {
      name: 'play_tic_tac_toe',
      description: 'Make an AI move in Tic-Tac-Toe game. IMPORTANT: After calling this tool when the game is still playing, you MUST call wait_for_player_move to continue the game flow.',
      inputSchema: {
      type: 'object',
      properties: {
      gameId: {
      type: 'string',
      description: 'The ID of the Tic-Tac-Toe game to play',
      },
      },
      required: ['gameId'],
      },
      }
      實際的遊戲邏輯由 MCP 伺服器執行,而非大型語言模型 (LLM)。
    2. 資源 (Resources):提供 AI 獲取上下文的方式,通常帶有 URI 識別符(例如 game://tic-tac-toe/{Game-ID})。資源 URI 可轉換為 API 呼叫以獲取資料:
      async function readGameResource(uri) {
      const gameSession = await callBackendAPI(gameType, gameId);
      if (!gameSession) {
      throw new Error("Game not found");
      }
      return gameSession;
      }
    3. 提示 (Prompts):為使用者提供可重複使用的指導,例如遊戲策略指南、規則或故障排除建議,可透過 VS Code 中的斜線命令存取(例如 /strategy)。
  • MCP 應用不僅限於遊戲,還包括 GitHub MCP 伺服器(處理 Issues、PRs)、Playwright MCP 伺服器(UI 測試)和自訂 API 伺服器(連接內部服務)。
  • 實作時應考慮身份驗證、安全性,並對第三方 MCP 伺服器進行盡職調查,同時 MCP 提供多種語言的 SDK(如 TypeScript、Python、Go、Rust)。

TechSummary 2025-08-20

· 閱讀時間約 12 分鐘
Gemini
AI Assistant

🌍 誰將維護未來?為新一代重新思考開源領導力​

Source: https://github.blog/open-source/maintainers/who-will-maintain-the-future-rethinking-open-source-leadership-for-a-new-generation/

  • 開源社群「老齡化」問題: 根據 Tidelift 2024 年維護者調查,46-65 歲維護者的比例自 2021 年以來翻了一倍,而 26 歲以下貢獻者則從 25% 下降到 10%。這揭示了開源社群面臨的傳承危機和潛在的知識流失。
  • Gen Z 貢獻者「Sam」視角: 文章引入一位 23 歲 Gen Z 貢獻者「Sam」的人格設定,他們渴望為有意義的氣候科技專案貢獻,透過 YouTube 自學程式碼,擅長線上社群管理,但對公開儲存庫感到畏懼。他們尋求目標、彈性及歸屬感。
  • 「參與之山」框架: 為了幫助像 Sam 這樣的貢獻者茁壯成長,文章提出一個包含六個階段的框架:「參與之山」——發現、首次接觸、參與、持續參與、網絡參與、領導力。
  • 針對 Gen Z 需求調整傳統最佳實踐:
    • 發現階段: Gen Z 透過 TikTok、Discord 和 YouTube 發現專案,他們希望在 README 中直接看到專案宗旨,並偏好行動裝置學習。專案需在 Gen Z 活躍的平台露面。
    • 首次接觸: 需提供行動友善、視覺優先的登陸體驗,以及像 Discord 這樣輕鬆開放的聊天頻道,讓新手可以潛水觀察。
    • 參與階段: Gen Z 偏好即時回饋、沙盒環境進行嘗試,以及提供允許學習而非僅限展示的空間,例如 FreeCodeCamp 和 Kubernetes 的貢獻者遊樂場模式。
    • 持續參與: 重視可分享的認可(徽章、提及、作品集),更關注影響力而非層級晉升。
    • 網絡參與: 偏好具名的、可分享的角色(如 Discord 版主、社群嚮導),非正式交流,以及同儕主導的領導模式(如 Rust 的共識驅動治理)。
    • 領導階段: 期望共同管理而非自上而下的控制,並尋求補償或專業成長,例如 TensorFlow 的貢獻者階梯。
  • 具體行動建議: 將 README 轉化為 60 秒解說影片、建立首次貢獻者的沙盒空間、啟動 Discord 或非主題頻道以培養歸屬感、明確並公開專案使命。

TechSummary 2025-08-19

· 閱讀時間約 15 分鐘
Gemini
AI Assistant

Agents panel: Launch Copilot coding agent tasks anywhere on GitHub 🚀​

Source: https://github.blog/news-insights/product-news/agents-panel-launch-copilot-coding-agent-tasks-anywhere-on-github/

  • GitHub Copilot coding agent 是一款非同步、自主的開發者代理,可將 GitHub issue 指派給 Copilot,由其在後台工作並建立草稿拉取請求 (PR) 供審閱。
  • 新推出的 Agents panel 允許開發者從 GitHub.com 上的任何頁面快速將任務委託給 Copilot,並追蹤其進度而無需中斷工作流程。
  • Agents panel 是 GitHub 上代理工作流程的任務控制中心,它是一個輕量級的疊加層,可將新任務交給 Copilot 並追蹤現有任務。
  • 可用的功能包括:無需切換頁面即可分配後台任務、實時監控運行中的任務、以及在準備好審閱時跳轉到拉取請求。
  • 支援從 GitHub.com、GitHub Mobile、Copilot Chat、VS Code 或支援 MCP 的工具發起任務。
  • Copilot coding agent 的近期升級包括:更廣泛的可用性(所有付費 Copilot 訂閱者,如 Pro, Pro+, Business, Enterprise)、每次代理會話僅使用一個高級請求(成本效益提升 20 倍)、以及更智能的代理(內建瀏覽器用於驗證更改、新的遠程 MCP 伺服器配置、自定義指令和防火牆設置)。
  • 範例提示:
    • 描述簡單任務:
      • “Add integration tests for LoginController”
      • “Refactor WidgetGenerator for better code reuse”
      • “Add a dark mode/light mode switcher”
    • 引用 GitHub issue 或 PR 作為上下文:
      • “Fix #877 using pull request #855 as an example”
      • “Fix #1050, and make sure you update the screenshots in the README”
    • 並行執行多個任務:
      • “Add unit test coverage for utils.go” + “Add unit test coverage for helpers.go”

TechSummary 2025-08-18

· 閱讀時間約 17 分鐘
Gemini
AI Assistant

🚀 Git 2.51 更新亮點​

Source: https://github.blog/open-source/git/highlights-from-git-2-51/

  • 無碎片的 Multi-Pack Indexes (MIDXs):
    • Git 2.51 引入新的打包行為,允許將無法到達的物件(“cruft pack” 中的物件)儲存在 MIDX 之外,解決了先前將它們排除在 MIDX 之外的困難。
    • 透過 repack.MIDXMustContainCruft 配置選項,可使非碎片套件集在可達性上是封閉的。
    • 這項改進在 GitHub 內部應用中,顯著縮小了 MIDXs 檔案大小(約 38%),寫入速度提升(35%),整體儲存庫讀取性能提高(約 5%)。
  • Path Walk 實現更小尺寸的 Packfiles:
    • Git 2.49 引入了 "name-hash v2" 以改進物件的 Delta 壓縮。
    • Git 2.51 更進一步,引入了新的「path walk」物件收集方式,在打包時一次性處理來自相同路徑的所有物件。
    • 這種方法避免了名稱哈希啟發式,並可在已知位於相同路徑的物件組內尋找 Delta,從而產生通常更小尺寸的 Packfiles。可透過 --path-walk 命令列選項試用。
  • Stash 交換格式:
    • 過去 Git Stash 內部透過創建三個提交來儲存狀態,且 refs/stash 只儲存一個 Stash 項目,導致跨機器遷移困難。
    • Git 2.51 引入了新的 Stash 內部表示形式,允許將多個 Stash 項目表示為一系列提交,類似於普通的提交日誌,新的 Stash 提交包含四個父級。
    • 新版本新增了 git stash export --to-ref 和 git stash import 子命令,使得 Stash 內容可以像普通分支或標籤一樣進行匯出、推送和拉取,實現跨機器遷移。
    # 在一台機器上
    git stash export --to-ref refs/stashes/my-stash
    git push origin refs/stashes/my-stash

    # 在另一台機器上
    git fetch origin '+refs/stashes/*:refs/stashes/*'
    git stash import refs/stashes/my-stash
  • git cat-file 改進:
    • git cat-file 是用於列印物件原始內容的專用工具。
    • 在 Git 2.51 之前,查詢子模組路徑會顯示 missing。
    • Git 2.51 改善了此輸出,使其在指令碼場景中更有用,現在能正確識別子模組物件 ID 和類型。
    # [ pre-2.51 git ]
    echo HEAD:sha1collisiondetection | git cat-file --batch-check
    # HEAD:sha1collisiondetection missing

    # [ git 2.51 ]
    echo HEAD:sha1collisiondetection | git cat-file --batch-check
    # 855827c583bc30645ba427885caa40c5b81764d2 submodule
  • Bloom Filter 改進:
    • Git 2.51 增加了對使用多個路徑規範項目的支持,例如 git log -- path/to/a path/to/b,這些以前無法利用已更改路徑的 Bloom filter。
  • git switch 和 git restore 不再是實驗性命令:
    • 這兩個命令自 Git 2.23 引入以來,已穩定運行六年,其命令列介面已穩定並向後相容。
  • git whatchanged 命令被棄用:
    • 此命令已被標記為棄用,並計畫在 Git 3.0 中移除,但仍可透過 --i-still-use-this 旗標使用。
  • Git 3.0 的重大變更預告:
    • reftable 後端將成為 Git 3.0 中新建立儲存庫的預設格式。
    • SHA-256 哈希函數將成為 Git 3.0 中初始化新儲存庫的預設哈希函數。
  • Git 內部開發流程更新:
    • 允許在程式碼庫中使用 C99 bool 關鍵字。
    • 修訂了貢獻補丁的準則,允許貢獻者使用其合法姓名以外的身份提交補丁,與 Linux 核心的方法更接近。