Salesforce DXがGAになりました

　今年のDreamforceも多くの最新機能が発表されていますね。去年は、Dreamforceに初めて参加させて頂きまして、世界中の開発者の熱気を感じて更に仕事への意欲を高める良い機会となりました。今は遠く離れた日本でSalesforce Liveで会場の雰囲気を感じている川口です。
　SalesforceDXがWinter'18でとうとうGAになりました。去年の10月にDreamforceで紹介されて、２月にClosed Pilot、６月にOpen Beta、そしてやっと10月のWinter'18でGAになりました。私はこんなに１つの機能に長く携わったのは初めてです。
　社内では、GAに伴いプロジェクトに適用しようと試行が始まろうとしています。これまで検証し準備を進めてきた私達にとって、これからがSalesforceDXを適用するために一番の頑張らなければいけないところです。
　なので、その前に意気込みを含めて準備してきた開発フローや今後の取り組みについて説明し、読んでもらえた開発者やお客様が「私の担当するプロジェクトでSalesforceDXをぜひ試したい！」と思って頂けるように書きたいと思います。

　もうすでにSalesforce界隈で話題になっているSalesforceDXなので、今更説明はいらないと思いますが、開発フローや今後の取り組みを話す前に、前提知識として少しSalesforceDXの説明をします。
　まず、SalesforceDXのDXという意味は「UX for Developers：開発者のユーザエクスペリエンス」から来ています。
　そして、SalesforceDXは、Salesforce開発者の生産性を高める機能や開発手法の総称です。
　下の図では、その機能や開発手法ついて説明されています。そして、SalesforceDXで一番強調すべきコンセプトはソース駆動開発です。今までは組織の中のものが正として考えていたものが、ソースリポジトリの中のものが正しいという考え方に変わりました。そのことにより今まで組織をカスタマイズする開発が、これからはソースを共有して開発する方法に変わりました。
　次に、ビルドやデプロイをすばやくできる仕組みや、チーム開発できる仕組み、継続的デリバリーや継続的インテグレーションの実現できる仕組み、オープンで標準的な開発をする手法などが提供されています。

　次にメリットです。品質、生産性、変更管理、開発方法の観点でまとめました。
　SalesforceDXから提供される機能以外にも、オープンで標準的な開発に使われているサービスも組み合わせて得られるメリットです。

バージョン管理システム関連の機能で得られるメリット
① ソース上書きの防止
② タスク（機能やバグ）とソースコードを関連付けた管理
③ プルリクエストで必ずレビューする環境を構築
④ ソースを常に動く状態に保つ

Salesforce CLIで得られるメリット
① ビルドのスクリプトに静的構文チェックツールを組み合わせて品質チェック
② 各開発者のエディタとCIサーバで、自動品質チェックする環境を構築

エディタで得られるメリット
① 静的構文チェックのLinterやプラグインで品質チェック

スクラッチ組織で得られるメリット
① 他の組織に影響を与えずに気楽に追加機能の開発
② データまで準備された環境が作れるので新機能評価で余計な設定やゴミを残すことがない

Salesforce CLIで得られるメリット
① ビルドのスクリプトを自動化

その他に得られるメリット
① 使い慣れたエディタを自由に選ぶことができる
② 一度ログインされた組織は、ログインを省略してアクセスできる

バージョン管理システム関連の機能で得られるメリット
① 短いサイクルで手戻りが少なくバグの混入を防ぐリリース

アーティファクトベース開発で得られるメリット
① 都度変更セットでリリース対象を選択する必要がなくなる
② 品質保証されたバージョン単位のリリース
③ アーティファクト毎に独立したリリース
④ 他のアーティファクトに依存しない設計
⑤ 各組織のアーティファクトをバージョンで把握

　モダンなソフトウェア開発の要件として、JavaやRubyなどのオープンで標準的な開発のベストプラクティスを取り入れられる開発を、Salesforce開発として選択できるようなったのは、複数のシステムを持つお客様にとってビルドプロセスを合わせるなど色々な部分でメリットになるのではないでしょうか。
　そして、マイナーリリースやメジャーリリースなどのリリースの種別や規模に応じて開発方法の選択肢が増える事もメリットがあると個人的に考えています。
　以上がメリットです。

　それでは、私たちが考えているSalesforceDXの開発フローについて説明します。
　下の図は、現在想定しているSalesforceの標準の開発フローです。今後、試行を進めていく中で変更や修正を加えていきます。

図の矢印の①~⓽までのプロセスについて説明します。
①　新規開発以外に既存の開発をSalesforceDX形式に変換し、アーティファクトを作成します。作成したアーティファクトをリモートリポジトリに登録します。
②　各開発者のローカルにクローンし、機能（チケット）毎のブランチを作成します。
③　開発者が開発したソースをスクラッチ組織にプッシュし単体試験を行いながら開発を進めます。
④　動く事を確認したソースをリモートリポジトリにプッシュします。
⑤　リモートリポジトリの各ブランチにプッシュされたタイミングで、Jenkinsがスクラッチオルグを作成し自動デプロイとテストを実行します。ジョブの結果を関係するユーザに通知します。
⑥　開発者は単体試験まで完了したら、リモートリポジトリの機能毎のブランチにプッシュし、プルリクエストで変更管理に通知します。
⑦　変更管理者はレビューを実施し問題なければ開発ブランチにマージを行います。開発ブランチがプッシュされると、JenkinsがQA組織に自動デプロイとテストを行います。
⑧　設計者-PLは各試験を完了し、Jenkinsを使って手動で開発ブランチをUAT組織にデプロイします。
⓽　エンドユーザがUATを承認後、変更管理者がマスターブランチにマージして、プッシュするとJenkinsがProduction組織にデプロイします。
※図ではJenkinsで自動デプロイをしていますが、プロジェクトによって手動に変更する場合があります。

　今まで利用している環境も利用しつつ、SalesforceDXで必要な機能を拡張していきます。

SalesforceDXでは、開発フローを回す上で必須な機能は以下の機能を考えています。
① リモートリポジトリにプッシュされるタイミングで自動テストやデプロイの実行
② 自動テスト環境のスクラッチ組織の作成、削除
③ 自動テストでは、ユニットテスト以外に画面テスト、構文チェックを実施

　その他に機能拡充として公開されているツールを組み合わせながら、生産性や品質を高める機能を実装していきます。また、現在、KPIを測定するインフラの整備をしているので、プロジェクト全体の品質をタイムリーに早期検知する仕組みを強化出来たらと考えています。

　いかがだったでしょうか？「SalesforceDXで開発してみよう！」と思っていただけたでしょうか？そう感じていただけたら幸いです。そして、是非、「試行したい！」という方がいればお声がけください。
　今回は、試行前の概要的な説明だけだったので、すでに導入しているプロジェクトの担当者にとっては、もう少し運用の情報が欲しかったと思います。今後、得られた情報を一つ一つ説明できたらと考えています。
　最後まで読んでいただきありがとうございました。それでは！