Contents
そもそもDevOpsとは何か？
開発側（Development）と運用側（Operations）の連携を緊密化しつつ、柔軟・迅速・高品質な開発を可能にするソフトウェア開発技法 or 開発体制
DevOpsの主要な構成要素
- 自動化
- インフラ構築の自動化
- テストの自動化
- デプロイの自動化
- 効率化
- 継続的インテグレーション（CI）
- 継続的デリバリー（CD）
- チーム開発体制
- 運用モデルに基づくバージョン管理
- チケット駆動開発によるタスクの明確化
DevOpsが実現されていないと何が困るのか（Salesforceの場合）
自動テストが組まれていないために…
- 新しく機能を開発しても、それをそのまま本番環境にリリースして問題が発生しないことを保証できない
- 結果として、本番環境リリースしても問題ないかの検証・テストにそれなりの期間と工数がかかる
- 本番環境リリースに成功しても、それによりメタデータ・ロジックの複雑化が進行し、次回の新機能リリースの際に、更なる検証工数・テスト工数がかかる
パッケージによるバージョン管理がなされていないために…
- 問題が発生した際のロールバックができない
- ロジックのバージョンの履歴が後から追跡できない
- メタデータ同士の依存関係が複雑化（HappySoup問題）
ソース管理がSoTではないために…
- （バックアップのない）メタデータを上書きされると復旧不可能
- 変更履歴の追跡ができない
- ロールバックができない
- 用途に応じたコードの管理ができない（key：ブランチ）
- レビューの可視化ができない（key：プルリクエスト）
- レビューの実施を回避可能である
- チケット管理ツールとの連携ができない
- CIツールとの連携ができず、自動テストが実行できない
開発ライフサイクルがスムーズに構築されていないために…
- エンジニアの人数が増えるに従って、コミュニケーションコストが増加し、開発効率が低下する
- コードレビューが実施されないケースが発生する
- 開発作業の割り振りの漏れが発生する
- 開発作業の遅延の把握に時間がかかる
DevOpsの有効性を示す有名な事例
- Amazonの新機能リリース頻度：23,000回（一日あたり）
- Googleの新機能リリース頻度：5,500回（一日あたり）
- 平均的エンタープライズ企業の新機能リリース頻度：1回（九ヶ月あたり）
→開発速度に621万倍の差
情報源：Gene Kim, Kevin Behr, George Spafford, The Phoenix Project: A Novel about It, DevOps, and Helping your Business Win (IT Revolution Press, 2013), 380.
SalesforceにおけるDevOps
■The 5 pillars of Salesforce DevOps from “An introduction to Salesforce DevOps”
- Version control：Git
- Automation：CI/CD, Static Code Analysis, E2Eテスト
- Testing ：Apex Unit Test, UAT, E2Eテスト
- Backup：データとメタデータのバックアップ
- Culture：開発者全員がDevOpsを利用可能な状態を実現する
■開発モデルにおけるDevOpsの漸次的採用（参考：「覚書 – DevOpsケイパビリティの漸次的向上」）
- 組織開発モデル（ソース管理なし）：Gitなし。変更セットでのリリース。
- 組織開発モデル（ソース管理あり）：Gitをbackup的に利用するパターン
- ソース駆動型開発（CI/CDあり）：Gitベースの開発。
- パッケージ開発モデル（Happy Soup）：ロック解除済みパッケージで全てのdeltaをカバー
- パッケージ開発モデル（パッケージ間の依存関係の制御あり）：論理的な単位（＝アプリケーション単位や業務単位）でメタデータを適切に分割
ソース駆動型開発への手引き
■利用ツールの例
- IDE：VS Code & Salesforce Extensions
- CLI：Salesforce CLI
- ソース管理：Github
- CI：Github Actions
補足：ソース管理とCIにBacklogとCircle CIを利用する組み合わせは若干レガシー化しつつある。
■組織戦略とブランチ戦略
- エンタープライズでない限り、ブランチ戦略はGithub Flowでよい。
- エンタープライズの場合は、Git Flowを利用する。
■SalesforceでのCIにあたって知っておくべきこと
周知の通り、Salesforceはクラウドサービスのため、一般的なアプリケーションと異なり、ローカル環境や仮想環境で動作しない。
そのため、CI（自動テスト）においても、一般的なアプリケーションのようにCIサービスが提供する仮想マシン（Ubuntuなど）上でSalesforceを直接動作させることができないため、「別で用意したSalesforce環境に認証を通して、そこに対してコードの仮デプロイ・テスト実行を行う」CI手順となる。
この際、「別で用意したSalesforce環境」として以下の二つの選択肢があり得る。
- 既存のSandbox環境
- （CIのジョブにより作成される）スクラッチ組織
理想的にはスクラッチ組織を用いることが望ましいが、事情（ロジックがデータに依存している場合にデータを含んだ組織作成を実装する難易度・スクラッチ組織の作成上限数・外部システム連携との疎通テストの実行にあたり認証周りの兼ね合いで組織が変わると困るなど）がある場合は、既存のSandbox環境を利用する。
■CI（自動テスト）のサンプルコード
- 既存のSandbox環境を利用するパターン
「Github – salesforce-ci-cd-org-dev」by Pablo Gonzalez - スクラッチ組織を利用するパターン
「Salesforce Continuous Integration with GitHub Actions」by Shun Kosaka
補足：SKさんは神
参考 – 古典的なSalesforceの組織戦略
補足①：特にlargeにおいて機能開発を行う組織の種別が（スクラッチ組織ではなく）Developer Sandboxである点が古典的
補足②：実体験ベースで言えば、上記の組織戦略はわざわざ覚えずとも、自然に最適解として行き着く。つまり、小規模開発ではSandbox一個で困らなかった状況が、規模が大きくなるにつれて変化し、「開発環境とテスト環境が同じだと、競合が発生してテストができないので、組織を分けたい」・「品質担保する環境がほしい・本番リリースにあたりメタデータとデータが完全に本番環境と一致する環境で事前にValidationを行いたい」などのようにニーズが自然発生してくる。
参考 – Gitのブランチ戦略
DevOps周りのおすすめリソースなど
「A Guide to Git (and Version Control) for Salesforce Developers」
「Salesforce Architects – Migrate Changes」 ※現在は削除されてしまっている模様