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