機能開発branchとmain branchの体制で運用する。
PRでのレビュー必須（Approvedは可能であれば複数が望ましい）
テストコード必須 or 推奨
機能開発branchがMerge Ready になるとは [ devでの検証が取れている ] ではなく、[ 機能開発branchの内容をprodにdeployしてから、検証OKのフィードバックを受け取るところまで完了している ]である。

が、主だった特徴に思える。

release branchが欲しくなる

mainと機能開発branchの構成の場合、機能開発branchの検証タイミングとrebaseタイミングが煩雑になりがちになる。
そして、チームメンバーのスキルにグラデーションがある場合

手の速いプレイヤーがガンガンリリースを切っていくことでmainのコミットとtagはどんどん積みあがる。
すると、手の遅いプレイヤーは再rebase作業が重なり、しんどい状況になる。

という課題が発生した。
そのため、

mainのheadからrelease branchを必ず作成し、以降のReleaseのための準備やFixについてはrelease branchにコミットを積む。
存在出来るrelease branchは最大1つだけ。（= releaseの追い抜きが不許可になるため、再rebaseを行うストレスが軽減される。）

とした方がprodにdeployする資産を作る際のrebase漏れや検証途中での再rebaseの負担増が起きにくく、(少なくとも我々にとっては）筋が良いようだ。
逆に開発チームがハイパワーな場合は、rebase業を忘れることはなく、複数回のrebase業が苦にならなかったり、そもそも開発スピードが速いため、rebase業をそれほど行わずにガンガンreleaseを切っていけるんだと思う。

PRレビューを小口化するためのルールについても形式化したくなる

機能開発branchからSub branchを切るかどうかの判断は、PRを分割するかどうか(=PRのサイズが大きくなるかどうか)という観点で行われることが望ましい。
形式化すると無駄なbranch操作が必要になるので、生産性には悪影響がある。
一方で、チームのパワーにグラデーションのあるケースだと、所作を決めたほうが混乱が少ないようだ。

所作をある程度固定化しつつ、生産性のために一部の所作は省略しても良いよう、branch modelを書いてみることにした。

customed branch model figure

about customed branch model

前提条件

機能開発branch、release branch、main branchの体制で運用する。（左記のbranchは必ずbranchのフロー上登場する。）
PRでのレビュー必須（Approvedは2以上必要）
テストコード必須 or 推奨
release branch を作成する = Staging へのdeploy＆検証 Ready = 機能開発の実装自体はこのタイミングで閉める。
release branch は１度に最大１つだけ作成出来る。但し、複数機能開発branchをMergeすることは可能。
release branchに機能開発branchをMergeするタイミングで、必要に応じてrebaseが必要。
prodへのdeployが完了し、prodでの検証OKのフィードバックを以て、main branchへのmerge、releaseのpublish、Tagの追加がReadyとなる。

feature integration branch は形式化したい人向けのoptionalなルート

機能開発を統合するようなbranchを作成し、PRを小口で作成し都度mergeしていく(prerelease0.1 => 0.2 のフロー)
機能開発branchで開発していて、先にレビューしてもらいたいケースが出てきた場合に、sub branchを作成し、PR作成⇒レビューを行い、merge readyになったタイミングで機能開発branchにmergeを行う（prerelease0.3 => release 1のフロー）

両者はやっていることは同じなので、本質的には後者のみで構わないはずだが、形式化を好む人は前者での作業のほうが心が安らぐようなので記述した。
一方で、合理性を好むタイプの人は後者での作業を従来通り行ってくれれば良い。

尚、機能開発branchのサイズが小さければsub branchを切らなくて良い(prerelease0.2 => 0.3 のフロー)

開発中の機能をmainに合流させたいケースを考える

前提としてエッジケースなので、図には記載しない。
開発が割合長期に渡る等の理由で、prodの稼働等が未達だが、mainにコードを合流させたいというケースがリアルワールドでは起こりうる。
実際問題、開発を統合するためのbranchを育てる方法も度が過ぎれば、PRのレビューやテストのカロリーが許容範囲を超えてくることはままある。

開発中の機能からmainへの直接PR作成＆mergeについては

現在稼働中の資産への影響がないこと
現在release branchが生存中ではないこと

を満たしている場合のみ許容するのが筋が良いように思える。

release branchの存在意義について

ケースによってはrelease branchが冗長になりがちではあるものの、機能開発branchのrebaseを忘れた状態で検証を行ってしまって時間をロスするといったケースを防ぐことが出来るというメリットが存在する。一方で手数は増えるため、開発チームのパワーと相談して決めるのが筋が良いように感じた。（少なくとも、2021年現在の自分のチームでは、必要なように思う。）

また、release branchは複数の機能開発branchをMergeする役割も担うことになる。（図で表現されていないけれど……。）

まとめ

こんなもの考えなくても完全にWayに則って進行できるのが一番ローコストで良い。

と思う一方で、チームのパワーに合わせてまずはミスが出にくい仕組みにして一歩ずつ進めていくしかないという気持ち。

2021-11-08

Swashbuckle.AspNetCore.SwaggerでSwaggerUiのRootPathを変更する

ASP.NET Core MVC Swashbuckle

Swashbuckle.AspNetCore.SwaggerでSwaggerUiのRootPathを変更したい

前回のユースケースで、PathBaseを利用してWebApiのRootPathを変更した場合、SwaggerUi自体のRootPathも変更が必要になります。

UseSwaggerUIのSwaggerUiOptionsのRoutePrefixにサブディレクトリを設定する

個人的にSwashbuckleに関連するConfigureをまとめてるのは以下です。 github.com

UseSwaggerUIのSwaggerUiOptionsのRoutePrefixにサブディレクトリを設定するコード例

github.com

                    .UseSwaggerUI(option => {
                        option.SwaggerEndpoint(swaggerUiSettings.Url, swaggerUiSettings.Name);
                        if (swaggerUiSettings.RoutePrefixSettings.IsOverridable) {
                            option.RoutePrefix = swaggerUiSettings.RoutePrefixSettings.RoutePrefix;
                        }
                    });

settingによって切り替えるコードにしているのでswaggerUiSettings.RoutePrefixSettings.IsOverridableの検査が入っていますが、option.RoutePrefixに、サブディレクトリを設定することで、SwaggerUIのRootPathを変更することが可能です。

次に

SwaggerUiからrequestを投げるエンドポイントのRootPath（Swagger a.k.a. OpenApi的にはServersに関するSettings）

の設定を行っていきます。（続きます。）

2021-10-24

Swashbuckle.AspNetCore.Swaggerでswagger.jsonのRootPathを変更する

ASP.NET Core MVC Swashbuckle

Swashbuckle.AspNetCore.Swaggerでswagger.jsonのRootPathを変更したい

表題の通りの欲求が発生するケースが、エンドポイントをサブディレクトリで分けて追加していくリアルワールドアプリケーションでは発生することがあります。サブドメインを切ってくれればいいんですが、証明書の管理面倒だぞ！って話になったり、事情は色々です。

UsePathBaseを使ってのRootPathを指定することで、エンドポイント自体のRootPathは変更可能ですが、今度はSwagger.jsonのRootPathを変更する必要があります。

UseSwaggerのSwaggerOptionsのRouteTemplateの頭にサブディレクトリを付与する

個人的にSwashbuckleに関連するConfigureをまとめてるのは以下です。 github.com

UseSwaggerのSwaggerOptionsのRouteTemplateの頭にサブディレクトリを付与するコード例

github.com

app
    .UseSwagger(option => {
        if (swaggerSettings.RouteTemplateSettings.IsOverridable) {
            option.RouteTemplate = $"{swaggerSettings.RouteTemplateSettings.RouteTemplatePrefix}{option.RouteTemplate}";
        }

settingによって切り替えるコードにしているのでswaggerSettings.RouteTemplateSettings.IsOverridableの検査が入っていますが、option.RouteTemplateに、サブディレクトリを付与することで、swagger.jsonのRootPathを変更することが可能です。

次に

SwaggerUiのRootPath
SwaggerUiからrequestを投げるエンドポイントのRootPath（Swagger a.k.a. OpenApi的にはServersに関するSettings）

の設定を行っていきます。（続きます。）

2021-10-10

Manage It! 読書メモ

プロジェクト管理の書籍、久しぶりに読む

Manage It!を読んでの感想とか。

プロジェクト is 何

新しいプロダクトやサービスの作成を目的とする新たな取り組み、もしくは体系的なプロセスを指す。

Done条件は成果の納入。

リスクを伴い、多くの場合、リソースが限られることによる制約を受ける。

プロジェクトマネージャー is 何

上記のリスクとリソースの管理者を指す。

完了が何を意味するかを明確に示し、伝達し、プロジェクトをDone状態に導くことを職務とする。

推進力の把握

プロジェクトによって様々。機能セットと期日が大事なケースもあれば、品質要件が必達なケースもある。それらをまず把握すること。

顧客からみたプロジェクトの推進力のリスト

成果(機能セット)
リリース期日
品質

プロジェクトの制約条件

利用環境
チーム構成の柔軟さ
義務つけられるプロセスがあるか
メンバーとその能力
予算額

※ 制約条件はあとから変更可能

制約条件によって、プロジェクトの最大規模が決まる。

列挙した要件の中で一番大事なものがそのプロジェクトのドライバー(推進力)。要件に優先順位をつけて、Top のものがドライバーということ。

　Projectに過剰な制約条件を課そうとするスポンサーに対処する

この項の、「優先順位のリスト化をして、選ばせることが有効なのは相手に迷いがあるケース」というのは自分の経験とも合致する。

工数で割れないものは実現できない。

というのは当たり前なのだけれど、管理業と交渉業は論理とは別の筋肉を使うので難しい。

相手が、希望と、絶望、どちらに金を払うタイプかによって、話を通すときに使う言葉を変えるというのは、リアルワールドではよくやる手段ではある。

が、こういった私のムーブは、正道で対処することを好む人からすると邪道なのだろうなあとも思う。（が、正しいことを伝えて、わかってもらえる人ばかりであるならば、世の中世話はないので、どうしても必要になるなあという感想。）

2021-09-18

.NET 6 RC1の利用メモ

.NET 6 RC1が来た

アナウンスブログ

devblogs.microsoft.com

Go Liveが付与

RC1でgo liveが付与されているためProduction環境にて利用可となりました。

VisualStudio2022 ダウンロード(Preview4から)

visualstudio.microsoft.com

SDK ダウンロード(通常vs2022 Preview4を入れれば入ってくるはず)

dotnet.microsoft.com

NU1605がBuild時に上手くいかないケースがある

自分が遭遇した現象

ダウングレード問題

csprojに追加するもの

VisualStudio2022で利用している拡張機能をまとめる

OpenonGitHub

VSColorOutput64（64bitになったためか後ろに64がついた）

GitDiffMargin

ProductivityPowerTools2022

Open in Visual Studio Code

TypeScript 4.7.4 for Visual Studio

Github Flow の機能開発branch部分は好きに運用しろというスタンスだと思っている

そもそもgithub flow is 何

release branchが欲しくなる

PRレビューを小口化するためのルールについても形式化したくなる

customed branch model figure

about customed branch model

前提条件

feature integration branch は 形式化したい人向けのoptionalなルート

開発中の機能をmainに合流させたいケースを考える

release branchの存在意義について

まとめ

Swashbuckle.AspNetCore.SwaggerでSwaggerUiのRootPathを変更したい

UseSwaggerUIのSwaggerUiOptionsのRoutePrefixにサブディレクトリを設定する

UseSwaggerUIのSwaggerUiOptionsのRoutePrefixにサブディレクトリを設定するコード例

Swashbuckle.AspNetCore.Swaggerでswagger.jsonのRootPathを変更したい

UseSwaggerのSwaggerOptionsのRouteTemplateの頭にサブディレクトリを付与する

UseSwaggerのSwaggerOptionsのRouteTemplateの頭にサブディレクトリを付与するコード例

プロジェクト管理の書籍、久しぶりに読む

プロジェクト is 何

プロジェクトマネージャー is 何

推進力の把握

顧客からみたプロジェクトの推進力のリスト

プロジェクトの制約条件

Projectに過剰な制約条件を課そうとするスポンサーに対処する

.NET 6 RC1が来た

アナウンスブログ

Go Liveが付与

VisualStudio2022 ダウンロード(Preview4から)

SDK ダウンロード(通常vs2022 Preview4を入れれば入ってくるはず)

feature integration branch は形式化したい人向けのoptionalなルート

　Projectに過剰な制約条件を課そうとするスポンサーに対処する