本稿で紹介するセッションの動画やスライドが閲覧できます
ガラパゴスな開発手法からの脱出
セッションでSalesforce DXの紹介を行ったのは、セールスフォース・ドットコムでプロダクトマーケティング シニアデベロッパーエバンジェリストを務める岡本充洋氏。同氏はSalesforce DXが開発された背景から話を始めた。
Salesforce Platform上で動作するアプリケーション（以下、Salesforceアプリ）の開発は、これまでSalesforce Wayとも呼ばれる独自の方法で行われることが多かったという。これは、いわばガラパゴスな開発手法であり、他のプラットフォーム上で近年行われているモダンなソフトウェア開発からは遠いものだった。米Salesforceは2011年にPaaSベンダの「Heroku」を買収したが、Herokuの創業メンバーであるAdam Wiggins氏が掲げた「12 Factor App[1]」などをはじめとするモダンなソフトウェアデリバリに必要な要件を、Salesforce自身が満たしていなかったのである。
また、Salesforceアプリの開発では「正しいコード」、つまり継続して更新していくべきコードはOrg（ランタイム環境）中にあると考えることが多いのだという。しかし、本来はソースコード管理システムの中にあるものが正しいコードでなくてはならない。
「Salesforce DXはそういったところから変えていくことを目指しています。単一のOrgを開発者が共有するのではではなく、開発者単位でOrgの生成と破棄を自由にコントロールするのです。そのために、チーム開発および継続的デリバリーをサポートするサービスを提供する、開発生産性の向上や他システムとの連携を容易にするCLIツールを提供する、といったことが考えられています」（岡本氏）
ソースコード駆動で素早い開発とデプロイ、オープンで業界標準に準拠した開発フローの取り込みと実現。Salesforce DXのリリースは、ガラパゴスからこうしたモダンな開発への船出となるようだ。
なお、岡本氏が「基本的にはさまざまなツール、さまざまな考え方、サーバサイドのAPIなどをつなぎ合わせた集合体と捉えている」というSalesforce DXの機能群を表しているのが、次のスライドである。
この後には、Salesforce DXが提供する各機能の紹介に話が移っていく。
注
[1]: [https://12factor.net/](https://12factor.net/)。日本語訳はこちら。
ソース駆動開発――コードとメタデータをバージョン管理システムへ
Salesforceアプリの他にない特徴の一つに「エンドユーザーによるカスタマイズ」がある。業務向けが多くを占めるSalesforceアプリならではかもしれないが、設定により業務に合わせて挙動や出力などを変えられる柔軟な仕組みをSalesforce Platformは提供している。ユーザーが行った設定はメタデータとしてサーバーに保管される。
「例えば、開発者がメタデータを使って作成したレポート書式を、ユーザーさんがちょっと変えました。よくある話です。そうなると“正しいソースコード”というのは、ユーザーさんが変更したSalesforce側のレポートのメタデータになるわけです。そうすると、それはバージョン管理システムに取り込まなくてはいけない」（岡本氏）
この状況でソース駆動開発を行うためには、開発者の記述したコードだけでなく、本番環境にあるメタデータもいっしょにバージョン管理しなければならない。そのため、Salesforce DXではTooling APIなどが拡張され、ソースを同期するための「ソースシンクAPI」がリリースされる。これまでは開発者（ローカル）側とSalesforceアプリが稼働するサーバー側とで相互にメタデータなどをやりとりするためのAPIが提供されていたが、これをさらに拡張した形だ。
ソースシンクAPIにより、開発者が提供した初期設定とエンドユーザーがカスタマイズしたメタデータのどちらが最新かを判断し、バージョン管理システムで一括管理することができるようになる。例えば、使い慣れたGitHubでコードを管理し、チーム開発をスムーズに進めるといったことも可能となる。
Salesforce CLIの提供
しかし、APIだけを提供されても、それを扱うためのクライアントツールがないと非常に扱いづらい上、ツールを自作しなくてはならない。そこで、APIを利用しやすくするためのCLI（Command Line Interface）が開発者向けに提供される。
Salesforce CLIがどういう形でリリースされるかは、今のところ未確定だが、岡本氏によれば「HerokuのCLIのプラグインとして提供されるというのが、開発チームの間で最も有力な流れ」だという。開発者プレビュー版が一部のデベロッパーに開放されているが、そこでは、Herokuコマンドに対してプラグインをインストールするというような形で、Salesforce CLIが実現されているそうだ。
Salesforce CLIでは、Orgの作成と削除、ソースコードのpush、データのインポート、テストの実行など、ひと通りの作業ができるようになっている。このCLIを利用すれば、Jenkinsなどの既存のCIサービスなどとの連携を構築する際にも簡単に行える。
Scratch Orgs――アプリの新規作成／削除が容易に
モダンなソフトウェア開発の要件の中には、ソフトウェアのスクラップアンドビルドが容易であることも条件として含まれていた。たとえ、本番ランタイムとローカルファイルシステムの間でソースコードなどを同期するAPIが提供され、そのAPIを利用するためのCLIが提供されたとしても、実際にコードを動かす開発環境の新規作成や破棄を容易に行えなくては、ライフサイクルは改善されない。一度構築した開発用ランタイムを破棄せずにずっと更新していくという、従来のSalesforceのスタイルは、まず変革したいところだろう。
そこでSalesforce DXで提供されるのが「Scratch Org」である。Scratch Orgは、開発者がSalesforceランタイム環境を自由に作成し、破棄することを可能にする機能だ。コマンドラインからでも、GUIからでも利用できる。
「（スライドには）ソースコードからスピンアップと書いてありますが、これはソースコードからの環境構築が可能だという意味です。Salesforceの環境を構築するときには、Developer EditionでもEnterprise Editionでも、一部の例外を除いて、Webページ上で名前を入力し、サインアップして、組織ができあがったらメールアドレスに通知を受け取る、という手順を踏む必要がありました。Salesforce DXからは、コマンドラインを叩くだけで環境ができあがり、それにアクセスするというイメージになります」（岡本氏）
Scratch Orgは、Salesforceアプリ開発者がこれまで手に入れることのできなかった開発の敏捷性（アジャイル）を提供することになるだろう。
継続的デリバリーと継続的インテグレーション
Herokuには、HerokuパイプラインやHerokuフローなどと呼ばれる機能がある。この機能は、GitHubと連携して効率的に開発のサイクルを管理する。具体的には「Pull Request単位でMerge前に自動ビルドする」「MergeされMaster Branchが更新されたら、ステージング環境を自動ビルドする」といったことをWebHooksを利用して実現する。
このHerokuの機能を使って、Salesforceアプリのコードのライフサイクルを管理しつつ、Salesforce Platformに自動的にデプロイするという機能を実現する計画が進められているという。これにより、Salesforceアプリ開発の世界にも、継続的デリバリーがもたらされる。
また、Salesforceアプリの継続的インテグレーションも実現に向けて作業が進められている。継続的デリバリーは主にリリースの自動化が目的だが、こちらはソフトウェアテストの自動化が主な目的である。
まず、Herokuは「Heroku CI」という独自のCIを今後リリースする予定だという。当然ながら、Heroku CIでは将来的にApex[2]のテストなどをサポートする。一方で、Heroku CIの機能でなく、Jenkinsをはじめとする外部のCIツールを連携する機能も実装される。JenkinsにはApexのテストを実行し、その結果を受け取るためのプラグインがあるので、それによりApexのテストを自動化することも可能となっている。
「こうした環境が整えば、かなりのテストをSalesforceアプリ開発でも自動化できます。それも、Salesforceだけで通用する特殊なやり方ではなく、皆さんがNodeやJava、Rubyなどで開発されているときのコンテキストや作法に沿って、すべてセットアップすることができる。これは重要なことだと思っています」（岡本氏）
注
[2]: ApexはForce.comでのアプリケーション開発に用いられる専用のプログラミング言語。
Salesforce IDEとアプリパッケージ
バージョン管理システムから継続的デリバリー／インテグレーションまで、開発をアジャイルに進めるための各種機能がそろうと、次はそれらに統合的にアクセスするための統合環境が欲しくなる。Salesforceアプリの開発環境には「Force.com IDE」が使われているが、これも新しい開発手法に適合する方向で機能拡張される。今までのForce.com IDEは、プラグインをインストールするとForce.comプロジェクトというものを作り、特殊なワークスペースを作成するなど、独自の作法を持っていた。
Force.com IDEの新バージョン2.0では、GitリポジトリをCloneしたプロジェクトに対して、Salesforce CLIコマンドをEclipseの中から実行可能になるという。これにより、ここまでに紹介されてきたさまざまな機能やツールをIDEから簡単に使えるようにする。
また、開発したものを広く配布しやすくするための新しいパッケージング機能「Packaging 2.0」の開発も進められている。Salesforceアプリを配布するための管理パッケージは、最初に名前空間を設定し、その中に作成するという手順になっていた。しかし、この方法では1つの名前空間に1つのアプリしか作成できず、不便を掛けていたという。Packaging 2.0では1つの名前空間の中に複数のアプリを作成可能にして、この問題を解決する。
ベータ版が6月、GA版が10月にリリース予定
セッションでは、岡本氏によるSalesforce DXのデモンストレーションも披露され、Salesforceアプリの新しい、モダンな開発方法に会場の参加者も期待を大きく膨らませているようだった。
最後に、Salesforce DXのリリース予定などが明らかにされた。Salesforce DXは現在、非公開プレビュー版が一部のデベロッパーによってテストされている段階である。2月になると、早期プレビューへ申し込んだ人たちに非公開パイロット版が配布され、開発者プレビューができるようになる。6月には公開ベータ版となる見込み。なお、パイロット版は下位互換を保証しないため、プロダクションでの使用は難しい。ベータ版はプロダクションへの組み込みを前提で検証しても構わないが、バグが残っている可能性があるという。新機能を確認するだけならパイロット版で、実業務への使用を検討するなら6月まで待ちましょう、というのが岡本氏からのメッセージ。
「10月あたりにはGA版（正式版）のリリースという予定ですが、変更の可能性もあり確約はできませんが、このような流れになっていますので、もうすぐ皆さんのお手元でもSalesforce DXが使えるようになります。そのときには、Salesforce DXをぜひ触ってみてください」（岡本氏）
GiuHubとの連携強化
なお、このセッションでは途中から、GitHub, Inc Solutions Engineerの池田尚史氏も登壇した。「SalesforceならびにHerokuでは、一番最初につなぎ込んで使用するリポジトリとしてGitHubを選んでいく」（岡本氏）ということが背景にある。
池田氏からは、GitHubで一番特徴的な機能である「Pull Request」を利用した開発フロー「GitHub Flow」などの解説があった。GitHub Flowでは、新規開発でもバグの修正でも、いきなりマスターブランチにコードを入れたりせず、まずは開発メンバーが各自のブランチを切って作業を進める。コード管理で混乱を生じさせないためだ。開発メンバーが各自のブランチ上で作業したら、まずはそのレビューを依頼するために担当者へ連絡を入れる。それがPull Requestである。レビューが済んだら、その内容をデプロイし、実際に動作を確認する。それで問題なければ、最後にマスターブランチにマージする。
また、Pull Requestを中心としたGitHub Flowの開発スタイルの中で、重要かつ近年では必須のプラクティスとして現場で行われているのが、Herokuによる継続的デリバリーの説明でも触れた「Pull Requestに対するCI」だという。
「Pull Requestに対するCIっていうのはとても重要です。マスターブランチの最新コードと、Pull Requestブランチの最新のコードを、CIサーバー上でマージしてテストを実施する。これによって、Pull Requestをマージする前に、マージしたらどうなるかを、機械的に保証できます」（池田氏）
現場ではツールの進化とともに、それを活用するノウハウが次々に生まれ、生産性などを高めている。そのことを実感できる例といえるだろう。
