.svg){kind=small}
.avif)
%201.svg){kind=small}
%201.svg){kind=small}
%201.svg){kind=small}
.svg)
.avif)
.avif)
.avif)
.avif)
.avif)
.png)
.avif)
.avif)
.avif)
No items found.
こんにちはコパードの大川です。
連載ブログ「AIエージェント×Copadoで変わる！Salesforce開発・運用の新標準」の最終回、
リリースフェーズ、運用フェーズと見ていき、最後に効果についてまとめます
みなさんは、リリースフェーズの準備をいつはじめますか。
開発環境から、統合テスト環境のような環境へのデプロイはリリースフェーズに含みますか。統合テスト環境構築というプロジェクト上の矢羽で管理されていませんか。
よくあるリリースフェーズは、移行フェーズという位置づけで「リリース資材の抽出」「リリースのリハーサル」「本番データの作成」「本番データのインポート」のような作業が行われているのではないでしょうか。
しかし、CI/CD ( Continuous Integration / Continuoun Delivery、継続的インテグレーション/継続的デリバリー) という言葉を振り返ったときには、リリースフェーズは本番リリースの直前から始まっているわけではないことに気づきます。構築した機能をいつでも稼働できるようにマージし、できるだけ早く本番までデリバリーする思想で言えば、リリースのフェーズは構築フェーズからつながっているのです。
Copadoでもこの思想は受け継いでおり、要件を管理するユーザーストーリーにメタデータを紐づけたときの資材が、そのままリリース対象資材です。開発環境から本番環境までの間に、いくつのSandboxを経由しようともリリース資材は開発環境で作ったものです。
イメージできますでしょうか。
みなさんが通常Sandboxを利用されるときには、開発用の環境で設定変更や開発を行い、テスト環境へ変更セットでピックアップして送信する。テスト環境でテストを行い、問題があったときにはテスト環境で修正してしまう。テストが完了したら、テスト環境で変更セットをまた作成し次のSandboxを送信する。という操作を繰り返していませんか。
Copadoの思想（CI/CDで目指す姿）はそうではありません。テスト環境へ送ったものに問題があったら、もとの開発環境で修正し、テスト環境を送り直すのです。テスト環境での修正は行いません。これはもっと先のSandboxや本番環境であっても同様で、原則は、一番下位の環境で修正を行い、最速で上位環境へデプロイするのです。
前回の記事でハーネスという言葉を使いました。このリリース手順も1つのハーネスです。
Copadoでは、開発環境を指定してユーザーストーリーを作成し、このユーザーストーリーにメタデータを紐づけます。紐づけの行為を行う際にバックエンドでは開発環境から実際のメタデータを取り出し、バージョン管理システムへコミットを自動的に行います。人が判断しなければならないものだけをUI上で提示し、その後は自動化することで手作業でのミスの入る余地を排除しているわけです。
Salesforceのリリースに苦労されている方は、いくつも疑問を持たれるのではないでしょうか。Copadoではそれに答える機能をいくつも持っています。ここでは典型的な2つをあげ、対処方法を説明します。
1つめは、組織間の差異。
これには、リリースしている資材の差異もあれば、メールアドレスやURL、ラベル、ログインIPアドレス範囲といった設定値そのものの差異もあります。
前者の差異は、Copadoではユーザーストーリー単位でどの環境にデプロイ済みなのかを管理し、UIで確認したり、操作時に指定がしやすいようにしています。ユーザーストーリーが複数あったときに、本番環境にはまだどれもリリースされておらずステージング環境には1のみがリリースされていて、下位の環境には反映されていない、というようなことがひと目でわかるようになっています。
当然ながら、1つのユーザーストーリーがどこまでデプロイされているかもパスで表示されてわかります。
後者の差異、メールアドレスやURL、ラベル、ログインIPアドレス範囲などに対しては、デプロイの際に宛先環境に合わせてCopadoが自動的に文字列置換をする機能を持っています。
開発環境で作った資材は変更せずバージョン管理システムにそのまま保持し、デプロイ時に必要に応じて環境依存の値を書き換えるという手順を自動化しており、ここでも手動の手順を排除してミスをなくすようにできているわけです。
2つめは資源の競合です。プロファイルや権限セットのリリースに苦労している人も多いでしょう。
Copadoには自動で競合を解決する機能があり、メタデータの種類によってはファイル単位ではなく変更された要素単位でのマージを行うことが考慮されます。例えば、カスタム項目追加時にプロファイルに項目レベルセキュリティが追加されますが、これを別々環境から別々のタイミングで更新しようとすると通常はファイルごと上書きしてしまい先祖返りが起きます。このような場合にCopadoはどちらの設定も残したプロファイルのメタデータを作成してどちらも要素を生かすように処理が進みます。
2つのケースに共通しているのは、リリースの操作そのものは単純に画面のボタンを押すだけですが、対象を見て内部的に必要な処理を実行しつつ、すべての記録が自動的に取られるということです。Copadoに実装されたノウハウを意識することなく利用し、ガバナンスも担保できるわけです。
次は運用フェーズです。例えば以下のような業務にCopadoは活用できます。
#
業務
Copadoの活用方法
1
問題が起きたときの調査
Copado AIに問合せ内容やスクリーンショットを貼り付けて問題箇所を特定
2
仕様変更・不具合対応を行うときの調査
（過去の仕様変更との関連）
Copado AIに仕様変更・障害内容を指定し、CI/CDで管理していたユーザーストーリーとの関連、整合性を確認
3
仕様変更・不具合対応を行うときの調査
（現在の組織設定の調査）
Copado AIに仕様変更・障害内容を指定し、組織の設定への影響箇所を特定
4
担当者の引き継ぎ
ドキュメントの作成・詳細化
Copado AIに現在の組織設定をアーティファクトにまとめるよう指示し内容をドキュメント化
5
バージョンアップ時の回帰テスト
CRTでテストを実行し、Copado AIでテスト結果を分析、必要に応じてテストスクリプトを修正
6
リリースノートからの影響調査
Copado AIにリリースノートの本文や一部を読み込ませ、組織への影響を確認
7
規模の大きい開発と並行した小規模開発
大小規模による開発内容をCI/CDで管理し、組織へのリリース状態を一元管理
リリースタイミングでの競合解消
8
新しい利用者へのトレーニング
Copado AIによるドキュメント化
CRTの実行記録を活用してマニュアル作成
Copado AIを用いたいくつかの業務のイメージを以下に示します。
2 過去の仕様変更との関連を見たときのイメージです。
次は 3 現在の組織設定の調査のイメージです。
CI/CDで管理するユーザーストーリーを中心に、要件、構築したメタデータ、CRTでのテスト結果、実際のリリースの履歴などをきっちりと管理しているものをCopado AIから参照・作成・編集とすることでSalesforce開発・運用に必要な情報へ一箇所からアクセスできる状態が実現されています。
これらの情報が揃っているので、Salesforceの運用時に確認すべき内容はすべてCopado AIに聞くことができるわけです。ここに上げたものはほんの一例です。みなさんが知りたいことがあれば、何でもCopado AIに聞くことが可能です。
連載の終わりに、Copadoの製品をすべて活用したときに得られる効果をまとめます。
成果の最大化
品質の向上
ガバナンス
継続的な監視・改善基盤
ここにあげたようなことに実現したいことが含まれている、特に複数の観点で検討が必要な状況ということであれば、ぜひご相談ください。
運用基盤の準備は早ければ早いほど得られる成果も大きくなります。
より速くリリースし、リスクを排除し、仕事を楽しんでください。
Try Copado Devops.
Explore our DevOps resource library. Level up your Salesforce DevOps skills today.
.avif)
.svg)
.avif)
