- DevOps Centerとは？
- DevOps Centerの設定方法と使い方
- プロファイルと DevOps センター
- DevOps Center DE版にできるがDE版にはSandboxはない？
- Troubleshoot DevOps Center Configuration (Beta)
- Troubleshoot DevOps Center Errors (Beta)
- DevOps Center エラー関係のまとめ
- DevOps Centerの質問のまとめ
- DevOps Center のバグ
- コミットの停止が発生した場合のトラブルシューティング
- DevOps Center インストールの制限
- DevOps Center 未解決
- DevOps Centerd： 権限セットの問題
The DevOps Center doesn't track or manage deployments that are made directly into your Salesforce environments, at all.
DevOps Center は、Salesforce 環境に直接行われる展開を追跡または管理しません。
Put another way: the DevOps Center works from a paradigm of trying to keep what's in your Salesforce environments in-sync with what's in the corresponding branch of your GitHub repository, but it doesn't currently support "the other way around".
別の言い方をすれば、DevOps センターは、Salesforce 環境にあるものを GitHub リポジトリの対応するブランチにあるものと同期させようとするパラダイムから機能しますが、現在「その逆」はサポートしていません。
If you find yourself needing to do an emergency hot-fix into a Salesforce environment (it happens), we recommend that you make the emergency fix as needed, of course. Then, when the emergency is resolved, go back and make the same change in a development environment in your DevOps Center, and promote that Work Item back through your pipeline and finally into your final pipeline stage. By doing so, you'll ensure that the emergency change that you had to make exists in both your source control system and all of the environments in your pipeline.
Salesforce 環境に緊急の修正プログラムを適用する必要がある場合 (実際に発生します)、必要に応じて緊急の修正プログラムを作成することをお勧めします。次に、緊急事態が解決されたら、戻って DevOps センターの開発環境で同じ変更を行い、その作業項目をパイプラインに戻して最終的なパイプライン ステージに昇格させます。そうすることで、実行しなければならなかった緊急の変更が、ソース管理システムとパイプライン内のすべての環境の両方に確実に存在するようになります。
Will Main update if a manual change is made in production?
現在の実稼働環境ではない組織で DevOps Center を有効にしてインストールする場合は、テスト プロジェクト/パイプラインを構築できる開発者組織 で試すことをお勧めします。サンドボックスの特定のバックエンド制限により、現在、サンドボックスへのインストールはサポートされていません。
初心者向けの質問: DevOps Center がサンドボックスで利用できるようになるのはいつですか?
自動化処理も使えるみたい
できないこと
「メタデータ API を介してフィールドの依存関係の値を追加できますが、削除することはできません。」
現時点では、DevOps Center で WorkItem にフィールドを追加することはできません。将来的にこの機能を追加するためのロードマップ項目があります。]
いいえ、それは不可能です。サンドボックスからフローを手動で削除し、GitHub からフロー定義を削除する必要があります。
No it is not possible. You would have to delete the flow manually from the sandbox and delete the flow definition from GitHub.
Not even Gearset is able to do this after Winter '19.
https://docs.gearset.com/en/articles/2506780-flow-definitions-can-t-be-deleted
unfortunately this is a known issue in Devops Center. Currently you can't commit components located in folders (EmailTemplate, Dashboard, Report, Document) .
残念ながら、これは Devops Center の既知の問題です。現在、フォルダー (EmailTemplate、Dashboard、Report、Document) にあるコンポーネントをコミットすることはできません。
同期ステータスはメタデータのみを確認します。両方にログインし、サンドボックスのuser.Id がUAT に存在することを確認します。ユーザーはデータであるため、サンドボックスの更新中にのみ同期されます。
ペレス・サンマルチノ・フランシスコ (Salesforce)
こんにちは@Ahmed Aiyazさん
DevOps センターは現在、個人または組織が所有する GitHub でホストされるリポジトリをサポートしています (組織が所有する場合は、これらの追加手順が必要ですhttps://help.salesforce.com/s/articleView?id=sf.devops_center_org_owns_github_repo.htm&type=5 )
エンタープライズまたはオンプレミスはまだサポートされていません。
このグループの右側に固定されているロードマップをご覧ください。役立つ機能に賛成票を投じることができ、それに応じて優先順位が付けられます。
すべてのメタデータがスクラッチ組織にデプロイされており、差分ではすべてが新しいことが示されているため、これは明らかです。すべてのメタデータを数回取得する以外に方法はありません
バグ
これらの変更は、開発環境に残っているはずです。したがって、新しい作業項目を開いて [Pull Changes] をクリックすると、それらの変更が表示されます。次に、新しい作業項目の一部としてコミットする変更を選択できます。作業項目がない場合は、ソース追跡がリセットされ、それらの変更が別の作業項目でコミットできるようになります。
その他
I think there may be a misunderstanding. Source tracking as a feature is not lost when you do a sandbox refresh (as in it is not disabled) however the old changes that were tracked before are no longer sustained. What you are seeing is expected behaviour. Whatever has been directly modified in Prod will not be able to be detected until you 'touch' it in the sandbox again.
誤解があるかもしれません。機能としてのソース追跡は、サンドボックスの更新を行っても失われません (無効にされていないため) が、以前に追跡された古い変更は維持されなくなります。あなたが見ているのは、期待される動作です。Prod で直接変更されたものは、サンドボックスで再度「触れる」まで検出できません。
CICD戦略のことを言っているのでしょうか？通常、リスク軽減のために多層ブランチとサンドボックス戦略を使用しており、そのために複数の GitHub リポジトリを作成する必要はありません。(たとえば)。ありがとう
役立つ情報はこちら: https://developer.salesforce.com/blogs/2017/09/error-handling-best-practices-lightning-apex
これらの例外は、定義したテキストとともに UI に表示される必要があります
私も初めてDevOps Centerを社内に導入したときに同様の問題に直面しました。当初は 4 つの環境がありました。開発、QA、UAT、および製品。したがって、UAT はバンドルを行う場所である必要があります。しかし、UAT 内のすべてを運用環境にプッシュしたくないので、うまくいくでしょうか。そこで、本番環境にプッシュしたい変更をバンドルするためだけに新しい環境を導入しました。したがって、UAT から、運用環境に移行する必要がある変更を選択でき、それらの変更はバンドル環境に移動され、そこではテストは行われません。そこで、リリースバージョンとバンドルを指定し、バンドルから本番環境にプッシュします
DevOps センターはメタデータ タイプとして「アセット ファイル」をサポートできますか?
According to the Metadata Coverage Report, ContentAsset is supported by the Metadata API.
https://developer.salesforce.com/docs/metadata-coverage/58/ContentAsset/details
新機能
That's actually a new feature that makes sure that DevOps Center has received all the events from GitHub so you don't find yourself in an undesirable state. It's not an error message but rather communication to wait a few more minutes so that your promotion is successful.
forceignoreファイル
yes, every pipeline stage' branch has a .forceignore file.
The back sync of dev environments is done using the branch of the first stage in the pipeline so you would need to update the .forceignore in that branch.
はい、すべてのパイプライン ステージのブランチには .forceignore ファイルがあります。
開発環境の逆同期はパイプラインの最初のステージのブランチを使用して行われるため、そのブランチの .forceignore を更新する必要があります。
キュー
sometimes the queueable takes a few minutes to execute, did your promotion completed or got stalled? If the promotion stalled, please review this article to work around it.
The "Sorry to interrupt" dialog it is usually displayed when there is an issue rending the page. Dismiss or closing the page should be able to remove it.
If your promotion stalled and following the article for stalled promotion doesn't solve your issue, and/or the "Sorry to interrupt" dialog keeps showing up, I would suggest to open a customer case so that the team can look into the logs and find the root cause.
キューアブルの実行に数分かかることがあります。プロモーションは完了しましたか、それとも停止しましたか? プロモーションが停止した場合は、この記事を参照して問題を回避してください。
「中断して申し訳ありません」ダイアログは、通常、ページのレンダリングで問題が発生した場合に表示されます。ページを閉じるか閉じると削除できるはずです。
プロモーションが停滞していて、停滞しているプロモーションに関する記事に従っても問題が解決しない場合、または「中断して申し訳ありません」ダイアログが表示され続ける場合は、チームがログを調査して、根本原因を見つけます。
GitHub リポジトリ
既存のリポジトリを使用して新しいプロジェクトを作成できるはずです。残念ながら、現時点では例外エラーが発生するバグがあります。これは今後のパッチリリースで修正される予定です。
--> このバグはバージョン 6.1 で修正されました。