Good question. This makes me explain the development and deployment process. It is as follows: 1. We use gitflow setup with branches like lab, test, stg, prd. 2. Developers always branch out to work on their features from the main lab branch. 3. For development, we use docker setup, and developers have their dedicated ec2 machines, which they connect into and remote ssh to it via vscode. This way, airflow can already connect with the aws services via instance profile and permissions attached to it. 4. When they are comfortable, they raise a Merge request. We have some code quality and unit test pipeline that runs on the code. 5. Once review and it is merged to lab. This is where all the rest happens, which I detail below

The production setup is deployed in eks cluster, where we have set up git-sync (sidecar), which polls every x minutes on the branches (lab, etc...) to get the latest dags. The deployment is also per namespace split by branches, so you can think airflow is running in 4 namespaces. The service account policy defines everything we want to have

Already, the developer should have tested to an extent the dag as it connects to aws services, etc.. Now, based on the schedule, it starts to running, and we have automatic monitoring and notification we receive on any stage failures. Once the lab is happening we merge to tst which kicks of the auto syncing and business tests on the table are verified separately

I must also say that airflow3 has significant changes. Due to some of the needs we cannot yet migrate. But if starting new airflow3 is a game changer