認証システムと書いたが、承認システムの間違いなわけだが、そんなことはさておき、
Gitは、ブロックチェーンと以下の点で似ているとおもう。
GitLabのマージリクエストは、承認者が承認することと類似していると思う。
よのなかに、承認システムを開発する場合がある。(自分が、最近そういうプロジェクトに参画していた)。「すでにあるシステムの見方をかえれば、作らなくていいんじゃないか?」と思ったのがこの記事を書く動機なのである。プロジェクト参画時は、それでお金を頂いていたので、この考えは封印していたのだが、いま改めて考察を進めていこうと思った次第である。
この記事には数億円以上の節約効果があるとかんがえているし、
IT人材の不足を、車輪の再発明を防ぐ的なアプローチによって、世の中の人材不足を緩和することにつながるとかんがえている。
以下の簡単なモデルケースを考えてみる
申請者がいて、1次承認者、2次承認者がいるとする。
これって、GitFlow?でたとえると、ブランチの構成が
というふうに見方を変えるだけの話ではないだろうか?
ハンコを押すという行為が、マージするという行為に代わる。
申請内容がダメな理由を書いてマージしなければ、差戻しという行為であると見なすこともできる
だれが許可したのかも履歴が残るので改ざんできない。
承認者1が承認した、つまりdevelopブランチにマージされたとして以下の手順に進む
ん-これだと、developブランチにまとまった承認が一括で承認者2へ承認依頼となる。
developブランチの守備範囲が大きすぎるのが問題だ。以下のようにルールを決めれば解決する。
develop_xxxxへのマージリクエストだけを承認対象とする
マージしたdevelop_xxxブランチを承認者2がマージ権限を持つmainブランチに対するマージリクエストを出す
develop_xxxxからのマージリクエストだけを承認対象とする
このやり方のメリットは、あらゆるフォーマットに対応しておりgitlab以外のシステム構築は不要ということだ。
gitlabはユーザ数に制限がほぼないから維持費も安い
GitLabでissueとよばれているドキュメントには、関連するissueを記載すると、そのissueのステータスがどのようなステータスになっているのか表示してくれるので、 状況がつかみやすい。
issueというドキュメントは表現が豊かなので、補足説明などしやすくなる。