问题标签 [continuous-delivery]

我有一些部署到多个 VM 的 WCF 服务。VM 是内部唯一网络的一部分，未加入域。有时我需要将二进制文件更新到最新版本。为此，我有一个 .bat 脚本。现在，我在每个 VM 上手动触发更新，我想通过 TeamCity 的按钮单击来自动交付。

我尝试从 powershell（来自 TeamCity 的远程作业）运行脚本，但配置安全问题有点痛苦，所以我放弃了它并返回到手动更新。后来我想在基础合约中添加一个新方法，比如

WCF 服务将在单独的进程中调用该文件（例如通过 cmd.exe）并关闭其主机。bat 文件将执行更新并重新启动 WCF 主机。

这是一个好方法吗？WCF服务的持续交付有没有更好的解决方案？

VCS 中的并行开发/分支如何影响构建工件存储库设置和发布给 QA？

在我们公司，我们对 VCS 进行分支以进行并行开发工作，而且我们通常没有太多关于哪个分支将以哪个顺序发布的警告。

对于版本编号，我想放置一个分支标识符以向 QA 显示构建来自哪个分支。来自主干的任何构建都将具有“正常”版本号，其中没有分支标识符：

最初我认为每个分支有一个构建工件存储库，主干有一个主存储库。

但是如果我的版本号包括分支，那么产品的版本号将是错误的（如果我正在构建并从分支发布）。

解决这个问题的方法是只从后备箱释放吗？

另外，我应该在什么时候开始从主干而不是从分支构建 QA 团队？

我目前的想法是说服管理层将开发团队分配到发布订单（比如发布后一周）并将他们的分支合并到主干。然后 QA 开始获取主干构建而不是分支构建，并且分支已合并的开发团队直接在主干而不是分支中修复任何错误。

* 更新 *

更具体地说，我将 SVN 用于 VCS，并将 Artifactory 用于我的存储库。我正在使用 Ivy 进行依赖管理。

查看关于 Repository Layouts ( Repository Layouts ) 的 Artifactory 帮助：

这和 Maven 和 Ivy 的默认布局向我表明这是更常见的：

这是使用 Ivy 的典型回购布局吗？我假设这需要使用 Ivy 的分支功能在构建时将依赖关系解析为 repo 中正确的分支文件夹？

* 更新 2 *

这是我当前的 Artifactory 结构：

1. 如何在构建时将 Ivy 指向特定的仓库？对于发布，我只需要从发布存储库中提取二进制文件。对于快照构建，如果它们出现在快照存储库中，我可以提取二进制文件，如果它们丢失，我可以从发布存储库中提取它们。我了解如何链接存储库，只是不了解如何切换它们。

在我的 IvySettings.xml 文件中，我有：

..但我不想要默认值。当我调用 Ivy 解析命令时，我想指定要解析的解析器链。像这样的东西：

这是切换我需要解决的存储库的错误方法吗？

发布任务有一个“解析器”属性，它以类似的方式完美地为我工作。

此外，在我的特定示例中，我可能有多个 SVN 分支对应于多个 Artifactory 快照存储库。我可以参数化我解析到哪个 repos 的方式吗？还是将所有分支的快照放入一个存储库并使用常春藤分支功能的更正确方法？

如果您需要任何其他信息来提供帮助，请告诉我。

我正在查看不同的存储库布局，并且我看到了文件夹集成修订版和文件集成修订版之间的区别。

这些是相同的修订号（只是放在文件和/或文件夹上）还是不同的东西？

这是我看到两者都提到的链接：Repository Layouts

持续集成的概念刚刚融入我的团队。

假设我们有一个名为Dev的集成分支。

从中派生出 3 个分支，每个特定当前项目一个分支：

• 项目A
• 项目B
• 项目C

首先，Teamcity 配置在专用服务器上，其目标是：

从每个分支（包括 Dev）的版本化源中编译和启动单元和集成测试

然后，当然，每个项目分支（A、B 和 C）都必须在克隆的生产环境中进行测试，以便执行 UAT。

但我想知道我们应该部署在什么频率上？每次源代码更改？

我们应该在将每个项目合并到它之后（对应于下一个生产版本中的实际情况）只部署包含 3 个项目的混合的 Dev，还是独立部署 3 个项目？

如果部署了 Dev，则不得考虑 Dev 未来可能发生的变化。实际上，可能会有一个名为Project D的新项目开始，它不能成为下一个版本的一部分。所以采用 Dev for integration (UAT) 是有风险的，因为部署者可能会非自愿地集成 Project D 的内容，因此环境不会揭示下一个版本的现实。

其他解决方案：我们不是拿 Dev 而是独立的 3 个项目，所以必须有 3 个并行的克隆生产环境吗？

如果是，则 UAT 不可靠，因为集成环境的行为可能会经常变化......

UAT 持续部署的概念对我来说并不清楚......

我正在努力从 Jenkins 构建服务器自动部署到远程 JBoss AS 7.1.1 服务器，作为构建管道的一部分，并有一个我从 ant 调用的小 jar 文件（基于this）。

我的问题是如何确定应用程序是否已安装？如果应用程序已经部署，则执行部署计划将失败（我可以捕捉到抛出的异常，但这不是很好）。

我正在使用 jsf 中的应用程序并不断交付给 Heroku。我是 JSF 和 Heroku 的新手。我不知道这是否可能，但我希望能够对应用程序进行小的更新，部署到 Heroku 但仍然让会话在会话范围的管理 bean 中存活。我在 web.xml 中将状态保存设置为客户端，但是当我将应用程序部署到 Heroku 时，管理 bean 中的所有值都将重置为其初始值。有谁知道如何解决这一问题？谢谢

有哪些可与 UrbanCode uDeploy、Noliosoft ZeroTouch 和 XebiaLabs Deployit 相媲美的持续部署工具？我尝试将应用程序部署到的环境是多操作系统（Linux、Windows Server）、各种类型的中间件（Websphere、Weblogic、Jboss、Tomcat、Apache、IIS、BizTalk）、不同的数据库（Oracle、MySQL、MSSQL），并包括不同类型的应用程序打包（.war、.jar、.conf、.xml、.zip、.exe、.msi）。我也从文件系统而不是 Maven 存储库中提取（但将来需要与 Maven 集成）。我已经构建了一个 Maven-cargo 部署流程，但部署工程师想要一个基于 GUI 的工具，可以收集指标。我尝试了 Webistrano 部署，但无法让 .NET、IIS 和 .msi 部署正常工作（我知道 - 它不适用于这些平台）。我有 Red Hat JON，但它不允许部署到 Windows。SCCM？谷氨酸？八达通部署？夸提？

我看过很多关于“Git vs SVN”主题的引文，通常的答案是

1. 你可以在任何地方提交
2. 节省空间
3. 快速分支

...

但是在这里我想讨论一下是否有利于持续交付？在我看来，Git 鼓励我们经常分支，但这与持续交付的概念背道而驰，后者主张经常合并到主线，而不是在功能上发布时分支。

所以，当我想为我们的持续交付选择一个版本控制系统时，我有点困惑，Git 还是 SVN？

你怎么看？

在持续部署中，您有时会逐渐升级您的服务器，例如，20 人中有 2 人会使用新代码，直到我们确信一切正常。如果新代码需要数据库模式迁移会发生什么，例如字段 phone 现在是 table Phones。除非我升级所有 20 台服务器，否则某些东西会坏掉。

I have a system I'm working on that has almost all of its logic in SQL Server stored procedures. As part of improving the development practices we want to move to a continuous delivery model using feature flags (aka toggles) to enable functionality in production.

How can I write the stored procs so that they check the flags efficiently and don't add load to the database by hammering a config table every time the procs are called?