问题标签 [continuous-delivery]

我想通过 WSUS 发布构建的结果。我的构建创建了一个 InnoSetup。我已经成功测试了使用WSUS Package Publisher 发布设置 但我想自动化这最后一步。我无法自动化 Package Publisher 或Local Update Publisher，也找不到可以自动化的工具。我错过了什么？

例如：我需要一个可以通过命令行启动的工具，它接受参数或配置文件并创建和发布 setuppackage。

我必须手动打包每个新版本吗？

谢谢迈克尔·格伦瓦尔特

作为持续交付管道的一部分，我们正在将 sidekiq 工作器版本部署到 Cloud Foundry。如果他们不再是最新版本，我们需要停止工人处理新工作。所以：

1. Worker v1 正在运行并执行 30 分钟的作业。
2. 我们部署了工作代码的 v2。
3. v1 应继续当前作业，但不启动任何新作业。

CloudFoundry 不允许我们发送USR1，因此我们需要一个解决方案，允许工作人员在每个工作开始之前确定他们是否是最新版本。

我们希望阻止 Sidetiq 根据某些条件安排新作业。在我们的用例中，没有更新版本的代码在另一个部署/容器中运行）

我们如何在 Sidetiq 调度作业时添加逻辑并阻止它这样做？

我们在 .NET 项目上工作，使用 TFS 进行：

• 源头控制
• 构建：生成 MSI 文件的门控签入
• 部署到实验室

我们想要创建一个适当的持续交付管道，即一个仪表板，其中包含用于每个签到红绿灯的管道。管道应显示所有阶段，例如 TFS 构建 > 部署到实验室 > 冒烟测试 > 集成测试 > 验收测试 > 部署到 PreProd > ...

所以它必须与 TFS 紧密集成。

我们正在评估 2 个选项：

1. 如果有任何可以显示管道的工具，请使用基于 TFS 的工具\插件\仪表板？
2. 使用 CI 工具，例如 Jenkins、TeamCity、Bamboo 来构建这个管道 - 理想情况下支持从 TFS 放置文件夹中获取构建的代码，而不仅仅是源代码

你会推荐什么？

我的团队正在开发用于客户端-服务器设置的桌面应用程序（混合 C++/Tcl）。目前它仅适用于 Windows，但很快我们需要将其移植到 Linux。CruiseControl.NET 每晚都会从 SVN 中的源代码构建它，并将其打包到 NSIS 安装程序中，但我们没有要运行的自动化测试。
添加任何单元测试几乎是不可能的，但应用程序的集成测试很容易，因为它已经大量基于脚本。
主要任务是将应用程序安装到 3 台 PC 上，配置它（包括复制一些文件），运行它，监控可能的崩溃，等待集成测试完成，收集摘要，发送电子邮件。可以使用一堆自定义 PowerShell 脚本来完成，但是

• 将来我们会想要添加更多的功能和更多的测试，而过去的简单脚本很快就会崩溃（像往常一样），所以我想尽量减少自定义脚本，如果我需要编写脚本，我更喜欢 bash/cygwin （我不熟悉 Python 或 Ruby）。
• 我想要一个可以报告当前进度的 Web 仪表板，如果出现故障 - 显示日志
• 我需要一些主管来监控被测应用程序并报告它是否挂起或崩溃
• 我们还需要在 Linux 上对其进行测试
• 理想情况下，我想在 PC 之间编排一些测试步骤（例如，在 PC1 上并行运行测试 X，在 PC2 上并行测试 Y，等到它们都完成，然后在 PC1 上运行测试 Z，同时监控 PC2 上没有崩溃等）

因此，我正在寻找一种 COTS 工具/工具集来帮助我做到这一点并且没有陡峭的学习曲线。理想情况下，免费，但如果它真的很好并且价格合理，我的公司可能会购买许可证。
当 NSIS 安装程序准备好时，应该从 CruiseControl.NET 触发该过程，然后执行上述所有操作。基本上，它至少应该允许远程安装软件、运行自定义脚本并拥有一个 Web 仪表板。
显然，可以使用像 Chef 这样的 SCCM 工具，但到目前为止，它们都不支持 Windows 服务器，只支持节点。我想避免为此设置 Linux VM，尽管我可以做到，如果我别无选择的话。此外，Chef 似乎有点矫枉过正 - 对 10k 机器有好处，但我只有 3 台……将来可能有 5 台。而且我对编排分布式测试的机会特别好奇。
StackOverflow 和互联网上的大多数类似问题都与 Web 应用程序、Java 容器、Maven 等有关，并且有很多工具和插件可供这些工具评估。
提前致谢。

这三个术语有什么区别？我的大学提供以下定义：

持续集成基本上只是意味着开发人员的工作副本每天与共享主线同步几次。

持续交付被描述为持续集成的逻辑演变：始终能够将产品投入生产！

持续部署被描述为持续交付之后合乎逻辑的下一步：只要产品通过 QA，就自动将产品部署到生产中！

它们还提供警告：如果您能够持续部署到测试系统，有时也会使用术语“持续部署”。

这一切让我感到困惑。任何更详细（或附带示例）的解释表示赞赏！

我正在使用 Git 将我的项目推送到 Visual Studio Online。我的项目链接到一个用于持续集成和交付的 azure 网站。

我对 Site.css 文件进行了更改，并将更改推送到 Visual Studio Online。自动构建将项目部署到我的 azure 网站。

但我对 Site.css 的更改未部署到网站。尽管我对视图和控制器的其他更改都可以。

我已查看并验证更新的 Site.css 已成功推送到 Visual Studio Online。但由于某种原因，它没有包含或应用在部署中。

当我将项目从本地 VS.2013 发布到 azure 网站时，它工作正常并且 css 已更新。

问题在于从 Visual Studio Online 到 Azure 网站的持续交付。

在持续交付中包含 Site.css 需要什么？

对于我们的一个应用程序，我们正在尝试自动化部署过程。我们为此应用程序实施了端到端的持续集成（构建/测试/打包/报告）。现在我们正在尝试实现自动化部署。这个应用需要部署在2000台服务器上，每台服务器下有50个客户端。一些组件将安装在服务器上，其中一些组件将安装在客户端上。
用于 CI 的工具：Jenkins、Github、msbuild、nunit、specflow、wix。

我已经阅读了持续交付和持续部署之间的区别，并理解持续交付意味着代码/更改被证明可以在任何时间点生效，持续部署意味着经过验证的代码/更改将自动部署到生产服务器。

网络上的大多数文章都解释了我们如何将持续交付/部署到其中一台服务器（DEV/Staging/Preproduction/production）的部署部分自动化。没有一篇文章谈到将应用程序部署到大量服务器和客户端。

现在我的问题是 1) 将应用程序部署到 2000 多个服务器和客户端是持续部署的一部分，还是应该在 CI/CD 之外处理？2）如果它可以在 CI/CD 中处理，那么我如何在 Jenkins 交付管道中对此进行建模并从 CI 工具触发所有服务器的部署？3) 是否有任何工具可以与 CI 工具集成以自动化部署？

谢谢

快速提问，如果我的想法总体上很愚蠢/是否有更好的方法，请告诉我：

为了创建持续交付管道，我想在 Composer 中使用“require-dev”声明各种类型的测试所需的一些包。但是，我想知道是否可以运行 install 命令以使用一个命令全局安装“require-dev”下列出的所有软件包？

这会很好，因为它可以让我轻松地保持测试环境最新，并允许对我需要的所有 PHP 测试解决方案进行全局访问。我知道这不是很多工作，如果我只是手动完成所有这些工作，我已经完成了，但我很想知道是否有一个很好的方法来做到这一点，因为我认为手动下载和一切，授予它执行权限，然后将其移动到 bin/ 目录以进行全局访问是一种乏味的解决方案。

我正在为我的工作场所开发 CI/CD 环境。我们正在努力解决的问题之一是我们当前使用的拉取请求工作流程，并且我们希望继续使用它。

当您提交功能分支并将其推送到 BitBucket 时，我们可以让 BitBucket 告诉 Bamboo 进行构建，但对于我来说，我无法在其中找到与实际拉取请求相关的任何内容。在我们的示例中，如果在 BitBucket 中生成功能分支的拉取请求时创建计划分支，那就太好了。随后的提交将触发 PR 计划分支上的其他构建。这在 Bamboo with BitBucket 上是否可行？