Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

業務システムの開発プロセスと、モダンなバージョン管理システムの機能のインピーダンスミスマッチ

ISO 12207、ISO 9126、IPAの情報システム・モデル取引・契約書のような契約に基づくシステムの開発プロセスって、モダンなバージョン管理システムで管理できるんだろうか? たとえば以下のような仮定を置いた場合に、ソースコードに対する変更はどのようにモデル化され、それがバージョン管理システムの機能のうえにどうマッピングされるのか?という話。

  • 全体をサブシステム毎に分けて、明確な責任分界点や工程毎の期限を設け、発注単位毎の独立性を保ったうえで開発・テストを進める
  • 自身の責任分界点の外側のソースの内容を理解することは求められていない
  • 作業者間で相互の信頼に基づく情報の共有は行われない
  • 変更はCCBからの命令に基いて行われており、その命令以外の変更は入っていたらダメ
  • 複数の命令を一つの変更にまとめて実施してはならず、命令と変更とは一対一対応する必要がある
  • 複数のテスト環境のうえでテストと変更が同時に行われており、「最新のソースコード」と「各テスト環境にデプロイしたいソースコード」が一致しない(その時点で最新のソースコードのうち、テスト環境ごとに入っていてよい変更と入っていてはいけない変更とが存在する)
  • 最終的にデプロイされるソースコードの正当性は開発者とは別のCCBが確認するが、CCB自身はソースコードの変更は行わない

たとえばSubversionのmoderator機能や、バージョン管理システムそのものではないけれどGitHub/GitLabのPull Request/Merge Request機能はCCBによる確認に使えるかもしれないが、mergeの際のconflictの発生を回避するためにどのような運用になっている必要があるか?とかは検討されていないのでは。