> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/database-devops/use-db-devops/understanding-state-of-database/unified-environment-overview.md).

# User Interface of Harness Database DevOps

Learn how to navigate the Harness Database DevOps user interface, including schema views, pipeline executions, deployment monitoring, and pinned plugin image versions.

This guide talks you through the UI of Harness Database DevOps.

### Environment overview for Database DevOps

![A screenshot of the Harness Database DevOps page that highlights the menu on the left of the UI.](https://4089095456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWwqb27iUU3gZvwGNroZp%2Fuploads%2Fgit-blob-01235cbc5dc4907595dbd371b1fea0aac6149f53%2Fdb-devops-overview.png?alt=media)

When you open the Harness Database DevOps module, you will encounter a single-pane interface that will display an overview of important activities relevant to using DB DevOps. The following sections describe what you can expect:

* **Left Navigation Menu**: A dropdown menu displaying multiple navigation options.
* **DB Schemas**: Located at the top-left under the overview tab, this section shows the number of database schemas you have created.
* **DB Instances**: This appears directly beneath the **DB Schemas** tab and indicates the number of database instances you have created.
* **Most Recent 5 Deployments**: This section displays the five most recent deployments, including the name of the **schema**, the **instance** it ran on, and the **last deployed** date.
* **Last 30 Days Pipeline Executions**: This shows the number of pipeline executions in the last 30 days from the point of login, including both failed and successful executions. It will include both failed and successful executions. Users can toggle between a bar graph and a line graph for visualization.
* **Migration State**: This indicates the status of recent changesets. A key in the top right of this section helps identify the statuses displayed in the table.

### Unified environment overview for database schemas

![Unified View that highlights the Database Schemas Applied](https://4089095456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWwqb27iUU3gZvwGNroZp%2Fuploads%2Fgit-blob-4d5363928638acc1889c3b56a1975273c0954e2c%2Fdbops-unified-view.png?alt=media)

When you click on **DB Schemas** section from the left-hand menu. Then, select the database schema you want to check. Once selected, click on the **Migration State** option under one of the connected DB Instances. This will open a clear, single-page view that shows all the changes linked to that schema in the database, whether they are pending, in progress, or already completed.

This overview provides insights into the database states in both production and non-production environments, allowing for quick assessments of readiness and synchronization. Here is what you will find in this section:

* **Add New DB Schema**: At the top of the menu, you have the option to create a new schema.
* **Database Schema**: The name of the database schema.
* **Associated Service**: The service associated with the schema.
* **DB Instances**: The number of database instances linked to the schema.
* **Last Schema Update**: The date of when the schema was last updated.
* **Three Point Menu**: Selecting this at the end of a highlighted database schema provides options to edit the schema details or delete it.

### Harness Database DevOps pipelines overview

![A screenshot of the Harness Database DevOps Pipeline UI](https://4089095456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWwqb27iUU3gZvwGNroZp%2Fuploads%2Fgit-blob-4efec446e2dd31335dbf19680061941f368543df%2Fdb-devops-pipelines-page.png?alt=media)

On the DB DevOps **Pipelines** UI, you are provided with a detailed overview that offers useful information for understanding the status of the pipelines in your environments. The following fields appear on the Harness Database DevOps **Pipelines** interface:

* **Pipeline Name**: The name of the pipeline
* **Code Source**: The source of the code, whether it be inline or stored in a repository.
* **Recent Executions**: The status of recent pipeline executions, with the latest status displayed on the right of the status bar.
* **Last execution**: The name of the person who last ran the pipeline and the dates it was executed, displayed in an estimate of hours, days, months or years beneath the user's name.
* **Last modified**: The date of when the pipeline was last modified.

### Changeset view in the Harness Database DevOps UI

<figure><img src="https://4089095456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWwqb27iUU3gZvwGNroZp%2Fuploads%2Fgit-blob-a8ab2c4bc3a3b195a8e80f63ce471e2c96772196%2Fdbops-changeset-view.png?alt=media" alt=""><figcaption></figcaption></figure>

Clicking on a ChangeSet opens the detail pane on the right-hand side of the UI. This panel provides two tabs:

* **ChangeSets (YAML)**: Displays the structured YAML definition of the applied change, including metadata such as the ID, author, object strategy, and specific change operation (e.g., createIndex).
* **SQL**: For script-based changes, this tab shows the actual SQL that was executed, ensuring transparency and auditability for database administrators and platform engineers.

Within the Migration State tab of the Harness Database DevOps platform, you have clear visibility into the applied changesets across database environments. This view is instrumental in tracking schema-level changes and understanding the evolution of your data models over time. The Migration State interface contains the following information:

* **Change ID**: A unique identifier for each ChangeSet, often scoped by team or environment for traceability (e.g., `devteam:2`).
* **Author**: The email address of the individual or service account or author name responsible for creating the ChangeSet.
* **Comment**: A descriptive message associated with the ChangeSet to indicate the purpose or context of the change.
* **Changes**: A detailed list of schema-level actions applied in the ChangeSet, such as `createIndex`, `addColumn` or `dropTable`. This allows DB admins and developers to quickly assess what structural updates were made to the database without manually inspecting scripts.

### Database DevOps executions overview

![A screenshot of the Harness Database DevOps Executions UI](https://4089095456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWwqb27iUU3gZvwGNroZp%2Fuploads%2Fgit-blob-7f707b79585479d911ded67e900549a10473bb7a%2Fdb-devops-executions-overview.png?alt=media)

The Harness DB DevOps **Executions** UI provides a comprehensive view of the execution statuses of your pipelines. Here is a detailed breakdown of the elements you will find on the DB DevOps **Executions** interface:

* **Pipeline Name**: This column displays the name of the pipeline that was executed, allowing users to identify which pipeline is being referenced.
* **Status**: The current status of the pipeline execution, showing whether it has passed or failed. This is crucial for quickly assessing the outcome of recent deployments.
* **Service**: This lists the service associated with the pipeline, providing context on which application or service the changes were applied to.
* **Environment**: The environment in which the pipeline was executed, such as development, staging, or production, helping users understand the context of the deployment.
* **Execution start time:** The name of the person who last initiated the pipeline execution, along with the date and time it was executed. The time is presented in a user-friendly format, estimating hours, days, months, or years beneath the user's name, which aids in tracking when changes were made.

### Access control for Harness Database DevOps

Harness Database DevOps uses the standard Harness role based access control (RBAC) model. You can invite users at the account, organization, or project level and assign them roles that control what they can view or manage within Database DevOps.

* **Account level**: Account Admin and Account Viewer roles grant access across all organizations and projects under the account. Use this level for platform administrators who need visibility into all deployments.
* **Organization level**: Organization Admin and Organization Viewer roles grant access to all projects within an organization. Use this level for DBAs or team leads responsible for multiple projects.
* **Project level**: Project Admin and Project Viewer roles grant access to resources scoped to a single project, including DB schemas, instances, pipelines, and executions. Use this level for individual contributors or reviewers working on a specific application.

If a user attempts to access a project without the required role, Harness displays a permission error. The error identifies the missing permission (for example, `core_project_view`) and the project identifier, so an account or organization admin can assign the correct role.

![Permission error for a user who is missing the core\_project\_view permission on a project](https://4089095456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWwqb27iUU3gZvwGNroZp%2Fuploads%2Fgit-blob-8bc2077da3b5d8820fb4994312256bcf511df380%2Fdbops-rbac-permission-error.png?alt=media)

Go to [RBAC in Harness](https://developer.harness.io/harness-platform/use-harness-platform/platform-access-control) to configure roles and invite users.

### Pinned image versions

Harness Database DevOps can pin the plugin images that pipelines pull at runtime. A pinned tag keeps execution on a known image when Harness publishes a newer default. This account setting is available from Database DevOps 1.109.x.

You choose the pinning mode that matches your requirement. Use **Default (Harness Managed)** when you want Harness to keep the current image. Use **Pin to version** or **Database specific (Advanced)** when you need a locked tag for a plugin or for a specific database.

Go to [Harness DB DevOps image list](/database-devops/new-to-database-devops/overview.md#harness-db-devops-image-list) to review image names and tag format. Go to [Database DevOps release notes](https://developer.harness.io/release-notes/database-devops) for the tags shipped in each release.

![Account Default Settings with the Pinned Image versions section](https://4089095456-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWwqb27iUU3gZvwGNroZp%2Fuploads%2Fgit-blob-0c6f0c3ea3779415650137a8a000c7afec85b68c%2Fdbops-pinned-image-versions.png?alt=media)

To open **Pinned Image versions**, do the following:

1. Navigate to **Account Settings**.
2. Under **General**, select **Default Settings**.
3. Select **Database DevOps**.
4. Open **Pinned Image versions**.

The page lists **Artifactory**, **Git Clone**, **Liquibase**, and **Flyway**. You can pin any combination of these plugins. Plugins that you do not pin continue to use **Default (Harness Managed)**.

* **Default (Harness Managed):** Pipelines use the image tag Harness currently publishes. Harness updates this tag when a new default ships.
* **Pin to version:** Pipelines use the image tag you enter. Use this when you want one locked tag for that plugin across the account. For example, pin Liquibase to `plugins/drone-liquibase:1.44.0-4.33` so every pipeline uses that plugin until you change it.
* **Database specific (Advanced):** Available for **Liquibase** and **Flyway**. Select the database that matches your requirement, then enter the image tag for that plugin. For example, pin Liquibase to a BigQuery plugin, or pin Flyway to a MongoDB plugin, if those are the databases you run. The dropdown lists the database-specific plugins available in your account. Pin only the databases you use.

**Artifactory** and **Git Clone** support **Default (Harness Managed)** and **Pin to version** only.

When you select **Pin to version** or **Database specific (Advanced)**, enter the full image reference in `repository:tag` form. The following values are examples only. Use a tag that matches the plugin and release you intend to run:

* **Artifactory:** `plugins/download-artifactory:1.1.3`
* **Git Clone:** `harness/drone-git:1.7.16-rootless`
* **Liquibase (Pin to version):** `plugins/drone-liquibase:1.44.0-4.33`
* **Liquibase for BigQuery:** `plugins/drone-liquibase:1.44.0-4.33-bigquery`
* **Flyway for MongoDB:** `plugins/drone-flyway-mongo:1.3.0-11.11.2-mongo`

For **Database specific (Advanced)**, select the database in the dropdown, enter its tag, then confirm. Repeat only for the databases you need to pin.

Click **Restore to Default** to return pinned plugins to Harness-managed images. Click **Save** at the top of **Account Default Settings** to apply the change.

**Pinned Image versions** applies at the account scope. You need view and edit permissions for Default Settings at the account level. Go to [Default settings](https://developer.harness.io/harness-platform/use-harness-platform/settings/default-settings) to review permissions and restore behavior.

You can also read and update image tags through the Database DevOps execution-config APIs. Go to [Configure Harness DB DevOps image versions](/database-devops/new-to-database-devops/overview.md#configure-harness-db-devops-image-versions) to use those endpoints.

### Next steps

* Go to [Create a pipeline in Database DevOps](/database-devops/use-db-devops/deployment-pipeline-configuration/create-a-pipeline.md) to set up your first deployment pipeline.
* Go to [Access applied changesets](/database-devops/use-db-devops/understanding-state-of-database/access-applied-changesets.md) to query the migration state programmatically from pipeline steps.
* Go to [Configure Harness DB DevOps image versions](/database-devops/new-to-database-devops/overview.md#configure-harness-db-devops-image-versions) to override image tags with the API.

{% @harness-feedback/feedback %}
