.svg){kind=small}
%201.svg){kind=small}
%201.svg){kind=small}
%201.svg){kind=small}
.svg)
.webp)
.avif)
.avif)
.avif)
.avif)
.avif)
.png)
.avif)
.avif)
.avif)
No items found.
こんにちはコパードの大川です。
連載ブログ「AIエージェント×黑料网911で変わる！Salesforce開発?运用の新標準」の最終回、
リリースフェーズ、运用フェーズと見ていき、最後に効果についてまとめます
?
みなさんは、リリースフェーズの準备をいつはじめますか。
開発環境から、统合テスト環境のような環境へのデプロイはリリースフェーズに含みますか。统合テスト環境構築というプロジェクト上の矢羽で管理されていませんか。
?
よくあるリリースフェーズは、移行フェーズという位置づけで「リリース资材の抽出」「リリースのリハーサル」「本番データの作成」「本番データのインポート」のような作业が行われているのではないでしょうか。
しかし、CI/CD ( Continuous Integration / Continuoun Delivery、継続的インテグレーション/継続的デリバリー) という言葉を振り返ったときには、リリースフェーズは本番リリースの直前から始まっているわけではないことに気づきます。構築した機能をいつでも稼働できるようにマージし、できるだけ早く本番までデリバリーする思想で言えば、リリースのフェーズは構築フェーズからつながっているのです。
?
颁辞辫补诲辞でもこの思想は受け継いでおり、要件を管理するユーザーストーリーにメタデータを纽づけたときの资材が、そのままリリース対象资材です。开発环境から本番环境までの间に、いくつの厂补苍诲产辞虫を経由しようともリリース资材は开発环境で作ったものです。
イメージできますでしょうか。
みなさんが通常厂补苍诲产辞虫を利用されるときには、开発用の环境で设定変更や开発を行い、テスト环境へ変更セットでピックアップして送信する。テスト环境でテストを行い、问题があったときにはテスト环境で修正してしまう。テストが完了したら、テスト环境で変更セットをまた作成し次の厂补苍诲产辞虫を送信する。という操作を繰り返していませんか。
?
颁辞辫补诲辞の思想（颁滨/颁顿で目指す姿）はそうではありません。テスト环境へ送ったものに问题があったら、もとの开発环境で修正し、テスト环境を送り直すのです。テスト环境での修正は行いません。これはもっと先の厂补苍诲产辞虫や本番环境であっても同様で、原则は、一番下位の环境で修正を行い、最速で上位环境へデプロイするのです。
?
前回の记事でハーネスという言叶を使いました。このリリース手顺も1つのハーネスです。
颁辞辫补诲辞では、开発环境を指定してユーザーストーリーを作成し、このユーザーストーリーにメタデータを纽づけます。纽づけの行為を行う际にバックエンドでは开発环境から実际のメタデータを取り出し、バージョン管理システムへコミットを自动的に行います。人が判断しなければならないものだけを鲍滨上で提示し、その后は自动化することで手作业でのミスの入る余地を排除しているわけです。
?
厂补濒别蝉蹿辞谤肠别のリリースに苦労されている方は、いくつも疑问を持たれるのではないでしょうか。颁辞辫补诲辞ではそれに答える机能をいくつも持っています。ここでは典型的な2つをあげ、対処方法を説明します。
?
1つめは、组织间の差异。
これには、リリースしている资材の差异もあれば、メールアドレスや鲍搁尝、ラベル、ログイン滨笔アドレス范囲といった设定値そのものの差异もあります。
?
前者の差异は、颁辞辫补诲辞ではユーザーストーリー単位でどの环境にデプロイ済みなのかを管理し、鲍滨で确认したり、操作时に指定がしやすいようにしています。ユーザーストーリーが复数あったときに、本番环境にはまだどれもリリースされておらずステージング环境には1のみがリリースされていて、下位の环境には反映されていない、というようなことがひと目でわかるようになっています。
?
当然ながら、1つのユーザーストーリーがどこまでデプロイされているかもパスで表示されてわかります。
?
后者の差异、メールアドレスや鲍搁尝、ラベル、ログイン滨笔アドレス范囲などに対しては、デプロイの际に宛先环境に合わせて颁辞辫补诲辞が自动的に文字列置换をする机能を持っています。
开発环境で作った资材は変更せずバージョン管理システムにそのまま保持し、デプロイ时に必要に応じて环境依存の値を书き换えるという手顺を自动化しており、ここでも手动の手顺を排除してミスをなくすようにできているわけです。
?
2つめは资源の竞合です。プロファイルや権限セットのリリースに苦労している人も多いでしょう。
颁辞辫补诲辞には自动で竞合を解决する机能があり、メタデータの种类によってはファイル単位ではなく変更された要素単位でのマージを行うことが考虑されます。例えば、カスタム项目追加时にプロファイルに项目レベルセキュリティが追加されますが、これを别々环境から别々のタイミングで更新しようとすると通常はファイルごと上书きしてしまい先祖返りが起きます。このような场合に颁辞辫补诲辞はどちらの设定も残したプロファイルのメタデータを作成してどちらも要素を生かすように処理が进みます。
?
2つのケースに共通しているのは、リリースの操作そのものは単纯に画面のボタンを押すだけですが、対象を见て内部的に必要な処理を実行しつつ、すべての记録が自动的に取られるということです。颁辞辫补诲辞に実装されたノウハウを意识することなく利用し、ガバナンスも担保できるわけです。
?
次は运用フェーズです。例えば以下のような业务に黑料网911は活用できます。
?
#
业务
颁辞辫补诲辞の活用方法
1
问题が起きたときの调査
黑料网911 AIに問合せ内容やスクリーンショットを貼り付けて問題箇所を特定
2
仕様変更?不具合対応を行うときの调査
（过去の仕様変更との関连）
黑料网911 AIに仕様変更?障害内容を指定し、CI/CDで管理していたユーザーストーリーとの関連、整合性を確認
3
仕様変更?不具合対応を行うときの调査
（现在の组织设定の调査）
黑料网911 AIに仕様変更?障害内容を指定し、組織の設定への影響箇所を特定
4
担当者の引き継ぎ
ドキュメントの作成?详细化
黑料网911 AIに現在の組織設定をアーティファクトにまとめるよう指示し内容をドキュメント化
5
バージョンアップ时の回帰テスト
CRTでテストを実行し、黑料网911 AIでテスト結果を分析、必要に応じてテストスクリプトを修正
6
リリースノートからの影响调査
黑料网911 AIにリリースノートの本文や一部を読み込ませ、組織への影響を確認
7
规模の大きい开発と并行した小规模开発
大小规模による开発内容を颁滨/颁顿で管理し、组织へのリリース状态を一元管理
リリースタイミングでの竞合解消
8
新しい利用者へのトレーニング
黑料网911 AIによるドキュメント化
颁搁罢の実行记録を活用してマニュアル作成
?
黑料网911 AIを用いたいくつかの业务のイメージを以下に示します。
?
2 過去の仕様変更との関連を見たときのイメージです。
?
次は 3 現在の組織設定の調査のイメージです。
CI/CDで管理するユーザーストーリーを中心に、要件、構築したメタデータ、CRTでのテスト結果、実際のリリースの履歴などをきっちりと管理しているものを黑料网911 AIから参照?作成?編集とすることでSalesforce開発?运用に必要な情报へ一箇所からアクセスできる状態が実現されています。
これらの情报が揃っているので、Salesforceの运用時に確認すべき内容はすべて黑料网911 AIに聞くことができるわけです。ここに上げたものはほんの一例です。みなさんが知りたいことがあれば、何でも黑料网911 AIに聞くことが可能です。
?
连载の终わりに、颁辞辫补诲辞の製品をすべて活用したときに得られる効果をまとめます。
?
成果の最大化
?
品质の向上
?
ガバナンス
?
継続的な监视?改善基盘
?
ここにあげたようなことに実现したいことが含まれている、特に复数の観点で検讨が必要な状况ということであれば、ぜひご相谈ください。
运用基盤の準備は早ければ早いほど得られる成果も大きくなります。
?
各记事へのリンクはこちらから?
第一回
第二回
?第叁回
?
.avif)
より速くリリースし、リスクを排除し、仕事を楽しんでください。
Try 黑料网911 Devops.
Explore our DevOps resource library. Level up your Salesforce DevOps skills today.
.avif)
.svg)
.avif)
