Salesforce DevOps Centerを触ってみた〜注意するポイント・期待すること〜
こんにちは、co-meetingにてエンジニアしているハナミズキです。今回のネタはDevOps Centerです。正式リリースされてから気になっていたので今回触ってみました。
1.はじめに
Salesforce DevOps Centerは、開発作業の変更や更新を直感的かつ使いやすく管理するツールです。特に、従来の「変更セット」の代わりとして機能し、開発の進捗を視覚的に確認・管理できるよう設計されています。
このツールは、ローコード環境で作業するシステム管理者からVSCodeを活用して高度な開発作業を行う開発者まで、さまざまな技術レベルのユーザーをサポートしてくれるらしいです。
DevOps Centerの構築方法については、公式ドキュメント「DevOps Center をインストールして構成する」を読むことをお勧めします。
さらに、多くの有識者がブログで環境構築の手法を紹介しているため、本記事ではその部分には触れず、実際にDevOps Centerを使用してみた経験から得られた重要な注意点と、今後の改善を期待したい課題に絞って解説していきます。
2.DevOps Centerの使用体験から得た注意点
DevOps Centerを触ってみて何度もつまづいたので私なりに注意するポイントを共有します。
2-1.日本語環境では注意しないと組織の紐づけが壊れる
DevOps Centerを日本語環境で使用する際、パイプラインのステージ名が日本語でデフォルト設定されます。現在、ステージ名に日本語を入力した際に不具合があり、英語のステージ名に修正しないとステージング環境への昇格に失敗する可能性があります。
以下のように日本語名のまま環境構築すると日本語名のステージは勝手に全て同じ組織に接続され、組織の紐付けが壊れてしまう現象が発生します。
（本番組織の接続は、このタイミングで実施しないので影響はありせん。）
<解決策>
デフォルトで設定されるステージ名は「インテグレーション」と「ステージング」です。接続する前に英語にすることで解決します。
もしも、日本語のまま接続してしまった場合、英語のステージ名をつけ再構築できたら解決します。
なお、DevOps Centerは接続組織のログイン情報を覚えているため、再構築する場合は組織を新規に用意する必要があります。組織を新規に用意できない場合は、プロジェクトを作り直すことで解決できます。
2-2.組織の同期とVSCodeでのデプロイ時のコンフリクト
Development Environmentsの[Sync..]をクリックして組織を同期させた後に、VSCodeを使用してデプロイすると対象組織の状態が変化しているため、コンフリクトエラー「Error (1): There are changes in the org that conflict with the local changes you're trying to deploy.」が発生します。
<解決策>
VSCodeからデプロイ時にコンフリクトしないようローカルのメタデータを最新の状態にしてから、開発・デプロイする開発習慣を身につけると手戻りが少なくなります。
// ローカルのメタデータを最新の状態に変更する
sf project retrieve start --target-org devops-study-scratch
or
sf project retrieve start --target-org devops-study-scratch --ignore-conflicts既に修正してしまっており、修正内容が限定的であれば、以下の例のようにピンポイントでデプロイしたい情報を選ぶのも一つの解決策です。
sf project deploy start --target-org devops-study-scratch --metadata ApexClass:SampleClass修正内容が競合している場合、git stashなどを使用して変更を一時的に退避させる方法、または問題がないと判断される場合には、sf project deploy startコマンドを実行する際に--ignore-conflictsオプションを付けて強制的に上書きする、という解決策もとれそうです
2-3.sandboxの更新タイミングとデータリスク
Sandbox環境の更新は開発データに影響を及ぼす可能性があります。更新が行われると、DevOps Centerで管理されているWorkItemに紐づく設定やデータがリセットされる恐れがあるため、更新には注意が必要です。
<解決策>
もしSandboxを更新する前に、コミットしていたのであれば、[Swap Development Enviroment]機能を活用し、環境の切り替えを行うことでGitHubリポジトリから再デプロイされ復旧できます。
しかし、コミットできていない場合はメタデータが失われてしまうため、こまめに修正範囲をコミットすることを推奨します。
詳細は公式ヘルプ「Sandboxが更新されたときの影響」を閲覧してください。
2-4.複数人での作業時の競合
複数人で作業していると競合が発生しやすいです。特に複数のWork Itemを同時に昇格しようとして内容が競合している場合、以下のようにブロックされ昇格できなくなります。
<解決策>
GitHubを見ると、以下のようにconflictsのメッセージが出ており、競合を解決してから再度昇格作業をすることで解決できます。
詳細は公式ヘルプ「競合検出と解決」を閲覧してください。
3.今後の改善を期待したいDevOps Centerの課題
DevOps Centerを触ってみて課題だと感じたこと、同時に今後の改善を期待したいポイントを共有します。
3-1.ロールバックができない
一度作業項目を昇格してしまうと、その操作を取り消すことができません。
以下は昇格前と昇格後のイメージとなっていますが、パイプライン上での作業は一方通行であり一部のWorkItemの昇格を取り消す機能は提供されていません。
<解決策>
現時点で解決策はありません。昇格作業はより慎重に行う必要があります。
なお、DevOps Centerの公開ロードマップにおいて、Issue#35で取り組みが計画されているため、将来的なアップデートでの改善が期待されます。
3-2.プロジェクトとWorkItemを削除できない
一度作成されたプロジェクトやWorkItemは画面上から削除できません。
よって、以下のイメージのように作成したプロジェクトが削除できない状態になります。
<解決策>
現時点では、削除機能が提供されていないため、不要になったプロジェクトやWorkItemを区別する方法として、以下のような対策が考えられます。
プロジェクトやWorkItemの名前を変更する。
WorkItemのステータスを「なし」に設定し、フィルタ機能を活用し非表示にする。
また、試してはいませんが、データモデルが公開されているので、Apexを使用して関連するレコードを削除する方法も考えられます。
なお、プロジェクトの削除についてはDevOps Centerの公開ロードマップにおいて、Issue#69で取り組みが計画されているため、将来的なアップデートでの改善が期待されます。
3-3.GitHubに直接コミットした場合に認識しない場合がある
GitHubに直接コミットしても、DevOps Centerがこれを差分として認識しない場合があります。
たとえば、以下のイメージに示されたように、GitHubに直接コミットされた「updateAccountName」はDevOps Centerの「integration」ステージで認識されず、一方でDevOps Centerを通じてコミットされた「helloAccountName」は認識されています。
<解決策>
DevOps Centerの公開ロードマップによると、この問題はIssue#96で現在解決に向けて取り組んでおり、将来的なアップデートでの改善が期待されます。
開発者は、問題が解決されるまでGitHubへの直接コミットを避け、DevOps Centerを通じてコミットするとよさそうです。万が一、GitHubへ直接コミットしてしまった場合は、DevOps Centerから再コミットすることで問題を回避できます。
3-4.エラーメッセージが分かりにくい
DevOps Centerで作業していると、エラーメッセージが分かりにくい場合があります。「詳細を見ろ」というような指示があるにも関わらず、詳細情報が提供されていないことがあります。
<解決策>
基本的にエラー発生時は、エラーメッセージの内容に従い対応します。その上で分からない場合は、DevOps Centerの公式ドキュメントやTrailblazer CommunityのDevOps Centerグループを参照して、似たような問題に対する解決策を探します。また、エラーメッセージを元にインターネットで検索すると、他のユーザーの経験に基づく解決策を見つけることができることもあります。
エラーメッセージの内容が「Timeout」や「Response code 403」の場合は、一定時間おいたあと再試行することで解決することがあります。ただし、これらのエラーメッセージが表示された際には、短時間での再試行では問題が再発する可能性が高いです。過去には、解決が困難だと早合点してプロジェクトを一からやり直した経験もあります。そのため、この種のエラーに直面した際には、根気強く待つことが必要です。
3-5.環境の不安定さ
同期、昇格、または環境の切り替えを行った直後、すなわち操作を実行してから10～20秒の間に、DevOps Centerからリンクをクリックするか、メニューから組織を開こうとすると、ログインやその他の操作ができなくなるなど、状況が不安定になる場合があります。
※この10〜20秒という時間は、私の個人的な感覚に基づくもので、環境によって差がある可能性があります。
<解決策>
こちらは一時的なものです。例えば、過去にログインできたのであれば時間をおいて再試行することで解決します。
いつか改善されることを期待したいですね。
4.おわりに
今回DevOps Centerを使用してみた結果、現時点での課題や注意点が多く存在することが明らかになりました。
そのため、本番運用に移行するのは、まだ早いかもしれません。
しかし、DevOps Centerの導入は、多くの組織にとって開発プロセスの改革の一歩となる可能性が高いです。DevOps Centerに対する開発活動も活発であり、将来に対する期待が大きいことから、私はこれに対してポジティブな評価をしています。
DevOps Centerを利用する最大の利点は、パイプラインを通じてどの機能開発がどの組織で進行中であるかを一目で確認できる点です。
本番環境に変更を加える際は非常に慎重になるべきですが、複数のチームで開発を行っている場合、他のチームが何をしているかを簡単に把握できることは、問題を早期に発見する上で役立ちます。
さらに、使用している組織に簡単にアクセスできるため、関係者と協力して開発を進めやすくなります。また、GitHubとの連携により、これまでソースコードのバージョン管理を行ってこなかった組織でも、変更内容の差分を確認できるようになり、問題に気付きやすくなる可能性があります。
したがって、課題の改善、特にロールバック機能のリリースが待ち遠しいです。次回のリリースノートでも、DevOps Centerの進化に注目していきたいと思います！
以上です、ここまで読んでくださりありがとうございました！
この記事が誰かの参考になれば良いなと思います。