dataprovider01/template-code-location
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[SIMPL-27992](https://jira.simplprogramme.eu/browse/SIMPL-27992) Document Workflow Deletion Process.

Browse Source 
Changelog: added
This commit is contained in:
Adrian LODIN
2026-05-27 17:42:51 +03:00
parent f5daf2f748
commit 81bb3299a4
1 changed files with 25 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
documents/Development Guide.md
View File

@@ -2,7 +2,7 @@
## 1. Goal and Scope ## 1. Goal and Scope
The purpose of this document is to provide a comprehensive guide for participants to create, manage, and update workflows within the Simpl-Open orchestration platform. The purpose of this document is to provide a comprehensive guide for participants to create, manage, update and delete workflows within the Simpl-Open orchestration platform.
By following a *code-first approach*, developers ensure consistency, traceability, and reliability across all environments. By following a *code-first approach*, developers ensure consistency, traceability, and reliability across all environments.
## 2. Local Development ## 2. Local Development
@@ -43,7 +43,10 @@ The heavy-lifting logic lives in separate repositories, pulled in as installable
These packages expose their jobs and ops which are then imported and registered in `repository.py`. These packages expose their jobs and ops which are then imported and registered in `repository.py`.
### 2.3 Code Examples (Ops, Jobs, and Definitions) ### 2.3 Code Examples (Ops, Jobs, and Definitions)
The orchestration logic should be modular. Here is a practical example of how to construct a workflow. The orchestration logic should be modular.
### 2.3.1 Workflow creation
Here is a practical example of how to construct a workflow.
**1. Defining Ops (`ops/ops.py`)** **1. Defining Ops (`ops/ops.py`)**
Ops are the core units of computation. Keep them focused on a single task. Ops are the core units of computation. Keep them focused on a single task.
@@ -101,6 +104,23 @@ defs = Definitions(
) )
``` ```
### 2.3.2 Workflow deletion
Here is a practical example of how to delete a workflow.
**1. Pre-delete check**
Before deleting an existing workflow, first check its status (if is needed or referenced):
- **Dagster UI**: Navigate to the "Runs". Identify a given worklog using the "Filter" button or navigation "Newer", "Older" buttons.
- **Details, logs check:** Check workflow status, open it by clicking on it's target or open logs by clicking on it's uuid.
**2. Delete Ops (`ops/ops.py`)**
If the workflow is defined as an op, delete it's corresponding method from the `ops.py` file.
**3. Delete Jobs (`jobs/jobs.py`)**
If the workflow is defined as a job, delete it's corresponding method from the `jobs.py` file.
**4. Delete Registering Definitions (`repository.py`)**
Delete workflow import, and it's definition from the `repository.py`
### 2.4 Best Practices & Constraints ### 2.4 Best Practices & Constraints
- **Separation of Concerns**: Keep orchestration logic (how ops connect) strictly separate from heavy business logic (which should ideally live in separate Python modules/classes). - **Separation of Concerns**: Keep orchestration logic (how ops connect) strictly separate from heavy business logic (which should ideally live in separate Python modules/classes).
@@ -145,7 +165,9 @@ The deployment follows these automated steps:
To confirm a successful deployment: To confirm a successful deployment:
- **Dagster UI**: Navigate to the "Deployment" or "Code Locations" tab. Verify that the loaded image tag matches the latest Git commit. - **Dagster UI**:
- Navigate to the "Deployment" or "Code Locations" tab. Verify that the loaded image tag matches the latest Git commit.
- Navigate to the "Runs" tab. Identify deleted workflow. Click on it's target to open details. "Pipeline not found" message shows that workflow was deleted successfully. Click on it's uuid to open logs. Logs must be available after deletion.
- **Health Check**: Trigger a "Test Run" of the job in the production environment using a limited data slice. - **Health Check**: Trigger a "Test Run" of the job in the production environment using a limited data slice.
- **Logs**: Monitor the initialization logs in the Dagster daemon to ensure the code location was loaded without schema or dependency errors. - **Logs**: Monitor the initialization logs in the Dagster daemon to ensure the code location was loaded without schema or dependency errors.