凱爾打扣

最近開發流程從 Gitflow 改為 Trunk-Based，讓每個 Feature 能很快速地回到主幹分支，但頻繁交付有時也不會想把新功能推出在使用者面前，所以這時候就能用 Feature Flag 來管理這些還沒有要發佈的功能，本篇文章記錄一下如何在 .NET Core 加入此功能，並講解一下目前實務上常規化的 Flag Nuget 安裝 dotnet add package Microsoft.FeatureManagement.AspNetCore 加入 Feature Toggle public void ConfigureServices(IServiceCollection services) { // feature toggle services.AddFeatureManagement(); services.AddControllers(); services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new OpenApiInfo {Title = "FeatureFlagPoc.API", Version = "v1"}); }); } 要使用時直接注入 private readonly IFeatureManager _featureManager; public WeatherForecastController(ILogger<WeatherForecastController> logger, IFeatureManager featureManager) { _logger = logger; _featureManager = featureManager; } 基本的 Feature Toggle 使用 var isFeatureAEnabled = await _featureManager....

Feature Flag 是否開啟，也可以透過自訂的類別來撰寫，可以透過IFeatureFilter來實現，以下範例以取得使用者 User-Agent 為例 實作IFeatureFilter，新增一個 BrowserFeatureFilter.cs 檔案 [FilterAlias("Browser")] public class BrowserFeatureFilter : IFeatureFilter { private readonly IHttpContextAccessor _httpContextAccessor; public BrowserFeatureFilter(IHttpContextAccessor httpContextAccessor) { _httpContextAccessor = httpContextAccessor; } public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context) { // 取得Request的瀏覽器類型 var agent = _httpContextAccessor.HttpContext.Request.Headers["User-Agent"].ToString(); // 取得 appSettings.json的設定 var settings = context.Parameters.Get<BrowserFilterSettings>(); // TODO: 這邊就可以撰寫邏輯驗證是否針對該瀏覽器開此功能 return Task.FromResult<bool>(false); } } public class BrowserFilterSettings { public string[] Allowed { get; set; } } appsettings.json (允許Edge瀏覽器開啟FeatureA功能) "FeatureManagement": { "FeatureA": { "EnabledFor": [ { "Name": "Browser", "Parameters": { "Allowed": [ "Edg" ] } } ] } } startup 注入 services....

如果要針對某用戶或群組來開啟特定功能，在 .NET Feature Management 中可以用 TargetFilter 來指定 appsettings.json (指定當前使用者的Guid或群組) RolloutPercentage 為選擇性參數，可以指定多少百分比的使用者會導向該功能 "FeatureManagement": { "FeatureA": { "EnabledFor": [ { "Name": "Microsoft.Targeting", "Parameters": { "Audience": { "Users": [ "1948fcc1-dc03-44a6-824f-fb48166ffa9d" ], "Group": [ { "Name": "Group1", "RolloutPercentage": 80 }, { "Name": "Group2" } ] } } } ] } } 實作 ITargetingContextAccessor public class TestTargetingContextAccessor : ITargetingContextAccessor { private const string TargetingContextLookup = "TestTargetingContextAccessor.TargetingContext"; private readonly IHttpContextAccessor _httpContextAccessor; public TestTargetingContextAccessor(IHttpContextAccessor httpContextAccessor) { _httpContextAccessor = httpContextAccessor ?...

Azure Static Web App 是什麼? 在今年 5 月 Azure 推出了 Azure Static Web App 的服務，如果要一句話來說，建立此服務時，可以一併設定與 Github or Azure DevOps 連結，在每次 Commit 的時候，就能直接將前端應用程式佈署到Azure，大大的增加開發體驗。除了靜態的 HTML、CSS、JavaScript，支援主流框架 React/Angular/Vue.js，也支援用 C# 撰寫 SPA 的框架 Blazor，支援的前端框架可以到此連結，後端可搭配 Azure 的 Serverless 服務 (Azure Function) 來實現 Api 的串接，透過 Reverse-Proxy 也省去的 CORS 的設定 Azure Static Web App 的價格 在免費的方案，即提供 SSL 的 Hosting，及 2 個自訂網域，可於 DNS Server 設定 cname，也可佈署你的後端程式於 Azure Function 搭配前後端串接，享有 100 萬個 Request 的免費額度 發佈 LINE Liff App 到 Azure Static Web App LIFF 全名是 LINE Front-end Framework，一個可以在 LINE App 內運作的網頁程式，可以將一些不適合對話式的情境，結合於 Line App 裡面，達成一致的體驗，也因為是 Liff App 是全前端實現，所以很適合發佈到 Azure Static Web App，以下用官方的 Liff Starter 來做一個部屬示範 https://github....

這是我自己整理的 Line Message Api Postman Collections 任何人只要 Import 後修改即可直接調用測試 詳細內容請見我的 Github Repo: https://github.com/kyleap/line-message-api-postman