Merge pull request #3607 from replicatedhq/cmx-acronym

Add CMX acronym

Author: paigecalvert

docs/intro-replicated.mdx

@@ -27,7 +27,7 @@ The following diagram demonstrates the process of using the Replicated Platform
 
 [View a larger version of this image](/images/replicated-platform.png)
 
-The diagram above shows an application that is packaged with the [**Replicated SDK**](/vendor/replicated-sdk-overview). The application is tested in clusters provisioned with the [**Replicated Compatibility Matrix**](/vendor/testing-about), then added to a new release in the [**Vendor Portal**](/vendor/releases-about) using an automated CI/CD pipeline.
+The diagram above shows an application that is packaged with the [**Replicated SDK**](/vendor/replicated-sdk-overview). The application is tested in clusters provisioned with the [**Replicated Compatibility Matrix (CMX)**](/vendor/testing-about), then added to a new release in the [**Vendor Portal**](/vendor/releases-about) using an automated CI/CD pipeline.
 
 The application is then installed by a customer ("Big Bank") on a VM. To install, the customer downloads their license, which grants proxy access to the application images through the [**Replicated proxy registry**](/vendor/private-images-about). They also download the installation assets for the [**Replicated Embedded Cluster**](/vendor/embedded-overview) installer.
 
@@ -101,11 +101,11 @@ The following shows an example of the Enterprise Portal dashboard:
 
 ### Compatibility Matrix
 
-Replicated Compatibility Matrix can be used to create VMs or Kubernetes clusters within minutes or less. You can interact with Compatibility Matrix through the Vendor Portal or the Replicated CLI, making it possible to integrate Compatibility Matrix into your existing CI/CD workflows to programmatically create test environments.
+Replicated Compatibility Matrix (CMX) can be used to create VMs or Kubernetes clusters within minutes or less. You can interact with CMX through the Vendor Portal or the Replicated CLI, making it possible to integrate CMX into your existing CI/CD workflows to programmatically create test environments.
 
-For more information, see [About Compatibility Matrix](/vendor/testing-about).
+For more information, see [About CMX](/vendor/testing-about).
 
-The following shows the Compatibility Matrix page for creating a cluster:
+The following shows the CMX page for creating a cluster:
 
 <img alt="Create a cluster page" src="/images/create-a-cluster.png" width="650px"/>
 
@@ -143,9 +143,9 @@ For more information about using the Replicated SDK, see [About the Replicated S
 
 ### Test
 
-The Compatibility Matrix can be used to quickly provision ephemeral VMs and Kubernetes clusters. When integrated into existing CI/CD workflows, the Compatibility Matrix can be used to automatically create a variety of customer-representative environments for testing code changes.
+The CMX can be used to quickly provision ephemeral VMs and Kubernetes clusters. When integrated into existing CI/CD workflows, the CMX can be used to automatically create a variety of customer-representative environments for testing code changes.
 
-For more information, see [About Compatibility Matrix](/vendor/testing-about).
+For more information, see [About CMX](/vendor/testing-about).
 
 ### License
 
@@ -186,5 +186,5 @@ ISVs can also set up email and Slack notifications to get alerted of important i
 Support teams can use Replicated features to more quickly diagnose and resolve application issues. For example:
 
 - Customize and generate support bundles, which collect and analyze redacted information from the customer's cluster, environment, and application instance. See [About Preflight Checks and Support Bundles](/vendor/preflight-support-bundle-about).
-- Provision customer-representative environments with Compatibility Matrix to recreate and diagnose issues. See [About Compatibility Matrix](/vendor/testing-about).
+- Provision customer-representative environments with CMX to recreate and diagnose issues. See [About CMX](/vendor/testing-about).
 - Get insights into an instance's status by accessing telemetry data, which covers the health of the application, the current application version, and details about the infrastructure and cluster where the application is running. For more information, see [Customer Reporting](/vendor/customer-reporting). For more information, see [Customer Reporting](/vendor/customer-reporting).

docs/partials/ci-cd/_test-recs.mdx

@@ -1,9 +1,9 @@
-* **Application Testing:** Traditional application testing includes unit, integration, and end-to-end tests. These tests are critical for application reliability, and Compatibility Matrix is designed to to incorporate and use your application testing.
+* **Application Testing:** Traditional application testing includes unit, integration, and end-to-end tests. These tests are critical for application reliability, and CMX is designed to to incorporate and use your application testing.
 
 * **Performance Testing:** Performance testing is used to benchmark your application to ensure it can handle the expected load and scale gracefully. Test your application under a range of workloads and scenarios to identify any bottlenecks or performance issues. Make sure to optimize your application for different Kubernetes distributions and configurations by creating all of the environments you need to test in.
 
 * **Smoke Testing:** Using a single, conformant Kubernetes distribution to test basic functionality of your application with default (or standard) configuration values is a quick way to get feedback if something is likely to be broken for all or most customers. Replicated also recommends that you include each Kubernetes version that you intend to support in your smoke tests.
 
-* **Compatibility Testing:** Because applications run on various Kubernetes distributions and configurations, it is important to test compatibility across different environments. Compatibility Matrix provides this infrastructure.
+* **Compatibility Testing:** Because applications run on various Kubernetes distributions and configurations, it is important to test compatibility across different environments. CMX provides this infrastructure.
 
-* **Canary Testing:** Before releasing to all customers, consider deploying your application to a small subset of your customer base as a _canary_ release. This lets you monitor the application's performance and stability in real-world environments, while minimizing the impact of potential issues. Compatibility Matrix enables canary testing by simulating exact (or near) customer environments and configurations to test your application with.
+* **Canary Testing:** Before releasing to all customers, consider deploying your application to a small subset of your customer base as a _canary_ release. This lets you monitor the application's performance and stability in real-world environments, while minimizing the impact of potential issues. CMX enables canary testing by simulating exact (or near) customer environments and configurations to test your application with.

docs/vendor/ci-overview.md

@@ -16,9 +16,9 @@ The following are Replicated's best practices and recommendations for CI/CD:
 
 * Include unique workflows for development and for releasing your application. This allows you to run tests on every commit, and then to promote releases to internal and customer-facing channels only when ready. For more information about the workflows that Replicated recommends, see [Recommended CI/CD Workflows](ci-workflows).
 
-* Integrate Replicated Compatibility Matrix into your CI/CD workflows to quickly create multiple different types of clusters where you can deploy and test your application. Supported distributions include OpenShift, GKE, EKS, and more. For more information, see [About Compatibility Matrix](testing-about).
+* Integrate Replicated Compatibility Matrix (CMX) into your CI/CD workflows to quickly create multiple different types of clusters where you can deploy and test your application. Supported distributions include OpenShift, GKE, EKS, and more. For more information, see [About CMX](testing-about).
 
-* If you use the GitHub Actions CI/CD platform, integrate the custom GitHub actions that Replicated maintains to replace repetitive tasks related to distributing application with Replicated or using Compatibility Matrix. For more information, see [Use Replicated GitHub Actions in CI/CD](/vendor/ci-workflows-github-actions).
+* If you use the GitHub Actions CI/CD platform, integrate the custom GitHub actions that Replicated maintains to replace repetitive tasks related to distributing application with Replicated or using CMX. For more information, see [Use Replicated GitHub Actions in CI/CD](/vendor/ci-workflows-github-actions).
 
 * To help show you are conforming to a secure supply chain, sign all commits and container images. Additionally, provide a verification mechanism for container images.
 

docs/vendor/ci-workflows-github-actions.md

@@ -4,7 +4,7 @@ This topic describes how to integrate Replicated's custom GitHub actions into co
 
 ## Overview
 
-Replicated maintains a set of custom GitHub actions that are designed to replace repetitive tasks related to distributing your application with Replicated and related to using the Compatibility Matrix, such as:
+Replicated maintains a set of custom GitHub actions that are designed to replace repetitive tasks related to distributing your application with Replicated and related to using Replicated Compatibility Matrix (CMX), such as:
   * Creating and removing customers, channels, and clusters
   * Promoting releases
   * Creating a matrix of clusters for testing based on the Kubernetes distributions and versions where your customers are running application instances
@@ -119,7 +119,7 @@ For an up-to-date list of the avilable custom GitHub actions, see the [replicate
   </tr>
   <tr>
     <td><a href="https://github.com/replicatedhq/replicated-actions/tree/main/report-compatibility-result">report-compatibility-result</a></td>
-    <td>In development or release workflows, use this action to report the success or failure of tests that ran in clusters provisioned by the Compatibility Matrix.</td>
+    <td>In development or release workflows, use this action to report the success or failure of tests that ran in clusters provisioned by CMX.</td>
     <td><code>release compatibility</code></td>
   </tr>
   <tr>

docs/vendor/ci-workflows.mdx

@@ -6,7 +6,7 @@ This topic provides Replicated's recommended development and release workflows f
 
 ## Overview
 
-Replicated recommends that you maintain unique CI/CD workflows for development (continuous integration) and for releasing your software (continuous delivery). The development and release workflows in this topic describe the recommended steps and jobs to include in your own workflows, including how to integrate Replicated Compatibility Matrix into your workflows for testing. For more information about Compatibility Matrix, see [About Compatibility Matrix](testing-about).
+Replicated recommends that you maintain unique CI/CD workflows for development (continuous integration) and for releasing your software (continuous delivery). The development and release workflows in this topic describe the recommended steps and jobs to include in your own workflows, including how to integrate Replicated Compatibility Matrix (CMX) into your workflows for testing. For more information about CMX, see [About CMX](testing-about).
 
 For each step, the corresponding Replicated CLI command is provided. Additionally, for users of the GitHub Actions platform, a corresponding custom GitHub action that is maintained by Replicated is also provided. For more information about using the Replicated CLI, see [Install the Replicated CLI](/reference/replicated-cli-installing). For more information about the Replicated GitHub actions, see [Use Replicated GitHub Actions in CI/CD](ci-workflows-github-actions).
 
@@ -64,11 +64,11 @@ jobs:
 
 ### Prepare clusters, deploy, and test {#dev-deploy}
 
-Add a job with the following steps to prepare clusters with Replicated Compatibility Matrix, deploy the application, and run tests:
+Add a job with the following steps to prepare clusters with CMX, deploy the application, and run tests:
 
-1. Use Replicated Compatibility Matrix to prepare one or more clusters and deploy the application. Consider the following recommendations:
+1. Use CMX to prepare one or more clusters and deploy the application. Consider the following recommendations:
 
-    * For development workflows, Replicated recommends that you use the `cluster prepare` command to provision one or more clusters with Compatibility Matrix. The `cluster prepare` command creates a cluster, creates a release, and installs the release in the cluster, without the need to promote the release to a channel or create a temporary customer. See the [`cluster prepare`](/reference/replicated-cli-cluster-prepare) Replicated CLI command. Or, for GitHub Actions workflows, see the [prepare-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/prepare-cluster) GitHub action.
+    * For development workflows, Replicated recommends that you use the `cluster prepare` command to provision one or more clusters with CMX. The `cluster prepare` command creates a cluster, creates a release, and installs the release in the cluster, without the need to promote the release to a channel or create a temporary customer. See the [`cluster prepare`](/reference/replicated-cli-cluster-prepare) Replicated CLI command. Or, for GitHub Actions workflows, see the [prepare-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/prepare-cluster) GitHub action.
 
      :::note
      The `cluster prepare` command is Beta. It is recommended for development only and is not recommended for production releases. For production releases, Replicated recommends that you use the `cluster create` command instead. For more information, see [Create cluster matrix and deploy](#rel-deploy) in _Release Workflow_ below.
@@ -80,13 +80,13 @@ Add a job with the following steps to prepare clusters with Replicated Compatibi
 
 1. After the tests complete, remove the cluster. Alternatively, if you used the `--ttl` flag with the `cluster prepare` command, the cluster is automatically removed when the time period provided is reached. See the [`cluster remove`](/reference/replicated-cli-cluster-prepare) Replicated CLI command. Or, for GitHub Actions workflows, see the [remove-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/remove-cluster) action.
 
-## Compatibility Matrix-Only Development Workflow
+## CMX-Only Development Workflow
 
 In a development workflow (which runs multiple times per day and is triggered by a commit to the application code repository), the source code is built and the application is deployed to clusters for testing. 
 
 This example development workflow does _not_ create releases or customers in the Replicated vendor platform. This workflow is useful for applications that are not distributed or managed in the Replicated platform.
 
-The following describes the recommended steps to include in a development workflow using Compatibility Matrix:
+The following describes the recommended steps to include in a development workflow using CMX:
 
 1. [Define workflow triggers](#dev-triggers)
 1. [Build source code](#dev-build)
@@ -120,9 +120,9 @@ jobs:
 
 ### Create cluster matrix, deploy, and test {#dev-deploy}
 
-Add a job with the following steps to provision clusters with Compatibility Matrix, deploy your application to the clusters, and run tests:
+Add a job with the following steps to provision clusters with CMX, deploy your application to the clusters, and run tests:
 
-1. Use Compatibility Matrix to create a matrix of different Kubernetes cluster distributions and versions to run tests against. See the [cluster create](/reference/replicated-cli-cluster-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/create-cluster) action.
+1. Use CMX to create a matrix of different Kubernetes cluster distributions and versions to run tests against. See the [cluster create](/reference/replicated-cli-cluster-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/create-cluster) action.
 
    The following example shows creating a matrix of clusters of different distributions and versions using GitHub Actions:
 
@@ -141,7 +141,7 @@ Add a job with the following steps to provision clusters with Compatibility Matr
             - {distribution: openshift, version: "4.13.0-okd"} 
     ```
 
-1. For each cluster created, use the cluster's kubeconfig to update Kubernetes context and then install the target application in the cluster. For more information about accessing the kubeconfig for clusters created with Compatibility Matrix, see [cluster kubeconfig](/reference/replicated-cli-cluster-kubeconfig).
+1. For each cluster created, use the cluster's kubeconfig to update Kubernetes context and then install the target application in the cluster. For more information about accessing the kubeconfig for clusters created with CMX, see [cluster kubeconfig](/reference/replicated-cli-cluster-kubeconfig).
 
 1. Run tests, such as integration, smoke, and canary tests. For more information about recommended types of tests to run, see [Best Practices and Recommendations](/vendor/ci-overview#best-practices-and-recommendations) in _About Integrating with CI/CD_.
 
@@ -242,11 +242,11 @@ Consider the following requirements and recommendations:
 
 ### Create cluster matrix, deploy, and test {#rel-deploy}
 
-Add a job with the following steps to provision clusters with Compatibility Matrix, deploy the release to the clusters, and run tests:
+Add a job with the following steps to provision clusters with CMX, deploy the release to the clusters, and run tests:
 
 1. Create a temporary customer for installing the release. See the [customer create](/reference/replicated-cli-customer-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-customer](https://github.com/replicatedhq/replicated-actions/tree/main/create-customer) action.
 
-1. Use Compatibility Matrix to create a matrix of different Kubernetes cluster distributions and versions to run tests against. See the [cluster create](/reference/replicated-cli-cluster-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/create-cluster) action.
+1. Use CMX to create a matrix of different Kubernetes cluster distributions and versions to run tests against. See the [cluster create](/reference/replicated-cli-cluster-create) Replicated CLI command. Or, for GitHub Actions workflows, see the [create-cluster](https://github.com/replicatedhq/replicated-actions/tree/main/create-cluster) action.
 
    Consider the following recommendations:
 
@@ -273,7 +273,7 @@ Add a job with the following steps to provision clusters with Compatibility Matr
             - {distribution: openshift, version: "4.13.0-okd"} 
     ```
 
-1. For each cluster created, use the cluster's kubeconfig to update Kubernetes context and then install the target application in the cluster. For more information about accessing the kubeconfig for clusters created with Compatibility Matrix, see [cluster kubeconfig](/reference/replicated-cli-cluster-kubeconfig).
+1. For each cluster created, use the cluster's kubeconfig to update Kubernetes context and then install the target application in the cluster. For more information about accessing the kubeconfig for clusters created with CMX, see [cluster kubeconfig](/reference/replicated-cli-cluster-kubeconfig).
 
   For more information about installing in an existing cluster, see:
   * [Installing with Helm](/vendor/install-with-helm)