この記事はLIFULL Advent Calendar 2018の17日目の記事になります。
こんにちは。LIFULLでSalesforceエンジニアをしています。@ohbashです。
2年ほど前までは、片手で数えられるほどのSalesforceの開発者も、いまではパートナーさんも含め20名強にまで増えています。
拡張開発のスピードも格段に上がっており、今後も開発部署が増えていくであろうことが予想されます。
今回は、そんなSalesforce開発の管理体制に関するお話です。
#前提
一般論っぽいタイトルにしていますが、弊社で行なっている管理方法をピックアップして共有する記事になります。
現在弊社で使っているメインの組織では、"利用ユーザー数は1000人ほど"、"コミュニティユーザーは数万人"、"ステークホルダーは全社"に渡るなど、規模が拡大しています。
リリース頻度も週に1回程度、タイミングが重なると3回・4回といった具合です。
当然、規模とステークホルダーの多さ、開発スピードによって、有効な管理方法が変わってくると思います。
弊社での実施内容がその一例として参考になれば幸いです。
#① 変更諮問
Salesforceの本番環境に変更を加える時は、開発部署が事前にチケットを作成し、変更諮問委員会で協議をする運用をしています。
開発のたびに「変更諮問」って、お役所かよって思っていました。
しかしSalesforce開発では、一般的なweb開発にくらべ、一つの箱（オブジェクト）にレコードタイプを分けて、別の用途の情報を格納するため、他用途への影響を考えて全体で統制を取る必要が出てきます。
実は過去に、改修スピードを保ちながら他に干渉が無いように、カスタムオブジェクトを多用して開発をしていた時期がありました。
結果として、同じような意味合いのカスタムオブジェクトが複数でき、組織の流動に耐えられなかったり、標準オブジェクトへの機能追加の恩恵を受けられないという問題が発生しました。
現在は見直しを図り、出来るだけ標準オブジェクトを使っていく方針で、ひとつの改修で他の利用者に影響がでないようにコントロールをしています。
また、変更諮問の役割として権限周りの統制も重要です。
変更を加える際に、この情報は誰が見えて良くて、誰には見えちゃダメかを知っている必要があり、各施策の担当者がSalesforce組織の全容を把握しておくことは現実的ではありません。
そこも、この会議体で全体を俯瞰してみて、考慮が足りていないポイントがあれば注意を促すことをしています。
この変更諮問の体制ですが、運用を開始してから1年ほどが経ち、ノウハウも溜まってきたため、ある程度協議が必要か否かの切り分けが出来るようになってきました。
#② Sandbox運用
「技術導入検証」と「運用改修」、「大・中規模プロジェクト」を同時に進行させるには、恒常的なSandboxの運用ルールが必要になります。
現在は、下記の4種類の環境でステージングを管理しています。
- 開発者のSandbox
- 部署のSandbox
- 統合環境
- 本番環境
「開発者のSandbox」は一人の開発者に一つのSandboxを割り当ててあり、基本的には各開発者が好きに使っていいというポリシーです。
その分、動作テストの担保としては信用がおけず、テストフェーズは「部署のSandbox」を使います。
「部署のSandbox」でテストが完了すると、変更セットを使って「統合環境」にデプロイをします。
この「統合環境」は本番環境前に必ず通るステージで、全ての開発部署が共同で使います。
また、本番反映前の最終確認として、出来るだけ本番環境に近い状態を再現しておく必要があります。
3つのステージを経て、はれて「本番環境」にリリースをします。
現運用では、各環境をどれだけ最新に保つかが特に重要であり、リフレッシュの頻度がキーになってきます。
「統合環境」のリフレッシュは最低でも月に1回。プラスで大きめのリリースがあった後にはリフレッシュを実施しています。
「部署のSandbox」および、「開発者のSandbox」は出来るだけ高頻度でリフレッシュをする方針で、感覚値では2週間に１度ぐらいでリフレッシュをしています。
#③ ソース管理・デプロイ管理
Salesforceの開発機能の弱いところとして修正リソースのオートマージができず、コンフリクトに気づけないという点があります。
小規模で開発している場合は、それぞれ修正ファイルのスコープを区切ったり、情報連携をしながら開発をすることができますが、部署を分断して開発をしていると、共通リソースに手を加えるときに、他で修正をしていないかを知ることは困難です。
そこで、ソースレビューと「部署のSandbox」への反映をGitとAntを経由して行うことで、修正被りに気づき、マージ修正をかけるようにしています。
開発者は、自分の「開発者のSandbox」で変更を加えた後、Gitにソースを上げ、PullRequestとしてレビュー依頼を上げます。
レビューがOKであれば、Gitの共通ブランチにマージ権限のある人がRequestを承認し、そのままAntをつかって「部署のSandbox」にデプロイをかけます。
このフローを徹底していれば本番環境のリソースとGitの共通ブランチのリソースは一致するはずですが、イレギュラーがおこり、ファイルの内容が乖離してしまうと、この運用は破綻してしまいます。
そのため、定期的に本番環境から最新のリソースを取得して、Gitで管理しているファイル群にアップデートをかけています。
Apex・Visualforceについては、上記の運用ですが、項目の追加や設定内容の変更については、全ステージで変更セットでのデプロイをしています。
また、デグレのリスクが比較的高い、プロファイルとページレイアウトの変更は、手動で行うことが多く、些細な変更でも本番反映前には必ず「統合環境」でも同様の設定変更を行う運用です。
現在リリーサーは二人おり、チャットワークで実施予定日と修正サマリを共有するようにしています。（この辺がちょっと野暮ったい）
#今後について
管理体制の一環として、Sandboxリフレッシュ時のapex処理の追加と、Apexリソースの削除フローの構築をしようと思っています。
Sandboxのリフレッシュ時にApexクラスを起動できる機能を使って、「不要ユーザーの無効化」、「カスタム設定値を開発環境用に書換え」、「テスト用データの投入」をやりたいなと考えています。
また、Apexリソースの削除フロー構築が必要です。
現在は、本番環境への更新は変更セットか手動設定でのみ行なっているため、削除フローがありません。
「Force.com IDE」や「Ant」を使って削除することができるので、削除フローを構築して綺麗な状態にしていきたいと思います。
以上、今回の内容を（かなり強引に）まとめると、
① 変更前に全体統制とポリシーに合致するか第三者的（？）にチェックしましょう
② 変更が加わる経路を統一して整備しましょう
③ Salesforceが弱いところ（ソースのマージ機能）は、外部のツールを使って補いましょう
というお話でした。
それでは！よいSalesforceライフを。