SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

イベントレポート(AD)

Salesforceアプリ開発をオープンに――API/CLIによる操作や、GitHubと連携したCI/CDを実現するSalesforce DXとは?

「Salesforce World Tour Tokyo 2016」開発者向けセッションレポート

  • このエントリーをはてなブックマークに追加

Salesforce IDEとアプリパッケージ

 バージョン管理システムから継続的デリバリー/インテグレーションまで、開発をアジャイルに進めるための各種機能がそろうと、次はそれらに統合的にアクセスするための統合環境が欲しくなる。Salesforceアプリの開発環境には「Force.com IDE」が使われているが、これも新しい開発手法に適合する方向で機能拡張される。今までのForce.com IDEは、プラグインをインストールするとForce.comプロジェクトというものを作り、特殊なワークスペースを作成するなど、独自の作法を持っていた。

 Force.com IDEの新バージョン2.0では、GitリポジトリをCloneしたプロジェクトに対して、Salesforce CLIコマンドをEclipseの中から実行可能になるという。これにより、ここまでに紹介されてきたさまざまな機能やツールをIDEから簡単に使えるようにする。

Salesforce IDE
Salesforce IDE

 また、開発したものを広く配布しやすくするための新しいパッケージング機能「Packaging 2.0」の開発も進められている。Salesforceアプリを配布するための管理パッケージは、最初に名前空間を設定し、その中に作成するという手順になっていた。しかし、この方法では1つの名前空間に1つのアプリしか作成できず、不便を掛けていたという。Packaging 2.0では1つの名前空間の中に複数のアプリを作成可能にして、この問題を解決する。

Packaging 2.0
Packaging 2.0

ベータ版が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をマージする前に、マージしたらどうなるかを、機械的に保証できます」(池田氏)

 現場ではツールの進化とともに、それを活用するノウハウが次々に生まれ、生産性などを高めている。そのことを実感できる例といえるだろう。

GitHub, Inc Solutions Engineer 池田尚史氏
GitHub, Inc Solutions Engineer 池田尚史氏

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
イベントレポート連載記事一覧

もっと読む

この記事の著者

市古 明典(編集部)(イチゴ アキノリ)

CodeZine編集部3年目の44歳。宝飾店の売り子、辞書専門編集プロダクションの編集者(兼MS Access担当)を経て、2000年に株式会社翔泳社に入社。月刊DBマガジン(休刊)、IT系技術書・資格学習書の編集を担当後、2014年4月より現職。9月から翌年2月まではNFL観戦のため、常時寝不足。...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/9902 2017/01/24 15:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング