Understanding Transformations (Edge)

The following sections walk you through:

• Transformation Architecture: The structure of the dbt projects, environments, and jobs within Hevo.

• dbt Project Workflow: The end-to-end workflow from a code change in GitHub to analytics-ready data in your Destination.

---

Transformation Architecture

The following diagram illustrates how the components of Transformations are organized and how they build on each other:

• A Transformation connects a GitHub repository to Hevo and serves as the workspace for a single dbt project. It contains all the environments, jobs, and runs associated with that project.

• Each environment connects to a specific Git branch and Destination. It can be configured as Staging, for testing changes before they go live, or Production, for running dbt models on live business data. Each environment can have multiple jobs.

• Jobs define which dbt commands to execute and when to trigger them. You can create Continuous Integration (CI), Merge, and Deploy jobs, each serving a different stage of the development workflow. Read dbt Project Workflow to understand how these job types work together.

• Every time a job executes, a run is created, recording the full outcome of the execution. This includes step-by-step execution logs, a lineage graph showing how data flows through your models, and dbt artifacts generated during the run.

---

dbt Project Workflow

When a code change is made to a dbt model, Transformations follows a structured workflow to take that change from a GitHub repository to analytics-ready data in your Destination. This workflow involves three job types, Continuous Integration (CI), Merge, and Deploy, each handling a specific stage of the process. The following diagram illustrates this end-to-end workflow:

• A developer pushes a code change and opens a pull request on GitHub.

• A continuous integration (CI) job automatically validates the code, checking for errors before the change is merged. If the CI job fails, the pull request is not merged, and the workflow stops until the errors are resolved.

• Once the pull request is approved and merged, a merge job applies the changes to the environment.

• A deploy job then runs the updated dbt models in your Destination, producing the final tables.

Each job type is triggered automatically by the preceding step. Deploy jobs can also be triggered manually, on a schedule, or automatically after a Pipeline sync, not only as part of the CI/Merge workflow.

---

See Also

• Familiarizing with the Transformations UI

• Creating your First Transformation Project

---

Revision History