特性標記清理:GitHub Actions 來幫忙!

王大冶發表於2024-12-01
  • CSS技巧與案例詳解
  • vue2與vue3技巧合集
  • VueUse原始碼解讀

image.png

在專案中使用特性標記的原因、好處和用例是什麼?

特性標記是一種強大的軟體開發技術,它允許在不需要重新部署應用程式的情況下,動態控制功能和其他程式碼的開啟或關閉,而且都是實時的。我們可以"暗暗地"推出新功能,只在必要時且當我們完全準備好時才使其可用。有人可能稱它們為"功能開關"(feature toggles),但我更喜歡叫"特性標記"(feature flags)。

從基本角度來看,特性標記就是程式碼中的附加條件。眾所周知,程式碼中的條件經常會引入複雜性。有許多設計模式和工具可以幫助降低程式碼複雜性,使其更易於維護和更可靠。

事實#1:特性標記可能會使事情變得更復雜。

現在,我們探討不同的用例和優勢。

首先,特性標記對於主幹開發(trunk-based development)來說是必不可少的。你不再需要維護長期存在的功能分支,開啟PR並將其合併到主分支。這幫助我們在開發中更快地部署和前進。

你還可以採用各種推出方式,比如金絲雀釋出(僅為小比例使用者啟用新功能)和A/B測試(為大量使用者群啟用該功能並將他們的行為與"對照"組進行比較),只需簡單點選幾下即可。

特性標記的另一個好處是所謂的目標定位。你可以基於規則配置特性標記的值,允許你設定預設值併為特定使用者或組織指定不同的值。

事實#2:特性標記有助於減輕壓力並最小化釋出功能時的風險。

特性標記不僅對軟體工程師有用。QA工程師、產品經理和銷售經理也能從中受益。特別是銷售經理可以利用特性標記向新客戶展示即將推出或早期釋出的功能,從而加強他們在談判中的地位。

到目前為止,我們討論了特性標記的比較重要的好處。然而,頻繁使用特性標記會產生技術債。手動管理數十個特性標記還算舒適,但當涉及到數百個時就變成了噩夢。特別是當人們開始將特性標記管理系統用作配置儲存,或者當特性標記用於每個小的內容更改時。

事實#3:頻繁使用特性標記會導致技術債務。

我們如何有效地解決這個問題?一種解決方案是安排一個特定的日期,每月或每季度進行一次標記清理。但是,手動執行這項工作需要大量時間。

處理特性標記可能會令人沮喪。我工作過的每個專案都使用不同的管理系統。但通常是LaunchDarkly,因此我的用例將基於它。相信它可以與任何其他系統整合,因為方法才是關鍵。

首先,我們需要確定標記是否過時並需要修改。在我的情況下,有兩種可能:

  1. 標記未被使用/從程式碼中移除,但在系統中未被歸檔。
  2. 如果標記對所有客戶都啟用,並且沒有任何衝突規則。

我們應該做的第一件事是將我們的程式碼與特性標記管理系統同步。LaunchDarkly有一個很棒的功能叫做"Code References"。

image.png

要啟用它,你必須在主分支中執行以下操作:

launchDarkly-code-references:
  name: Code References
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
      with:
        fetch-depth: 11 # 如果find-code-references的lookback配置選項未禁用,則必須設定此值。
    - name: LaunchDarkly Code References
      uses: launchdarkly/find-code-references@v2.11.8
      with:
        accessToken: ${{ secrets.ACCESS_TOKEN }}
        projKey: ${{ secrets.PROJECT_KEY }}

目的是在你的程式碼中搜尋特性標記條目,並在LaunchDarkly中的程式碼引用中顯示它們。

此外,我嘗試尋找一些可以用作過時特性標記報告器的GitHub Action。雖然LaunchDarkly有自己的Slack整合,但它的"準備刪除"標記演算法有點奇怪。它有時會返回甚至是永久性的特性標記。

這就是為什麼決定自己採取行動。很感激LaunchDarkly提供了詳細的REST API文件,我發現它非常有用。

這個Action幫助識別符合規則檔案中指定的刪除標準的特性標記。它為特性標記生成報告,允許使用者輕鬆地將其分享到指定的渠道(如Slack)或直接在控制檯中檢視。此外,該Action提供特性標記作為輸出,允許你根據需要自定義使用方式。

你可能想要指定在LaunchDarkly中定義的維護團隊。使用excluded tags來定義不應報告的例外(特殊特性標記)。

name: Feature Flags Ready For Removal
on:
  schedule:
    - cron: "00 11 * * 5"
  workflow_dispatch:

jobs:
  send-feature-flags-report:
    name: Feature Flags
    runs-on: ubuntu-latest
    steps:
      - name: 'Send Report'
        uses: rkhaslarov/launchdarkly-outdated-feature-flags-reporter-action@v1.0.0
        with:
          access-token: ${{ secrets.ACCESS_TOKEN }}
          project-key: ${{ secrets.PROJECT_KEY }}
          environment-key: ${{ secrets.LD_ENV }}
          maintainer-teams: 'team'
          threshold: 30
          report-type: 'slack'
          excluded-tags: 'MANUAL_REVIEW'
          slack-webhook: ${{ secrets.SLACK_WEBHOOK }}

我們已經探索了特性標記,理解了它們的使用方式及其複雜性。然後檢視了簡化LaunchDarkly中特性標記識別和清理的action。請幫我一個忙,在審查期間謹慎處理特性標記,如果其他消費者沒有主動使用它們,請考慮刪除。

首發於公眾號 大遷世界,歡迎關注。📝 每週一篇實用的前端文章 🛠️ 分享值得關注的開發工具 ❓ 有疑問?我來回答

本文 GitHub https://github.com/qq449245884/xiaozhi 已收錄,有一線大廠面試完整考點、資料以及我的系列文章。

相關文章