Merge pull request #52951 from weslbo/images-implement-development-lifecycle-processes-in-azure-databricks

Updated images

Author: Stacyrch140

learn-pr/wwl-databricks/implement-development-lifecycle-processes-in-azure-databricks/includes/2-apply-version-control-git.md

@@ -4,6 +4,8 @@ Data engineering projects require systematic tracking of code changes, collabora
 
 Git folders bring version control capabilities into your Azure Databricks workspace through a **visual Git client** and API. This integration lets you perform standard Git operations such as **cloning repositories**, **creating branches**, **committing changes**, and **pushing updates** directly from the workspace interface. You don't need to switch between external tools and your development environment.
 
+:::image type="content" source="../media/2-understand-git-folders-azure-databricks.png" alt-text="Diagram explaining git folders in Azure Databricks." border="false" lightbox="../media/2-understand-git-folders-azure-databricks.png":::
+
 When you create a Git folder, you connect it to a **remote repository** hosted by providers like Azure DevOps, GitHub, GitLab, or Bitbucket. The folder mirrors your repository structure, allowing you to work with notebooks, Python files, SQL scripts, and other supported assets while maintaining version control. All team members can have their own Git folders mapped to the same remote repository, enabling **collaboration through shared branches** and coordinated commits.
 
 > [!TIP]
@@ -22,6 +24,8 @@ To clone a repository:
 5. Provide a name for the folder in your workspace.
 6. Select **Create Git folder**.
 
+:::image type="content" source="../media/2-create-git-folder.png" alt-text="Screenshot of the Create Git folder dialog." lightbox="../media/2-create-git-folder.png":::
+
 After cloning, the repository contents appear in your workspace. You can open notebooks, edit files, and begin development immediately.
 
 ## Pull changes from the remote repository
@@ -34,6 +38,8 @@ To pull changes:
 2. Select **Pull** to fetch and merge changes from the remote repository.
 3. If conflicts exist between remote changes and your local modifications, resolve them using the **conflict resolution interface**.
 
+:::image type="content" source="../media/2-commit-push.png" alt-text="Screenshot of the git dialog in Azure Databricks." lightbox="../media/2-commit-push.png":::
+
 **Pull regularly**, especially before starting new work, to minimize integration issues. When you pull changes that modify notebook source code, the **notebook state resets**. This means cell outputs, comments, and version history for that notebook clear to reflect the updated content.
 
 ## Keep your repository organized

learn-pr/wwl-databricks/implement-development-lifecycle-processes-in-azure-databricks/includes/3-manage-branching-pull-requests-conflicts.md

@@ -1,5 +1,7 @@
 Collaborative development in Azure Databricks relies on effective **version control practices**. When multiple team members work on notebooks and code files simultaneously, you need a structured approach to **isolate changes**, **review code**, and **integrate work** without disrupting production workflows.
 
+:::image type="content" source="../media/3-manage-branching-pull-requests-conflicts.png" alt-text="Diagram showing how to manage branching, pull requests and conflicts." border="false" lightbox="../media/3-manage-branching-pull-requests-conflicts.png":::
+
 Azure Databricks Git folders provide a visual Git client that integrates directly with your workspace. This integration lets you perform common Git operations—branching, committing, and merging—without leaving the Azure Databricks environment.
 
 ## Create and manage branches
@@ -12,6 +14,8 @@ To create a new branch:
 2. Select **Create branch** and enter a descriptive name.
 3. Base your branch on the appropriate source branch, typically `main`.
 
+:::image type="content" source="../media/3-create-branch.png" alt-text="Screenshot of the create branch dialog." lightbox="../media/3-create-branch.png":::
+
 Use a **consistent naming convention** for branches to identify work clearly. Common patterns include:
 
 - `feature/feature-name` for new functionality

learn-pr/wwl-databricks/implement-development-lifecycle-processes-in-azure-databricks/includes/4-implement-testing-strategy.md

@@ -6,6 +6,8 @@ In this unit, you learn how to implement a testing strategy that covers **unit t
 
 A well-designed testing strategy follows the **testing pyramid** concept. At the base, you have many fast, isolated unit tests. Moving up, you have fewer integration tests that verify component interactions. At the top, you have a small number of comprehensive end-to-end tests and UAT scenarios.
 
+:::image type="content" source="../media/4-understand-test-pyramid.png" alt-text="Diagram showing the testing pyramid." border="false" lightbox="../media/4-understand-test-pyramid.png":::
+
 This structure exists because different test types serve different purposes:
 
 | Test type             | Purpose                                             | Scope                    | Speed               |

learn-pr/wwl-databricks/implement-development-lifecycle-processes-in-azure-databricks/includes/5-configure-package-databricks-asset-bundles.md

@@ -1,5 +1,7 @@
 When you work on data engineering projects, you need a systematic way to define, package, and deploy your Databricks resources across environments. **Databricks Asset Bundles (DABs)** provide an **infrastructure-as-code** approach that lets you describe jobs, pipelines, and other resources in YAML configuration files. By configuring and customizing these bundles, you can **automate deployments** and ensure consistency between development and production workspaces.
 
+:::image type="content" source="../media/5-configure-package-databricks-asset-bundles.png" alt-text="Diagram explaining Databricks asset bundles." border="false" lightbox="../media/5-configure-package-databricks-asset-bundles.png":::
+
 ## Understand the bundle configuration structure
 
 A Databricks Asset Bundle consists of **YAML configuration files** that define your project's resources and deployment settings. The primary configuration file, `databricks.yml`, must exist at the **root of your bundle project**. This file establishes the bundle's identity and can reference additional configuration files for better organization.

learn-pr/wwl-databricks/implement-development-lifecycle-processes-in-azure-databricks/includes/6-deploy-bundle-databricks-cli.md

@@ -1,5 +1,7 @@
 After your team packages a data asset bundle, deploying it to Azure Databricks becomes your next responsibility. The **Databricks CLI** provides a direct path from your local development environment to production workspaces. You control when and where your pipelines, jobs, and other resources go live. Understanding this **deployment workflow** enables you to move code reliably across environments while maintaining consistency.
 
+:::image type="content" source="../media/6-deploy-bundle-databricks-cli.png" alt-text="Diagram explaining the different steps when deploying a bundle with Databricks CLI." border="false" lightbox="../media/6-deploy-bundle-databricks-cli.png":::
+
 ## Validate bundle configuration
 
 Before deploying, confirm that your bundle configuration is **syntactically correct** and complete. The `bundle validate` command checks your configuration files and reports any issues that would prevent successful deployment.