我们目前正在为 Cloud Composer 上的 Airflow (>2.0.1) 开发自定义运算符和传感器。我们使用官方 Docker 镜像进行测试/开发
从 Airflow 2.0 开始，推荐的方法是不要将它们放在 Airflow 的插件目录中，而是将它们构建为单独的 Python 包。然而，在开发 DAG 并在 Docker Airflow 上对其进行测试时，这种方法似乎相当复杂。
要使用 Airflows 推荐的方法，我们将为 DAG 和操作员/传感器使用两个单独的存储库，然后将自定义操作员/传感器包挂载到 Docker 以在此处快速测试并在本地计算机上对其进行编辑。为了在 Composer 上进一步使用，我们需要将我们的包发布到我们的私有 pypi 存储库并将其安装在 Cloud Composer 上。
但是，将所有内容都放在本地插件文件夹中的旧方法非常简单，无法解决这些问题。
根据您的经验，您推荐的开发和测试自定义操作器/传感器的方法是什么？
【问题讨论】：
标签： airflow
您可以将“通用”代码（自定义运算符等）放在 dags 文件夹中，并通过 .airflowignore 文件将其排除在调度程序处理之外。这允许在开发内容时进行相当快的迭代。
您仍然可以将 DAG 和“通用代码”保存在单独的存储库中，以使事情变得更容易。您可以轻松地为此使用“子模块”模式（添加“通用”存储库作为 DAG 存储库的子模块 - 这样您就可以一起检查它们，您甚至可以保留不同的 DAG 目录（针对不同的团队）具有不同的以这种方式获取通用包的版本（只需将其子模块链接到不同版本的包）。
我认为“打包”模式更多的是生产部署而不是开发。一旦您在本地开发了通用代码，如果您将其打包在通用包和版本中（与任何其他 python 包相同），那就太好了。然后你可以在测试后发布它，版本它等等。
在“开发”模式下，您可以使用“递归”子模块更新检出代码并将“common”子目录添加到 PYTHONPATH。在生产中 - 即使您使用 git-sync，您也可以通过您的操作团队使用自定义映像（通过安装适当的、已发布的软件包版本）部署您的自定义运算符，其中您的 DAGS 将单独进行 git-sync，而无需子模块结帐。该子模块仅用于开发。
此外，在这种情况下，值得使用您推送到 DAG 存储库的 Dag 运行 CI/CD，以查看它们是否继续使用“稳定”分支中的“已发布”自定义代码，同时运行相同CI/CD 与公共代码通过“开发”分支中的子模块同步（这样您可以使用链接的公共代码查看最新的开发 DAG 代码）。
这就是我要做的。它将允许在开发时进行快速迭代，同时还将通用代码转换为“可冻结”的工件，可以在生产中提供稳定的环境，同时仍然允许您的 DAG 快速开发和发展，同时 CI/CD 可以帮助保持“稳定”的东西真的很稳定。
【讨论】：