To do this effectively, I would recommend to use Databricks Terraform provider for that - in this case the definition of the job could be stored in the Git or something like, and then it's easy to integrate with CI/CD systems, such as Azure DevOps, GitHub Actions, etc.
The differences between environments could be the coded as variables with different files with variables for different environments, etc., so you can re-use the main code between environments, like this:
provider "databricks" {
host = var.db_host
token = var.db_token
}
data "databricks_spark_version" "latest" {}
data "databricks_node_type" "smallest" {
local_disk = true
}
resource "databricks_job" "this" {
name = "Job"
new_cluster {
num_workers = 1
spark_version = data.databricks_spark_version.latest.id
node_type_id = data.databricks_node_type.smallest.id
}
notebook_task {
notebook_path = "path_to_notebook"
}
email_notifications {}
}
P.S. Theoretically, you can implement some periodic task that will pull the jobs definitions from your original environment, and check if the jobs definitions has changed, and apply the changes to another environment. You can even track changes to the jobs definitions via diagnostic logs, and use that as trigger.
But all of this is just hacks - it's better to use Terraform.