我正在使用umbraco 7.4.x。我一直在尝试找出进行双向部署的最佳方法。
如所示，我们在本地有多个开发人员，并且我们有一台开发服务器和一个实时服务器。我们有从本地部署到DEV的单击部署，但这只是代码。我们正在将数据库复制到DEV，但是现在我们也有需要在DEV上输入内容的人。这也导致我们也对DEV数据库进行更改，并将数据库复制。当然，我们可以通过版本控制来完成所有这些，但这仍然是非常不便的。
我是否缺少更好的方法？几个月前，我尝试使用USYNC，但我们经常遇到崩溃。
我听说过快递，似乎这对于从开发/舞台到生产部署而言是有益的，但是这也可以将内容/DOC类型更改推向我们本地机器吗？我不确定，因为它们不是Internet上的Web服务器，而只是通过Visual Studios运行的本地IIS Express
预先感谢！
我们使用 usync （usync usync.contentedition -https：//er.umbraco.org.org/projects/projects/developer-teveloper-tooveler-tools/usync/）在实例之间。从过去探索它的位置发生了变化，因为它已经改变了。值得一提的是，它需要在不同的环境上进行良好的配置，以避免冲突等。
您也可以使用 courier ，它的最新版本由 umbraco cloud （http://umbraco.io/）使用，这也可能会让您感兴趣，因为它会给您带来完全控制多个Umbraco实例之间的部署过程。
一个选项是让所有开发人员设置以从同一开发数据库中工作。有时，您的开发人员可能必须"重新发布整个站点"或重新指示检查索引，以确保其所有缓存和临时文件都是最新的。否则，这对我们来说效果很好已有很多年了。令人沮丧的部分是，Dev A上传的媒体文件不会立即在Dev B的文件系统上。您应该能够将媒体移至Azure Blob存储以解决此问题。有一个软件包应该有助于在此处设置。
我不推荐usync.contentedition。我没有亲自尝试过，但是我还没有听到有关它的好报告。另一方面，usync对我们来说是一种挽救生命，即使它不是完美的。在这一点上，即使我们从未将其配置为更改，我们也会在每个站点上安装USYNC。我们喜欢的是，我们可以在源控制中记录对文档类型和数据类型的更改。使用共享数据库设置意味着我们不需要USYNC在开发和本地环境上阅读。但是，您将需要确保您的开发人员都了解USYNC。如果DEV A添加了DOC类型，则该DOC类型的USYNC .DEF文件可能会显示在Dev B. Dev B. Dev B. Dev B中不应在这种情况下提交USYNC文件。
Courier最近工作得更好。除非您正在运行Umbraco 7，否则我不会推荐它，并且可以获得最新版本的Courier。快递非常有用，但是在将其交给客户之前，您应该对其进行大量测试，因为Courier可以使您能够以大量的方式射击自己。它肯定有所改善。在《 Umbraco 6的快递》中，我曾经不得不在不打破网站的情况下努力部署。现在，在umbraco7的快递中，我必须非常努力地打破它。现在，这是将内容更改用于生产的可行选择。只需确保在生产环境中使用之前对其进行大量测试。