我们正在努力寻找解决该问题的最佳方法.
假设我在Python环境中工作,使用pip& setuptools的.
我在正常的git流程中工作,或者我希望如此.
所以：

>移动到某个应用程序中的功能分支,进行更改.
>转移到依赖库中的功能分支 – 开发事物.
>使用“-e git ssh”将应用程序指向依赖库的功能分支.
>创建一个拉取请求.

当这一切都完成后,我想把东西合并到主人,但我不能不做另外的最后一次更改来获得应用程序(上面的步骤3)requirements.txt现在指向该功能的主要分支.

我们缺少python中的“微服务”或多个依赖源代码是否有任何良好的工作流程？

解决方法:

从开发到部署的Python应用程序工作流程

看起来你正在寻找使用git开发Python应用程序.

以下描述适用于任何类型的基于Python的应用程序,
不仅仅是基于金字塔的网络.

要求

情况：

>使用Pyramid Web框架开发基于Python的解决方案
>有多个python包,参与最终解决方案,包可能是依赖的.
>一些包装来自公共pypi,其他包装可能是私人包装
> git控制的源代码

期望：

>拟议的工作方式应允许：

>拉请求
>应适用于包裹所依赖的情况

>确保部署是可重复的

提出的解决方案

概念：

>甚至金字塔应用程序作为版本化软件包发布
>对于私人pypi使用devpi-server incl. volatile和release索引.
>对于包创建,请使用pbr
>使用tox进行包单元测试
>测试,在发布新的软件包版本之前
>部署前测试
>将部署配置与应用程序包分开

金字塔网络应用程序作为一个包

Pyramid允许以Python包的形式创建应用程序.在
事实上,整个初始教程(包含21个阶段)正是使用这个
做法.

尽管如此,您可以在开发模式下运行应用程序,但您没有
在生产中这样做.从发布的包中运行很容易.

Pyramid使用漂亮的.ini配置文件.保持development.ini在
包存储库,因为它是开发的组成部分.

另一方面,请确保生产.ini文件不存在
不应该与应用程序混合,属于部署的东西.

为了使部署更容易,请在包中添加一个打印到的命令
stdout典型的部署配置.为脚本命名,例如myapp_gen_ini.

编写unittests并配置tox.ini来运行它们.

将部署内容与应用程序分开

将应用程序代码与部署配置混合将产生问题
那一刻,你将不得不安装到第二个实例(因为你很可能
更改配置的至少一行).

在部署存储库中：

>保留这里的requirements.txt,其中列出了应用程序包和其他
生产所需的包装.请务必指定确切的包版本
至少为您的应用程序包.
>保留这里的production.ini文件.如果您有更多部署,请为每个部署使用一个分支.
>把这里放到tox.ini

tox.ini应具有以下内容：

[tox]
envlist = py27
# use py34 or others, if your prefer

[testenv]
commands = 
deps =
    -rrequirements.txt

部署存储库的预期使用是：

>将其克隆到服务器
>运行tox,这将创建virtualenv .tox / py27
>通过$source .tox / py27 / bin / activate激活virtualenv
>如果repo中还不存在production.ini,请运行命令
$myapp_gen_ini> production.ini生成生产模板
组态
>根据需要编辑production.ini.
>测试,它的工作原理.
>将production.ini更改提交到存储库
>做部署应用程序所需的其他东西(配置Web服务器,监督等)

对于setup.py,请使用pbr包

使包创建更简单,并保持与git相关的包版本控制
存储库标签,使用pbr.最终你的setup.py只有3行
long和所有相关内容将以ini的形式在setup.cfg中指定
文件.

在第一次构建之前,你必须在git repository中有一些文件,
否则会抱怨.当你使用git时,这应该没问题.

要分配新的软件包版本,请设置$git tag -a 0.2.0并构建它.这将
创建版本为0.2.0的包.

作为奖励,它将根据您的提交创建AUTHORS和ChangeLog
消息.将这些文件保存在.gitignore中并使用它们来创建AUTHORS.rst
和ChangeLog.rst手动(基于自动生成的内容).

当你将提交推送到另一个git存储库时,不要忘记推送标签.

使用devpi-server作为私有pypi

devpi-server是一款出色的私人pypi,它将带给您以下优势：

>拥有私人pypi
>缓存的公共pypi包
>更快的虚拟环境构建(因为它将从缓存的软件包安装)
>即使没有互联网连接,也能够使用pip
>在各种类型的包索引之间推送：一个用于开发
(发布的版本可以在这里更改),一个用于部署(发布的版本不会在这里更改).
>对任何有权访问它的人进行简单的单元测试,甚至可以收集
结果并通过网页使其可见.

对于所描述的工作流程,它将作为可以部署的python包的存储库提供.

要使用的命令是：

> $devpi upload将上传开发的包上传到服务器
> $devpi test< package_name>下载,安装,运行单元测试,
将测试结果发布到devpi-server并清理临时安装.
> $devpi push …将已发布的软件包推送到devpi-server或甚至公共pypi上的正确索引.

注意,一直很容易将pip命令配置为使用
$pip install< package>的devpi服务器上选定索引的软件包.

devpi-server也可以用于持续集成测试.

git如何适应这个工作流程

所描述的工作流程不受使用git的特定样式的约束.

另一方面,git可以在以下情况中发挥作用：

> commit：commit消息将成为自动生成的ChangeLog的一部分
> tag：定义版本(由setup.py根据pbr识别).

随着git的发布,拥有多个存储库,分支等,
devpi-server允许类似的分发,因为每个用户都可以拥有它
工作索引发布到.无论如何,最后会有一个git存储库
与master分支使用.在devpi-server中也将达成一致
生产指数.

摘要

描述的过程并不简单,但复杂性与任务的复杂性相关.

它基于工具：

> tox
> devpi-server
> pbr(Python包)
> git

建议的解决方案允许：

>管理python包,包括.发布管理
>单元测试和持续集成测试
>任何使用git的风格
>部署和开发具有明确定义的范围和交互.

您的问题假设有多个存储库.建议的解决方案允许通过良好管理的软件包版本解耦多个存储库,并发布到devpi-server.