DevOps センターとは

Salesforce DevOpsセンターは、Salesforce開発エコシステム内での効率的かつ協調的な開発プロセスを実現するための革新的なツールです。このツールは、DevOpsの原則に基づき設計されており、開発ライフサイクル全体を通じて、計画、構築、テスト、デプロイ、監視、およびフィードバックの各段階で、効率性と生産性の向上を目指しています。

Salesforce DevOpsセンターの核心機能

従来の変更セットの後継者と言われてるSalesforce DevOpsセンターは以下の豊かな機能を用いております。

バージョン管理と自動同期

Salesforce DevOpsセンターは、Gitベースのバージョン管理システムと緊密に統合されており、開発者がコードの変更履歴を簡単に追跡し、必要に応じて以前のバージョンに戻せるようにします。自動同期機能は、ローカルの変更を中央リポジトリに自動的にプッシュし、リポジトリの変更をSalesforce環境にプルすることで、環境間の一貫性を保ちます。

継続的インテグレーション/デリバリー (CI/CD)

Salesforce DevOpsセンターは、コード変更が自動的にテストされ、安全に本番環境にデプロイされるCI/CDプロセスをサポートします。これにより、新機能や修正を迅速にリリースすることが可能になります。

監視とフィードバック

運用環境でのアプリケーションのパフォーマンスをリアルタイムで監視し、問題が発生した際に迅速に対応できるようにします。また、エンドユーザーからのフィードバックを集約し、それを基に改善策を検討できます。

使用シナリオ

複数の開発者が同じプロジェクトに取り組んでいる

DevOpsセンターの自動同期はチーム内のコードの整合性を保つのに役立ちます。更にチーム内のコードの変更を追跡し、統合するのにも役立ちます。

大規模なカスタマイズや複雑なSalesforce環境を管理する

Salesforce DevOpsセンターは、大規模なカスタマイズや複雑なSalesforce環境を管理するための効率的で統合されたアプローチを提供します。環境管理からリリース管理、パイプラインとステージの設計に至るまで、DevOpsセンターは組織内の協調と生産性の向上を支援します。

品質保証が重視される

自動化されたテストとCI/CDパイプラインを使用して、リスクを抑えながら高品質の製品を提供します。

事前設定

DevOps Centerを利用するには変更を追跡できる環境を準備しないといけません。開発する際にScratch組織またはSandbox組織を利用することができます。

Scratch組織

Scratch組織はデフォルトとして物の変更が既に追跡可能になってるため、Scratch組織を利用するには「Dev Hub を有効化」が必要になります。

Sandbox組織

Sandbox組織は変更の追跡がデフォルトではないので、まず設定からから「Developer Sandbox および Developer Pro Sandbox のソース追跡」を有効化しないといけません。

インストールと設定の仕方

DevOps Centerを使用するにはまず設定から有効化し、パッケージをインストールする必要があります。

設定の手順

パッケージインストールが終わったら、次は接続アプリを作成します。必ず以下のステップの様にアプリ作成する必要があります。

[設定] から、[クイック検索] ボックスに「アプリケーションマネージャ」と入力し、[アプリケーションマネージャ] を選択します。
[新規接続アプリケーション] をクリックします。
基本情報を入力:
[Web アプリケーション設定] で、[開始 URL] に「/sf_devops/DevOpsCenter.app」と入力します。
[保存] をクリックします。
[接続アプリケーションを管理する]で、[管理]をクリックします
[権限セット] セクションで、[権限セットの管理] をクリックします。
[sf_devops_NamedCredentials] を選択し、[保存] をクリックします。

権限セット

DevOps Centerの権限セットは５つありまして、D使用するユーザは必ずsf_devops_NamedCredentialsを割り当てしないといけません。以下は全ての権限セット一覧になります。

今回は全ての権限を自分に割り当てします。

使用方法

全ての設定が完了したら、アプリランチャーより「DevOps Center」をクリックしたら、DevOps Centerの画面に移動されます。

DevOps Centerのユーザロール（考察）

DevOps Center自体は誰でも使えるし、ロールなどはありません。しかし、やることを混乱させないためには各DevOps Centerのユーザを明確に分けないといけません。

アドミン：新しいカスタム項目やオブジェクトを作成したり、権限や設定を変更したりする役目です。
開発者（デベロッパー）：新しい物を開発したり、既存の物を改善する役目です。基本的にはコードやソースコード管理（Github）をわかる人に与えます。開発者もアドミンと同じ権限を持っています。
レビュアー：アドミンと開発が行った変更点をレビューする役目です。レビュアーは必ずGithubをわかる人ではなくてもいいですが、変更点はコードも含まれますので、コードをわかる人かつメタデータもわかる人が一番適切だと思います。
マネージャー（管理者）： DevOps Centerを管理する人です。DevOps Centerを使用するユーザ、開発の流れ、パイプライン、開発環境の整理・準備、などを管理する役目になります。アーキテクトやシステム全体をわかる人が一番適切です。

Githubに接続

ランチャーからDevOps Centerのアプリを起動したら、以下の画面に遷移されます。

「New Project」のボタンをクリックすると新規のプロジェクトを作成されますが、ただしプロジェクトを始めるにはGithubに接続する必要があります。「Connect to Github」をクリックするとGithub認証ページに移動し、認証が終わったらDevOps Centerのホーム画面に遷移されます。

プロジェクト作成

認証完了後に「New Project」のボタンをクリックすると以下の入力画面が映ります。

注意点：

Create a repository for my project that uses the Salesforce DX project structure. こちらの選択肢は新しいプロジェクトを作成し、さらにそのプロジェクトのGithubレポジトリも自動的に作成されます。
Use an existing repository for my project. This repository must use the Salesforce DX project structure. こちらの選択肢は既に存在されてるレポジトリを使用し、新しいプロジェクトを作成される形になります。

今回はデモ用のプロジェクトを既に用意してましたので、既存の選択肢を選びます。
プロジェクトを作成したら以下の画面になります。

環境を整う

プロジェクト作成されたら、リリース先の環境（組織）を指定しないといけません。「Release Environment」のカラムに「Click to Connect」リンクをクリックするとリリース先の組織の認証画面に遷移され、認証が完了しましたら、次は開発組織を設定します。以下のリンクをクリックしたらパイプライン画面に遷移されます。

パイプラインでは開発からリリースまでの組織（環境）を管理できます。以下の画像はパイプラインのデフォルトリリースまでの組織ですが、自由にカスタムできます。
例えば、今回は開発組織、テスト組織とリリース（本番）組織のみが必要であれば、他の組織を削除することができます。

①「Development Environments」の「Add Development Environments」をクリックすると開発組織を追加できます。

注意点：開発組織として使用できる組織はスクラッチ組織またはソース追跡を有効されたSandbox組織のみ
② UAT（テスト環境）を設定するためには、「Connect Environment」のボタンでテスト組織を認証させ、テスト用のGithubブランチを設定する形になります。
「Environment Name」には組織のエリアスを入力して、「Login」ボタンをクリックすると組織の認証画面に遷移され、認証が完了したら以下の画面のようになります。
注意点：

「Activate」をする前に開発環境と本番（Production）以外の環境（ステージ）はGithubのブランチを指定しないといけません。
「This is the bundling stage」のオプションはこの環境でタスクを一括で全ての次のステージ（今回は本番環境）にデプロイすることができます。

上記の事が完了したら、「Activate」ボタンでパイプラインを有効化し、環境設定が完了しました。
環境設定が完了したら、以下のように「Stages」タブが現れました。

タスクの割り振り

新規タスクは「Work Items」メニューを選択し、「New Work Item」ボタンで作成できます。

Subject」にはタスクのタイトルで、「Description」にはタスクの説明、「Assigned To」には担当者を割り当てます。

作成したら、以下の画面になります。

開発作業

DevOps Centerでは開発の流れを管理することができます。まずは上記の「Work Items」の画面より開発するタスクのIDをクリックしたら以下の画面に遷移されます。

DevOps Centerには２つの開発方法が存在されてます。

DevOps Center内で完結する開発
先程作った開発組織で開発をして、変更点やリリースする物を全てDevOps Center内で管理できます。カスタムオブジェクト作成などのコーディング以外の開発はこちらのやり方で一番適切です。コーディング開発でもこちらのやり方を使用することができます。
「I want to develop and commit my changes to the work item feature branch from DevOps Center using a connected development environment.」を選択して、開発組織を選ぶ必要があります。
DevOps Center外で開発する形
例えば開発者はDevOps Centerのアクセスがなく、Githubのみで全ての作業を管理するであればこちらのやり方の方が一番適切です。
「I want to develop and commit my changes to the work item feature branch from outside of DevOps Center.」を選択します。

今回は上記で接続済みのScratch組織を開発組織として使って開発を進む形なので、オプション①を選択します。
そして、上記の開発仕方を選んだら「Proceed」ボタンで次のステップに進めます。
もし開発組織がUAT（パイプラインの次の組織）と同期されてなかったら、以下の様に同期させる通知が表示されて、「Go to Environments tab...」ボタンでパイプラインの組織管理画面に移動できます。

組織管理画面に組織の同期をさせるには以下の「Sync」ボタンより同期することができます。

同期させるために、どんな物を同期させるや同期される際のテストは次の画面に選択できます。

同期させる物（Changes to Synchronize）

上記の説明通り、同期される物は選択できます。

Changes not in dev environment
UAT組織（テスト環境）よりには存在するが、開発組織には存在されてない物やUAT組織より差分があった物のみを同期させる
All metadata in the UAT stage's branch
UAT組織より全ての物を同期させる

Test Options （同期させる際に実行できるテスト）

Default
デフォルトのテストのみを実行する
Run local tests
ローカルテストのみを実行する
Run all tests
全てのテストを実行する
Run specified tests
指定するテストのみを実行する

今回は全ての物を同期させ、デフォルトのテストのみを実行する形で進みます。「Start Sync」ボタンで同期処理を行えます。

同期処理が完了したら、以下の様に二つの組織の間に同期されてるという状況が表示されます。

作ってきた開発作業のタスクに戻るには左メニューの「Work Items」で移動できます。

先程UAT組織と開発組織の同期が完了しましたので、接続済みの開発組織を選択できます。終わったら「Proceed」ボタンで作業項目を作成されます。

作業項目を作成したら、ステータスが「新規」から「処理中」に変更され、このプロジェクトで指定したGithubのリポジトリに自動的にブランチが作成されます。

ポイント：

Github上で作業ブランチは自動的に作られてました。こちらのリンクより作業ブランチを確認できます。
こちらのボタンで作業で変更された物を取得できます。
もし取得できなかったら、こちらのリンクより手動で作業した物を指定することができます。

開発が終わったら開発組織にデプロイし、行った変更点を上記の「PullChanges」ボタンで取得できます。

今回はApexクラスのみを開発を行ったので、Apexクラスの「StageManagement」をチェックして、コミットのコメントを記載し「Commit Changes」のボタンをクリックすると自動的にGithubへコミットをプッシュしていただけます。

コミットが完了したら以下の画像のようになります。

全てのコミットが完了しましたら、右上の「Create Review」のボタンでGithubのPullRequest（以降：PR）を自動的に作成され、ステータスが「In Review」になります。

PRを作成したら、タスクのステータスが「処理中」から「レビュー中」になります。「View Change Request」のボタンでGithub上でPRの内容を確認できます。

自動的に作られたPRは以下の様になります。

昇格・デプロイ・リリース方法

ここからはレビュアーとマネージャーの作業になります。まず上記自動的に作られたPRをGithub上で確認し、全ての確認が完了したら右上の「Ready to Promote」のスイッチより開発された物をUAT（テスト環境）に自動的に昇格（デプロイ）されます。

ステータスも「レビュー中」から「昇格準備完了」になります。
注意点：こちらのスイッチは一回ONにすると後戻りができないので、必ず全ての確認を行ってからスイッチをONにした方が無難です。
対策方法：確認漏れでスイッチONしてしまった場合、一番右の上の「🔽」のボタンをクリックし、「Change Status to Never...」のボタンで作業項目自体を無しにすることができます。しかし、こちらの処理を行ったら、一から作業項目を作成する必要があります。

昇格（デプロイ）

次はUATに昇格する処理を実行します。
一番左の「Pipeline」メニューをクリックしたら、昇格画面に遷移できます。

先程行った実装を昇格するには： ①のチェックボックスを選択して、②の「Promote Selected」ボタンでUATに昇格できます。

こちらの画面で昇格するオプションを選択できます。今回は行った変更のみを昇格し、デフォルトのテストオプションを選択します。そして「Promote」ボタンで昇格処理を実行します。

昇格処理中の画面は以下の様になります。

昇格成功したら、以下の様な画面になります。ちなみに、この処理でGithubでUATブランチから本番ブランチへのPRも自動的に作成されます。

UATの🔽のボタンをクリックすると、様々な物を確認できます。

ポイント：

Open EnvironmentでUAT組織に遷移できます。
View Branch in Source ControlでGithub上のUAT用ブランチを確認できます。
View Change Requestで本番へのPRを確認できます。
View Last Commit in Source Controlで最後のコミットの詳細をGithub上の画面に確認できます。

全ての確認が終わったら、本番へのデプロイ処理を行います。
各環境の設定の時に「This is the bundlling stage」のオプションを選んだら一括で本番へのデプロイ処理を実行できますが、今回はチェックそのオプションを利用しないので、チェックでデプロイする項目を選べます。

デプロイする項目を選んだら「Promote Selected」をボタン押して、本番環境にデプロイします。

バンドリングのデプロイの場合：本番へのデプロイする際にバージョン番号を記載できます。
バンドリングしてないのデプロイの場合：

「Promote」ボタンで本番へのデプロイを実行します。

以下は本番へデプロイ中の画面になります。

デプロイが完了しましたら以下の様な画面になります。

そして、DevOpsセンターのシステムが自動的に同期処理を各環境に行います。

まとめ

Salesforce DevOpsセンターを活用することで、開発プロセスが合理化され、チーム全体の生産性が向上します。バージョン管理、自動同期、CI/CD、監視、フィードバックの機能を通じて、高品質なアプリケーションの迅速なリリースを実現することができます。複数の開発者が関わるプロジェクト、継続的リリースが求められる環境、または大規模なカスタマイズが必要な場合には、Salesforce DevOpsセンターの使用を検討することをお勧めします。このツールは、Salesforce開発の未来を形作る上で欠かせない存在となるでしょう。

最後に

DevOpsセンターのUI上では残念ながらプロジェクトの削除とタスクの削除機能がありません。公式ドキュメントにも削除する場合のケースも記載されてません。
ただ、裏のやり方でこれらを削除することができます。こちらの削除の裏のやり方を次回の記事に記載する予定です。

何か不明な点があったら、コメントなどを残してくれると返答します。