GitLab

目次

認証システムと書いたが、承認システムの間違いなわけだが、そんなことはさておき、

Gitの特徴

Gitは、ブロックチェーンと以下の点で似ているとおもう。

GitLabの特徴

GitLabのマージリクエストは、承認者が承認することと類似していると思う。

車輪の再発明になっていないか?

よのなかに、承認システムを開発する場合がある。(自分が、最近そういうプロジェクトに参画していた)。「すでにあるシステムの見方をかえれば、作らなくていいんじゃないか?」と思ったのがこの記事を書く動機なのである。プロジェクト参画時は、それでお金を頂いていたので、この考えは封印していたのだが、いま改めて考察を進めていこうと思った次第である。

この記事には数億円以上の節約効果があるとかんがえているし、

IT人材の不足を、車輪の再発明を防ぐ的なアプローチによって、世の中の人材不足を緩和することにつながるとかんがえている。

簡単な申請・承認のモデルケース

以下の簡単なモデルケースを考えてみる

申請者がいて、1次承認者、2次承認者がいるとする。

これって、GitFlow?でたとえると、ブランチの構成が

というふうに見方を変えるだけの話ではないだろうか?

ハンコを押すという行為が、マージするという行為に代わる。

申請内容がダメな理由を書いてマージしなければ、差戻しという行為であると見なすこともできる

だれが許可したのかも履歴が残るので改ざんできない。

現状、紙で運用している会社があったとして、簡単にデジタル化するのにつかえるか考察する

承認者1が承認した、つまりdevelopブランチにマージされたとして以下の手順に進む

ん-これだと、developブランチにまとまった承認が一括で承認者2へ承認依頼となる。

解決案

developブランチの守備範囲が大きすぎるのが問題だ。以下のようにルールを決めれば解決する。

この場合の承認者1の仕事をイメージしてみる

develop_xxxxへのマージリクエストだけを承認対象とする

マージしたdevelop_xxxブランチを承認者2がマージ権限を持つmainブランチに対するマージリクエストを出す

この場合の承認者2の仕事をイメージしてみる

develop_xxxxからのマージリクエストだけを承認対象とする

このやり方のメリット

このやり方のメリットは、あらゆるフォーマットに対応しておりgitlab以外のシステム構築は不要ということだ。

gitlabはユーザ数に制限がほぼないから維持費も安い

GitLabでissueとよばれているドキュメントには、関連するissueを記載すると、そのissueのステータスがどのようなステータスになっているのか表示してくれるので、 状況がつかみやすい。

issueというドキュメントは表現が豊かなので、補足説明などしやすくなる。

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2022-11-03 (木) 11:26:45 (85d)