Fabric 已成为我选择的部署工具，用于部署 Django 项目以及用于初始配置 Ubuntu slices。但是，我当前使用 Fabric 的工作流程不太干，我发现自己：
- 从一个 fabfile.py ="noreferrer">Django 项目到另一个项目，并
- 根据每个项目的需要修改
fabfile.py （例如，将 webserver_restart 任务从 Apache 更改为 Nginx，配置主机和SSH端口等）。
此工作流程的优点之一是 fabfile.py 成为我的 Git 存储库的一部分，因此在 fabfile.py 和 pip requirements.txt< /code>，我有一个可重新创建的 virtualenv 和部署过程。我想保持这一优势，同时变得更加DRY。看来我可以通过以下方式改进我的工作流程：
- 能够
pip install在fabfile.py中定义的常见任务并
- 拥有
fab_config文件包含每个项目的主机配置信息并根据需要覆盖任何任务
有关如何增加DRY我的 Fabric 工作流程的性质如何？
Fabric has become my deployment tool of choice both for deploying Django projects and for initially configuring Ubuntu slices. However, my current workflow with Fabric isn't very DRY, as I find myself:
- copying the
fabfile.py from one Django project to another and
- modifying the
fabfile.py as needed for each project (e.g., changing the webserver_restart task from Apache to Nginx, configuring the host and SSH port, etc.).
One advantage of this workflow is that the fabfile.py becomes part of my Git repository, so between the fabfile.py and the pip requirements.txt, I have a recreateable virtualenv and deployment process. I want to keep this advantage, while becoming more DRY. It seems that I could improve my workflow by:
- being able to
pip install the common tasks defined in the fabfile.py and
- having a
fab_config file containing the host configuration information for each project and overriding any tasks as needed
Any recommendations on how to increase the DRYness of my Fabric workflow?
发布评论
评论（1）
我已经在这个方向上使用基于类的“服务器定义”做了一些工作，其中包括连接信息，并且可以重写方法以以不同的方式执行特定任务。然后我的库存 fabfile.py （永远不会改变）只是在服务器定义对象上调用正确的方法。
I've done some work in this direction with class-based "server definitions" that include connection info and can override methods to do specific tasks in a different way. Then my stock fabfile.py (which never changes) just calls the right method on the server definition object.