Contents
概要
表題について評価する。
比較対象
①変更セットを用いた組織開発モデル
②DevOpsCenterを用いないソース駆動型開発
各開発モデルにおけるDevelopment & Deployment Process
- 組織開発モデル with 変更セット
- チケットを作成 on チケット管理ツール
- Sandboxで開発
- 変更セットを用いてデプロイ
- ソース駆動型開発 with CI/CD tool
- チケットを作成 on チケット管理ツール
- 開発用組織で開発
- 変更をリモートリポジトリにpush on ローカルPC
- 継続的インテグレーション on CI/CD tool
- プルリクエスト on Github
- 手動レビュー & マージ on Github
- 継続的デプロイメント on CI/CD tool
- DevOpsCenter
- 前提：Pipeline設定（組織・Branch）
- WorkItem（＝チケット）を作成 on WorkItem
- 開発用組織で開発
- “Commit Changes” on WorkItem（→Stagingブランチに自動push）
- 継続的インテグレーション on CI/CD tool
- “Create a Review” on WorkItem（→Stagingブランチへのプルリク自動作成）
- “Ready to Promote”にステータス変更 on WorkItem
- “Promote” on Pipeline（→Stagingブランチに自動マージ+ Staging組織に自動デプロイ + 上位のブランチに自動push）
DevOpsCenterを用いた開発の特徴
- VCSに関連した操作が一切不要である（すなわち、ローカルPC上でデルタをpushしたり、Github上でPull Requestを作成・マージする必要がない）
- メタデータのリリースをWorkItemに紐づけて行う必要があり、「チケット駆動型開発」を前提とした作りとなっている。
DevOpsの良い点・悪い点
■良い点
・VCS（Git）に慣れていない人でも簡単に「チケット駆動型の開発ライフサイクル」・「ソース管理」を実現できる。
・（Reviewフェーズを飛ばしてPromoteできないため）Review実施に関して一定の強制力がある。
■悪い点
・（完全にDevOpsCenterベースで開発することを前提とした場合）CLIと比べてCommit頻度が格段に落ちることが予想される
→つまるところ、Version ControlがLocal内で実施されるかという観点で見た場合、最新バージョンのSubversionとGitの相違に似た話に帰着する。
・デプロイがUnlocked Packageベースではないので、Unlocked Pakageベース開発の比べると機能が圧倒的に貧弱（例：パッケージのバージョン管理・パッケージの階層構造・ロールバック）
結論
Unlocked Packageベースのパッケージ開発モデル
サードパーティーDevOpsサービス（Copado, GearSetなど）
===越えられない壁===
DevOps Center
メタデータAPI
===越えられない壁===
変更セット
※通常のソース駆動型開発がどこに位置付けられるかは、頑張り具合による。