版本控制和部署依赖系统

Question

我需要一些开发团队的最佳实践或经验，他们必须处理与我目前所拥有的问题相同的问题。

我们公司多年来一直在开发客户端软件。唯一的依赖是有一个适当的数据库。对于每个版本(更新)，我们还在必要时更新(增量)数据库。版本化模式已经建立，并且与我们的意识形态相匹配。

现在，我们已经开始开发移动应用程序(充当外部客户端)。对我们的架构的一些初步评论：

移动客户端与数据库(与桌面客户端相同的数据库)之间的接口是一个RESTful for服务。两个客户端的版本控制都是独立的。一个应用程序由桌面开发团队维护，而移动部分由另一个团队维护。

但我不知道如何处理网络服务。它是否也应该是独立的(自己的版本控制)，尽管它使用了许多由桌面开发团队维护的共享库？

它的工作原理：

移动客户端将其参考数据与与数据库交互的webservice同步(只读访问数据库)。在移动应用程序上生成的用户数据也与webservice同步，但是它被写入一些持久的临时表中。并且将启动一个异步作业来尝试导入到数据库(在锁定问题、权限、.时可能会失败)。如果导入失败，也可以在桌面客户机上启动相同的导入过程(他们使用相同的库从临时表导入到特定的表)

一般来说，这三个部分中的每一个部分都可以更改(例如修补程序、特性、性能改进)，而不会影响其他两个部分。因此，我需要一个单独部署的策略。尽管如此，它很可能会影响到三个国家中的两个。

我应该在哪里/什么时候检查这三个系统是否兼容？我该怎么检查这个？在数据库中有一个包含每一个可能的版本组合的表，这些组合一起工作？

如果你不明白我的问题，因为它是完全含糊的，请告诉我。描述起来不那么容易

Answer 1

它是否也应该是独立的(自己的版本控制)，尽管它使用了许多由桌面开发团队维护的共享库？

IMHO有两种可能的模式：

1. Web服务被视为桌面应用程序的一部分，并获得相同的版本号。
2. Web服务被看作一个单独的应用程序，获取它自己的版本号(您必须跟踪哪个WS版本号与应用程序&数据库版本号相匹配)

当REST非常稳定且不经常更改时，模型1很好，并且您希望每次创建桌面应用程序的新版本&数据库时都提供一个新的WS版本。当您部署主应用程序的新版本时，这通常包括WS的新部署。这也可能意味着，每当您需要为WS提供for修复时，桌面应用程序就会有一个新的版本(和部署)。如果您使用像"major.minor.patchlevel“这样的版本控制方案，对于WS和桌面应用程序/数据库，只有"major.minor”是相等的，则可以避免使用后者，而只要桌面应用程序/数据库的任意修补程序级别和WS可以一起工作，则允许不同的补丁级别。这种版本控制方案是模型2的“轻型版本”。

如果WS有一个与您的应用程序和数据库完全不同的“发布周期”，那么模型2会更好。例如，当您比应用程序的其他部分更频繁地更改REST时(听起来不太可能)，或者当大多数应用程序和数据库的更改不影响WS服务时，您只是不需要提供(也不想部署)一个新的WS版本。这也取决于开发WS的人员:如果您在这方面有一个独立的团队，那么很可能他们需要有自己的发布周期才能完成任务(参见康威定律)。

当您的web服务与桌面应用程序共享大量库时，我想您更有可能希望在提供新桌面应用程序的版本(模型1)时提供一个新的WS版本，否则会在生产中得到一堆相同的库版本，这增加了维护的复杂性。

我应该在哪里/什么时候检查这三个系统是否兼容？

让WS检查当数据库连接到db时，数据库是否有兼容的版本号。在模型1中，这应该很简单，在模型2中，您需要一个他可以处理的数据库的版本号列表(这个列表必须是WS安装的组成部分，所以不会因为错误的部署而混乱)。

移动应用程序还应该检查REST是否提供了他们所期望的一切。它们可以包含显式版本检查(并且停止工作，或者在WS版本太旧或太新时要求更新)，或者单独检查不同的REST特性，在缺少某些功能时具有不同的行为。什么是最好的，在很大程度上取决于REST的外观、用户的期望、如何将新版本部署到移动设备上等等。

让REST的新版本向下与旧版本兼容可能是个好主意(如果可能的话)，并将WS用作移动应用程序的版本与其他系统部分的版本分离的一个点。