2022.02.08

はじめてのFlosum

TM

目次

はじめに

今回は「はじめてのFlosum」と題し、Flosumの特徴や簡単な使い方をまとめました。

「Flosum」と聞いたことはあるが、何ができるか詳しく知らない方、どういったことができるかは何となく知っているが、実際に触ったことがない方など……
Flosum未経験の方に向けて、初心者目線で基本的な内容について解説します。
（題目の通り、昨年初めてFlosumを使用したメンバーが執筆しております）

この記事がFlosum未経験の方の足掛かりとなれば幸いです。

1.Flosumとは

Flosum社が提供するSalesforceの移行ツール

Flosumでは、各Sandbox（開発環境）のメタデータが取得でき、Flosum上で各環境間の資材重複確認や、本番環境との差分比較が行えます。

参考：https://www.flosum.com

Salesforceの開発・リリースにおける課題

・リリースに変更セットを使っているが、設定や処理に手間がかかる
・バージョン管理や追加・修正箇所の把握を簡単に行い、反映漏れをなくしたいが、
　Salesforce DXやGitHubを使うほど開発・運用チームがこなれていない
・アプリケーションのデプロイ・リリース・資材比較をもっと簡単に実施したい
・リリースをスケジュール実行したい
・リリース内容のロールバックを簡単に行いたい　　　　　　　　　　　　　　　　　　　　　　…etc.

これらの課題はFlosumで解決！

Flosum上で資材整理～本番環境リリースまでの一連の作業が完結するため、Flosumを利用することで、システムのリリース管理やバージョン管理など、開発者・システム担当者にとって負担が大きい作業工数を削減できます。

2.他のリリース管理方法との比較

変更セット、メタデータ、Flosumの特性をまとめました。
それぞれ用途に合わせて使い分けるといいかもしれません。

変更セット

用途 ・小規模な機能をリリースする場合に使用
資材整理
【メリット】
・標準機能であるため、操作が簡単である

【デメリット】
・1つ1つの資材を選択するのは手間である
・プロファイルをリリースする場合は注意が必要である
差異確認 ・変更セットとリリース先環境の資材比較は行えない
スキル ・操作方法さえ理解していれば使用可能である
ツール ・標準機能

メタデータ

用途 ・大規模な機能をリリースする場合に使用
・複数環境で開発している場合に使用
資材整理
【メリット】
・リリースしたい箇所だけデータソースをマージすることで資材の一部のみを
　リリースすることが可能である
・プロファイルも該当箇所のみリリース可能である

【デメリット】
・リリース対象のxmlを作成する必要があるため、スキルが必要である
差異確認 ・リリース前後でメタレベルでの差異確認が可能である
スキル ・メタデータに関する知見がある程度必要である
ツール ・Visual Studio Code
・Ant移行ツール　　など

Flosum

用途 ・複数環境で開発している場合に使用
・Salesforce DXやGitHubを使うほど開発・運用チームのスキルがないが、
　バージョン管理や追加・修正箇所の把握を簡単に行いたい場合に使用
・リリースをスケジュール実行したい場合に使用
・リリース内容のロールバックを簡単に行いたい場合に使用
資材整理
【メリット】
・1つ1つ資材を選択するのは手間であるが
　Snapshotで絞り込みできていれば変更セットより選択が容易である

【デメリット】
・Snapshot機能を使って資材取得を行うが、
　絞り込み条件によっては取得できない資材がある
差異確認 ・Impact Analysisという機能で、リリース資材がリリース先に新規追加されるか
　更新されるかを一覧で確認可能である
スキル ・操作方法さえ理解していれば使用可能である
ツール ・OEM/AppExchange(有料)
　詳細は弊社営業にお問い合わせ下さい
参考（AppExchange）：Flosum -リリース管理とSalesforceの継続的インテグレーション

3.リリース手順

ここからはFlosumでのリリース手順を見ていきます。
Flosumには以下オブジェクトが存在し、これらを介してリリースを行います。
オブジェクト レコード登録内容
Orgs 各環境のSalesforce組織情報を登録する
Snapshot 開発環境からリリース対象を取得・保持する
Branch
 リリース対象をまとめ、比較や検証を実施する
Repository 本番リリース後に資材を格納する
これらはFlosum特有のものですが、名称とその用途を念頭に置けば、詳細な手順を見る際にもスムーズに理解ができると思います。

まずは図と合わせて、簡単に手順を追っていきましょう。

3-1.1環境からリリースする場合の手順

①～④の順序でリリースを行います。

①開発環境 A から Snapshot A （資材）を取得する
②Snapshot A （資材）からリリースに必要な資材を選択し、Branch へ格納する
③Branchに格納した資材をリリース先環境と比較・検証し、デプロイする
④リリース後、Branchに格納した資材をRepositoryに登録する

3-2.複数環境からリリースする場合の手順

①～④の順序でリリースを行います。
※1環境からのリリースする場合と異なる点：①、②

①開発環境 A から Snapshot A （資材A）、開発環境 B から Snapshot B （資材B）を取得する
②Snapshot A （資材A）、 Snapshot B （資材B）からそれぞれリリースに必要な資材を選択し、Branch へ格納する
③Branchに格納した資材をリリース先環境と比較・検証し、デプロイする
④リリース後、Branchに格納した資材をRepositoryに登録する

3-3.リリース手順詳細（1環境からリリースする場合）

ここからはもう少し詳しくリリース手順を見ていきましょう！

より詳細な手順は以下よりご確認いただけます。
最速Flosumリリース 4ステップ！
https://base.terrasky.co.jp/articles/vjLWV

①Snapshot作成
　Orgsで設定した開発環境から資材を取得して、Snapshotを作成します。
　※最終更新日や最終更新者で絞り込み、資材を取得することが可能です。

接続先を登録したOrg画面上「Create Snapshot」をクリックします。

最終更新日で絞り込みを行い、対象コンポーネントを選択し、「Create Snapshot」をクリックします。

②Branch作成
　 Snapshotからリリース対象の資材を選択し、Branchを作成します。

作成したSnapshot画面上「Commit to Branch」をクリックし、遷移先画面にてリリースしたい資材を選択し、「Continue Commit to Branch」をクリックします。

③比較・検証・デプロイ
　作成したBranchの資材をリリース先環境と比較し、デプロイ可能か検証し、デプロイします。

・比較
作成したBranch画面上「Impact Analysis」をクリックします。
その遷移先画面にてリリース先環境を選択した後、「Impact Analysis」をクリックします。

・検証
作成したBranch画面上「Validate」をクリックすると検証が実施され、結果が表示されます。
※添付からエラー内容の確認が可能です

添付エラー（例）
---------- Deployed flow ----------------
File name:flow/ServiceScheduleNotification.flow,Componrnt name:ServiceScheduleNotification(Line:undefined:column:undefined):
Message:myRule_10_A1（レコードを更新）-オブジェクト「WorkOrder」の項目「PressurizedState__c」は存在しません。
---------- Error Log Finished ----------------

この場合、リリースしたいフローに使用されている項目「PressurizedState__c」がオブジェクト「WorkOrder」に存在しないため、エラーとなっています。
そのため、項目「PressurizedState__c」をBranchに含めるとこのエラーは解消されます。
・デプロイ
作成したBranch画面上「Deploy」をクリックするとデプロイが実施され、結果が表示されます。

④Repository登録
　 Branchに登録されている資材をRepositoryへ登録します。

デプロイしたBranch画面上「Commit to Repository」をクリックし、Repositoryへ資材登録を行います。

これでリリース完了です！

いかがでしょうか？
使い方に慣れれば、変更セットと同じように活用できそうですね。

最後に

使用して感じたところを記載します。

・開発環境で変更してしまった資材を、当時の状態で再度リリース可能な点
　(※当時のSnapShotが残っていれば可能)やロールバックが容易な点は
　便利そうであると感じた。

・環境間や実装タイミング毎のリリース資材の差異確認が容易であると感じた。
　※差異の詳細を確認するにはメタデータを確認する必要がある

・今回は一度に複数環境へリリースを行ったり、
　複数開発環境からBranchでマージしてリリースを行ったりしていないため、
　Flosumの恩恵を存分に受けることはできなかったが、
　そういった使い方をすればもっとFlosumのメリットを感じられたかもしれないと感じた。

まだまだ私たちもFlosumについて学び始めたばかりですが、実際に使用してみて特性を理解していくことができました。
今後も、資材管理・リリース方法の手段の一つとして適宜利用していきたいと考えています。

最後までお読みいただきありがとうございました。
61 件
    　
  • banner
  • banner

関連する記事

関連するキーワード