- DevOps Center <--訳した分
- Salesforce DevOps Center: A Deeper Dive
- Salesforce DevOps Center Tips: Environment Management
- Troubleshoot DevOps Center Errors (Beta)
長かったので、設定方法は別に分けます。
- 本番組織で Dev Hub を検索し、Source Tracked Sandbox を有効にして Dev Hub を有効にする
DevOps または DX を使用して高度なことを行う開発チームがある場合は、本番組織で有効にする前に開発チームに確認してください。ただし、とにかく有効にする必要があります。
- また、DoCe は最初は Github でのみ機能するため、Github があることを確認してください。
- Github で無料のプライベート リポジトリを作成できます。
- これが自分の Github アカウントではなく、会社が所有するものであることを確認してください。メタデータでさえ、個人の Github アカウントに保存しないでください。
- 次に、開発者サンドボックス (部分的ではない) を作成または更新します。ソース追跡を有効にした後に作成されたサンドボックスが必要です。
- セットアップで DevOps Center を検索し、有効にします。次に、クリックしてパッケージをインストールします。
- インストール後、DevOps Center はアプリ ランチャーのアプリになります。
なぜ DoCe はパッケージであり、Salesforce の一部ではないのですか? さて、いくつかのことが今この方向に向かっているようです。これにより、製品チームは年に 3 回のメイン リリースとは異なるスケジュールでリリースできます。これは必ずしも頻繁なリリースを意味するわけではありませんが、バグ修正がより簡単に行えるようになることを願っています。パッケージですが、引き続きサポートを受けられます。(ベータ版では、DoCe のフィードバックは GitHub スペース ( https://github.com/forcedotcom/devops-center-feedback ) 経由です)。
UI
DoCe を開いて最初に気付くのは、新しいタブで開き、画面全体を占めることです。(そして、アプリ ランチャーで現在の画面を開いたままにするだけです)。DoCe は、Lightning アプリケーション ビルダー、メール テンプレート ビルダー、その他の「ビルダー」と同様の「ビルダー」UI です。しかし、UIは本当にひどいです。Salesforce の他の部分とは異なります。チームは、Salesforce の標準的な設計図に従わないものを構築するために、どのように GET を行うのでしょうか。彼らは設計システム全体を作成しましたが、どのチームも参加して好きな混乱を作成し、それを Salesforce と呼ぶことができますか? これが、セットアップ PM が必要な理由です。すべてのセットアップ画面で団結と結束が必要です。
- プロジェクト、作業項目などのデータは組織内にありますが、組織内で簡単に表示する方法はありません。プロジェクトのタブがありますが、名前以外は何も表示されません。他のオブジェクトのページ レイアウトとタブを作成することもできますが、実際には必要ありません。レポート タイプを作成したら、レポートを作成できます。
セットアップ
新しい計画
プロジェクトは基本的に組織です。プロジェクトは 1 つしかない場合がありますが、それで問題ありません。
-
新しいプロジェクトを作成する
WTF はここで不注意な UI を使用しています。これはどのようにしてテストを通過するのでしょうか?
-
DX プロジェクト構造についてのビットは無視してください。これが現在の状況です。必要でない限り、それについて知る必要はありません。
-
リポジトリの作成が最も簡単です。
-
DoCe にプロジェクト レコードがあり、選択した名前のプライベートの空の Github リポジトリがあります。
注: リポジトリ名は Github の単なるリポジトリであるため、私よりもはるかにクリエイティブになりたい場合があります。会社の他のすべてのリポジトリと混在している場合は、必要な命名規則を知る必要があります。従う。
本番環境に接続
- 次に、組織を接続します。プロダクションから始まります。[クリックして接続] をクリックします。
UI が Salesforce の規則に従っていないことに気付くでしょう。通常、Salesforce では、行のアクションは行の最後のドロップダウン ボックスに表示されます。
- デフォルトの名前は TDD Release でしたが、Prod と Sandbox しかないため、シンプルにするために名前を Prod に変更しました。
ログインして、組織の DevOps Center へのアクセスを許可します。
これが DoCe が既にインストールされている組織である場合、それを行うのは奇妙に思えます。
- 今、あなたは何をしますか？ここには「アクション リンク」がありません。続行するには、プロジェクト レコードをクリックする必要があります。
サンドボックスに接続
プロジェクトをクリックすると、これが表示されます...すべてを少し無視して、[設定]をクリックします
- [追加] をクリックしてサンドボックスを追加します。
- この手順を実行する前に、新しく作成したサンドボックスにログインしていることを確認してください。これにより、MFA をセットアップし、サンドボックスですべてが正常であることを確認できます。
- ここでも、適切な命名規則を使用してください。おそらく、サンドボックスの名前に似ています。
- このステップで「開発に使用」を選択し、サンドボックスを選択します
注: ここで問題が発生しました。私は拡張ドメインを使用しており、ここのログイン画面では dot salesforce dot com をテストするためだけに表示されるため、このステップで拡張ドメインに入るには URL をハックする必要がありました。
パイプラインをセットアップする
ここでは物事を単純化します。Sandbox と Prod のみを使用している場合は、どのタイプの環境で作業しているかを尋ね、これをシンプル モードとして設定するウィザードが欲しいです。
- 統合、UAT、およびステージング ステージの場合は、ドロップダウン矢印をクリックし、[ステージの削除] をクリックします。
- これで簡単なセットアップが完了し、Activate をクリックできます。
バンドル ステージとブランチ名は無視して、シンプルに保ちます。
作業項目
これでワークアイテムを作成できます
- [新しい作業項目] ボタンが通常の Salesforce ボタンのように見えないのはなぜですか?
- WTF は、箇条書きのタブ設定が間違っています。ああ、神様。
- 詳細を入力します。前述のとおり、これは Jira チケットではなく、いかなる形のチケットでもありません。簡単な説明を入力し、選択したチケット システムでチケットへのリンクを設定するだけです。
- これは、次に行うことであり、展開します。作業項目の内容を理解するには、少し試行錯誤が必要になる場合があります。
変更をビルドする
- サンドボックスで変更を行う前に、これを最初に設定する必要があるかどうかはわかりませんが、そうでないことを願っています. これはプロジェクト レベルで設定する必要があり、作業項目レベルで既に設定されているはずです。
- [続行] をクリックします。
- これで、Github ブランチが作成されました。繰り返しますが、これについてあまり心配する必要はありません。Github のものはすべてシームレスです。
- さあ、サンドボックスでモノを作りましょう。
Pull Changes
- アイテムを作成したので、作業アイテムで [Pull Changes] をクリックします。
注: 移動中に 2 つのワーク アイテムがあり、すべての変更がプルされる場合がありますが、このワーク アイテムに関連するメタデータ コンポーネントを選択できることを心配する必要はありません。
- フローを作成し、カスタム フィールドを作成し、フィールドを 2 つのページ レイアウトに追加し、フローを Lightning ページに追加し、新しいフィールドのいくつかのプロファイルに権限を付与し、アカウント管理を行う人々の権限を処理する権限セットを追加しました。
- そこに手動で追加したコンポーネントがあることに注意してください。
- プロファイルがプルされたからといって、プロファイルの展開を開始するわけではないことに注意してください。使用している展開方法に関係なく、プロファイルを展開しないでください。ただし、Perm セットの展開は問題ありません。
Commit
コミットするメタデータ コンポーネントを選択し、メモを入力して、[変更のコミット] をクリックします。
レビューを作成
- さて、次のステップは本当に奇妙です。変更をコミットすると、[変更をコミット] ボタンがグレーに変わるだけです。したがって、次のステップはレビューの作成であることを知っておく必要があります。
- [レビューを作成] をクリックします
- 各ワークアイテムに対してこの手順を実行する必要があります
Ready to Promote
- あなたは最後のステップが変だと思っていましたが、これはさらに変です。Salesforce のどこで、トグル ボタンを使用してステージ内の項目を移動する必要がある UI を見たことがありますか?
- [宣伝する準備ができました] をクリックします。ステージを Ready to Promotion に変更し、Work Item をそれ以上変更できないようにロックするだけです (ただし、変更が必要な場合は、Ready to Promotion をオフに切り替えることができます)。
- パイロット フェーズ中にこれらすべてをフィードバックとして提供したにもかかわらず、このプロセスを改善するために何も行われませんでした。
作業項目の承認
- ここでパイプラインに戻ります (この UX は少し奇妙に感じますか? そのとおりです)。
- ここで、複数の作業項目に取り組み、それらすべてを昇格準備/承認済みステージに移行します。変更を本番環境にデプロイする準備が整ったら、次のステップを実行します。
Promote
- プロモートするワークアイテムを選択し、[選択したものをプロモート] をクリックします。
- 本番組織にログインします
- 次に、画面が約 5 回更新された後、プロモートするワーク アイテムを再度選択し、[選択項目のプロモート] を再度選択する必要があります。
これも、すでに本番にログインしているため、非常に奇妙です (ただし、デプロイ先の本番組織がまったく異なる可能性があることを覚えておいてください。しかし、私がこの組織にいて、既にログインしていることを理解するのに十分なほど賢いはずです)。 ）。
-
ここではデフォルトのままにします。
注: テスト設定を変更したい場合があります。これは、本番環境への他のすべての展開と同じです。 -
[Promote] をクリックします。これは、Deploying to Production になっているため、Deploy と表示されているはずです。
展開
- ここにはデプロイフィッシュはありませんが、デプロイがこの段階にある間、必要に応じて本番組織でデプロイステータスに移動し、そこから監視することができます。
展開済み
以上で、ワークアイテムが本番環境に展開されました。
Github
舞台裏で、Github は、作成したコミットとワーク アイテムのプル リクエストを実行し、それらのアイテムを最初に選択したブランチ (メインなど) にマージしました。
また、展開したすべてのアイテムのすべてのメタデータを確認できます
作業項目リスト ビュー
- このリスト ビューは、クローズされたすべてのワーク アイテムでどんどん大きくなり、通常の Salesforce のようにリスト ビューを作成する方法はありません。したがって、ここに入るたびにフィルターを使用する必要があります。ただし、少なくとも逆の日付順で並べ替えることができます。
- 作業項目用のタブを作成したり、作業項目用のカスタム フィールドを作成したりして、それらを任意の Salesforce レコードとして扱うこともできますが、DoCe でその追加情報を確認することはできません。
展開エラー
- これ以降の展開は、通常の Salesforce 展開とまったく同じであり、すべて同じ欠点があります。
- クリックして詳細を表示
- エラーの詳細をクリック
- ここでのエラーの詳細は、組織のリリース状況で表示されるエラーの詳細とまったく同じです。（例えば、理解不能）。
- ただし、Deployment Status の方が読みやすい
- そのため、取引先ページのレイアウトと取引先の Lightning ページを修正する必要があります。
- 次に、ワーク アイテムに戻り、[プロモーションの準備完了] の切り替えを解除し、変更をプルしてから、変更をコミットして [プロモーションの準備完了] に戻し、[パイプライン] に戻ってプロモート / デプロイを再度実行する必要がありました。
コンポーネントを手動で追加する
- コンポーネントを手動で追加できます。これは、パイロット以来の優れた新機能です。これを行うには、メタデータを完全に理解する必要があります。詳細について学ぶことをお勧めしますが、この手順を実行する必要はありません。ソース トラッキングに頼ることができます。
これは変更セットよりも優れた UI ですが、変更セットに既に組み込まれており、この UI に簡単に追加できる関連するメタデータ検索がないことは興味深いことです。そんなミス。
- 追加した後にコンポーネントを削除することはできませんが、この作業項目にコミットするようにコンポーネントを選択することはできません。
本番環境の変更
- 開発組織を本番環境で行われた変更と同期できるようにするためのものです。サンドボックスを頻繁に更新するのではなく、これを行ってください (作業項目の進行中は更新しないでください)。
- しかし、うまくいかなかったようです。もう一度試してみる必要があります。
Tips
- ゆっくりスタート！1 つのサンドボックスから本番環境に移行して、それに慣れてください。
- 次に、開発チームと協力して、「パイプライン」とサンドボックスの管理方法を検討します。
- DevOps センターを 1 つの組織で使用し、それを使用して完全に異なる組織との間でデプロイできます。私はパートナーとして、それをパートナー組織にインストールし、クライアントのすべての組織のすべての展開を 1 つの中心的な場所にすることができます。それはデータではなく、単なるメタデータなので、それらをまとめておくのに問題はありません。以前、すべてのクライアント組織のメタデータをバックアップ用に Bitbucket に保持していました。
高度な機能
最初に組織のすべてのメタデータを Github に取得して、デプロイ時に組織への変更を確認できるようにすることをお勧めします。すべてのメタデータを取得する方法の詳細については、 https://tddprojects.atlassian.net/wiki/spaces/SF/pages/595197983を参照してください。