Más contenido relacionado
La actualidad más candente (15)
Similar a Salesforce World Tour Tokyo 2017 (SalesforceDX〜Salesforceにも継続的デリバリーを〜) (20)
Más de Akira Kuratani (19)
Salesforce World Tour Tokyo 2017 (SalesforceDX〜Salesforceにも継続的デリバリーを〜)
- 2. About me
Akira Kuratani / 倉谷 彰
TeamSpirit Inc.
Architect
@a_kuratani
Podcast(migration.fm)
ハッシュダグ:#migrationfm
Winter‘17
- 18. • 静的解析
• Force.com Security Source Code Scanner自動化
• PMD Apex導入
• Jenkinsでもローカルでもチェック可能
対策
• ドキュメント自動生成
• ApexDoc
• メタデータ(XML)をHTMLに変換
Notas del editor
- ご紹介いただきました株式会社チームスピリットの倉谷です。
会社ではアーキテクトをやっておりますが、プロダクト全般の品質を管理するQAリードもやっています。
Salesforce Developer Group Tokyoの運営メンバーをやっていたり、Podcastを配信していたりしたので、今年の春にSalesforce MVPに選んでいただきました。
このPodcastは、Salesforceエンジニア向けのPodcastになります。ご興味のある方はぜひ聴いていただければ嬉しいなぁと思います。
何か喋らせろ、という方は、こちらのツイッターアカウントまでご連絡いただければ、収録の日程など調整させていただきますので、よろしくお願いします。
発表資料やセッションの動画は後日セールスフォール・ドットコム様から公開していただけると思います。
ツイートはご自由にしていただいて構いませんので、ぜひツイートしてタイムラインを盛り上げてください。
ハッシュタグにPodcastで使っている「#migrationfm」をつけてもらえるとうれしいです。
今日は、QAエンジニアとして整備してきた継続的インテグレーションの弊社の事例、今後継続的デリバリーを実現するために何をすればよいか、それらがSalesforceDXによってどう変わるかをお話していきたいと思います。
- まず、会社についてご紹介させていただきます。
株式会社チームスピリットは、Salesforce Platform上でサービスを提供する会社です。
主に扱っている製品は、働き方改革プラットフォームである「TeamSpirit」になります。会社名と同じ製品名となりますが、製品は英語表記になります。
どういった製品か、というと、一般の社員の方々が日々業務で利用するような勤怠管理、経費精算、工数管理、電子稟議など事務処理ツールをひとつにまとめて提供しております。
- おかげさまで正式リリース後、5年で800社、10万IDの方々にご利用していただいております。
急成長することはビジネス面ではとてもよいことですが、開発現場にとってはハードなことも多くあります
- この急成長を支えるための仕組みづくりが必要でした
この仕組みづくりでは開発プロセスや問合せの管理方法など多岐に渡りましたが、その一環として継続的デリバリーの前段階である継続的インテグレーションに取り組みました。
- 継続的デリバリーとは、具体的にはどういったことをやることでしょうか?
- ・自社組織でここまでできている
カバレッジレポート
・SalesforceDXを利用するとこんな感じになる
- 私が入社したときは、リポジトリとパッケージ作成組織のソースコードが一致していませんでした。
とりあえず触ってみようと思うと、パッケージをインストールするか、パッケージ作成組織からソースコードを取得して別の開発組織にデプロイする必要がありました。
まぁ、それまでは2人で作っていて、それでも困らなかったので仕方ないかもしれません。
そんな状態なので開発中のソースコードがある開発組織もソースコードが一致していないところがありました。
これから、開発エンジニアも増やしていこうとしていて、さすがにまずいので対策しました。
- 対策としては、ソースコード管理の一元化です。
具体的には、開発組織からパッケージ作成組織にデプロイしていたのをやめて、リポジトリからパッケージ作成組織にデプロイするように一元化しました。
必ずリポジトリにソースコードがコミットされるようになるので、パッケージ作成組織と開発環境を同じソースコードに保てるようになりました。
これで、やっと私もリポジトリから新しい開発組織を作成できるようになりました。
まぁ、すぐに人は増えることはなかったですが、私が一人でたくさん開発組織作ってました。
開発組織が正しく構築できるようになっていいこととしては、機能検証のスピードを上げることができることです。
開発組織が
- ・自社組織でここまでできている
カバレッジレポート
・SalesforceDXを利用するとこんな感じになる
- SalesforceDXで変わる継続的デリバリー。
今のところ、弊社では継続的デリバリーまではしていません。
このあたりがSalesforceDXでどう変わるのか、SI・自社開発の場合、ISV・OEMの場合で私の方から岡本さんに質問していきたいと思います。
- まず、SI・自社開発の場合です。
基本的な流れは変わらないと思っています。
SalesforceDXでソースコードをリポジトリで一元管理するようになるので、開発環境はリポジトリからソースコードを取得して、開発環境にソースコードをデプロイして構築します。
開発・テストが完了したら、ソースコードでSandbox組織にデプロイして、ステージング環境でのテストを実施します。
最後に、運用組織にリリースしますが、ここは直接デプロイするケースと変更セットからがあります。
一連の開発フローはこんな感じになると思いますが、SalesforceDXで変わることはありますか?
- 次に、私が主に興味のあるISV/OEMの場合です。
開発組織については特に変わらないと思います。
以降については、パッケージを作成する必要があるため、パッケージ作成組織にリポジトリからソースコードを取得してデプロイします。
ここで、ベータパッケージを作成し、ステージング環境にパッケージをインストールして、最終テストを実施します。
最後に、運用組織にリリースしますが、ここではお客様の運用組織にプッシュアップグレードします。
一連の作業はこんな感じになりますが、SalesforceDXで変わることはありますか?
特に、Packaging2.0 によって、SI・自社開発においても
- これで、最後になりますので、まとめです。
最近の開発スタイル、特にアジャイルな開発では継続的インテグレーションが一般化してきています。
今回は、弊社チームスピリットにおいて、Salesforce開発に継続的インテグレーションを導入していくまでに起きた問題とその対策についてご紹介しました。
これは、SalesforceDX以前の移行ツールだけでも実現できていることです。
後半では、SalesforceDXだからこそ実現できることについて言及しました。主には、Scratch Orgが導入されることでテストの並行化ができるようになります。
これによって、GitHub FlowなどのようなPull Requestをベースとした開発スタイルでマージ前に自動テストを実行できるようになります。
最後にすぐに始められることを紹介したいと思います。
まず、1点目です。
静的解析ツールとして、PMD Apexというツールをご紹介しました。
PMDは古くからあるツールで、様々なプログラミング言語で静的解析ができるツールです。
PMD ApexはそのApex版となります。
そのため、エコシステムが育っておりEclipse、Visual Studio Code、vimなどのIDEやエディタに組み込んで利用できます。
インラインで警告を出してくれるので、開発の手助けになると思います。
次に、2点目です。
ぜひ、試してもらいたいことはApexテストの自動実行です。タイムリーにApexテストの実行結果が通知されると開発作業自体がかなり楽になると思います。
ソースコードを一元管理する必要があったり、Jenkinsを立ち上げるかCIサービスを利用する必要がありますが、それ以上のメリットを感じられると思います。
ついでに、デモ環境などに継続的にデプロイしておいて、プロジェクトマネージャーやユーザーに触ってもらうこともできます。
開発期間を短縮することが求められているときなので、素早くフィードバックをもらえるように環境を準備することも大事になってくると思いますので、こちらも機会があれば試してみてください。
- 弊社チームスピリットでは、一緒に世界の働き方を改革する仲間を募集しています。
Reactでフロントエンドを作ってみたい、ApexでガッチリしたWebサービスのAPIを作ってみたい、という方はいらっしゃいませんか?
まかない付きの勉強会「まかないてっく」など開催していますので一度来てみてください。
- 最後に時間が許す限り、質問をお受けしますが、いかがでしょうか?