- 追加された行はこの色です。
- 削除された行はこの色です。
[[GitLab]]
* 目次 [#n23c1cc1]
#contents
認証システムと書いたが、承認システムの間違いなわけだが、そんなことはさておき、
** Gitの特徴 [#w20e1025]
Gitは、ブロックチェーンと以下の点で似ているとおもう。
- 分散管理
- 偽造がしにくい
** GitLabの特徴 [#j58ea79a]
GitLabのマージリクエストは、承認者が承認することと類似していると思う。
** 車輪の再発明になっていないか？ [#hefcae67]
よのなかに、承認システムを開発する場合がある。（自分が、最近そういうプロジェクトに参画していた）。「すでにあるシステムの見方をかえれば、作らなくていいんじゃないか？」と思ったのがこの記事を書く動機なのである。プロジェクト参画時は、それでお金を頂いていたので、この考えは封印していたのだが、いま改めて考察を進めていこうと思った次第である。
この記事には数億円以上の節約効果があるとかんがえているし、
ＩＴ人材の不足を、車輪の再発明を防ぐ的なアプローチによって、世の中の人材不足を緩和することにつながるとかんがえている。
** 簡単な申請・承認のモデルケース [#d5a1a55e]
以下の簡単なモデルケースを考えてみる
申請者がいて、１次承認者、２次承認者がいるとする。
これって、GitFlowでたとえると、ブランチの構成が
- mainブランチが２次承認者がマージ権限を持つブランチ
- developブランチが1次承認者がマージ権限をもつブランチ
- featureブランチが申請者がコミット、push権限を持つブランチ
というふうに見方を変えるだけの話ではないだろうか？
ハンコを押すという行為が、マージするという行為に代わる。
申請内容がダメな理由を書いてマージしなければ、差戻しという行為であると見なすこともできる
だれが許可したのかも履歴が残るので改ざんできない。
* 現状、紙で運用している会社があったとして、簡単にデジタル化するのにつかえるか考察する [#me7a122e]
- 手順1 資料や申請書などをスキャナーで取り込む
- 手順2 申請書をgit管理されているフォルダに格納する。
- 手順3 申請を確認する単位でブランチを作成する。マージの希望先のブランチはdevelopブランチであり、承認者１がマージ権限を持つ
- 手順4 承認者１はマージもしくは、差戻を行う。
承認者１が承認した、つまりdevelopブランチにマージされたとして以下の手順に進む
- 手順5 承認者１はdevelopブランチからmasterブランチへのマージリクエストをだす。
ん－これだと、developブランチにまとまった承認が一括で承認者２へ承認依頼となる。
** 解決案 [#qca03560]
developブランチの守備範囲が大きすぎるのが問題だ。以下のようにルールを決めれば解決する。
- ルール１ タイムスタンプなどをもとにして申請番号を決める
- ルール２ 承認者１が承認する（マージする）ブランチをdevelop_申請番号のような名称で作成する。承認者２の承認用のブランチは承認者３がいる場合は作るが、そうでない場合は、mainブランチ固定なので承認者２用のブランチは作る必要はない
- ルール３ 申請者がブランチを作る際に作成するブランチ名に申請番号を付ける
- ルール４ ブランチのマージ先の名称は、develop_申請番号
- ルール５ 申請者は上記内容のマージリクエストを出す
** この場合の承認者１の仕事をイメージしてみる [#g99106e9]
develop_ｘｘｘｘへのマージリクエストだけを承認対象とする
マージしたdevelop_xxxブランチを承認者２がマージ権限を持つmainブランチに対するマージリクエストを出す
** この場合の承認者２の仕事をイメージしてみる [#e77d528f]
develop_ｘｘｘｘからのマージリクエストだけを承認対象とする
** このやり方のメリット [#vf0eb834]
このやり方のメリットは、あらゆるフォーマットに対応しておりgitlab以外のシステム構築は不要ということだ。
gitlabはユーザ数に制限がほぼないから維持費も安い
GitLabでissueとよばれているドキュメントには、関連するissueを記載すると、そのissueのステータスがどのようなステータスになっているのか表示してくれるので、
状況がつかみやすい。
issueというドキュメントは表現が豊かなので、補足説明などしやすくなる。
