问题标签 [continuous-delivery]

由于我无法控制的原因，我们必须使用 maven 项目设置，其中最顶层的 pom.xml 实际上不是父 pom。现在我们想创建一个 jenkins 部署管道，它当然会将整个反应器的唯一版本部署到我们的 nexus 存储库。

我们的设置是这样的：

现在我们必须：

• 将 root、parent、module1 和 module2 的版本设置为我们唯一的构建版本
• 将 module1 和 module2 的父版本设置为相同的构建版本
• 保持外部父 pom 的版本不变

我在 mojo 中没有看到执行versions:set此操作的参数。调用mvn versions:set -DnewVersion=1.2.3仅设置根 pom 的版本。完全相同的调用在传统的父/子反应器构建中完美运行。

有没有可能的解决方案？

注意： versions:update-child-modules不是一个选项，因为我们无法定义特定的目标版本

我使用 naught ( https://github.com/andrewrk/naught ) 在多个内核上运行我的 node.js 应用程序，并且也没有给我零停机时间部署只用一台机器。

我想使用 supertest ( https://github.com/visionmedia/supertest ) 在每个单独的节点启动之前对其进行测试 - 对于一些基本的集成测试，这将为该节点提供进入池的“OK”(在此之前节点可以处理.send('online'))。

如果超测测试是单个节点的一部分 - 它会自行关闭请求-响应周期（好）还是只是向整个池发送 http 请求（坏）？

如果没有 - 还有其他方法吗？

谢谢 ！！！

我们正在使用构建管道插件在 Jenkins 中设置持续交付管道。

我们的部署步骤使用专有的部署工具（由来自 jenkins 的 HTTP 请求触发），但我们需要额外的 Jenkins 步骤来对随后部署的项目进行验收测试。所以我们的部署工具需要触发最后一个管道步骤。

詹金斯的设置很明显：

对于手动触发的下游构建步骤：添加将等待手动触发的构建步骤：

• 选择 Build Pipeline Plugin，Manually Execute Downstream Project 复选框
• 在下游项目名称字段中输入下游项目的名称。（nb 可以使用逗号指定多个项目，例如“abc, def”。）

来源：构建管道插件

问题是：我似乎找不到通过 URL 触发此下游构建的方法。

事实上，我需要部署作业中的 URL，所以我可以将它作为回调 URL 发送到部署工具。有人可以帮忙吗？

我想为我的开源应用程序设置一个持续交付周期。它基于 Linux 的用户空间文件系统 (FUSE)。我尝试在CloudBees 的 Jenkins上设置它，它提供了不错的免费帐户，但我没有 root 访问权限，这是有问题的，因为我的项目有很多依赖项。我继续使用Travis CI，它非常适合测试内部 API，因为我拥有安装依赖项的 root 访问权限。但它不支持 FUSE，所以我不能直接在文件系统上运行测试。根据我对 Travis CI 的经验，持续交付方法可能会阻止许多错误的发布，并有助于更快地发现问题。

有没有类似 Travis CI 的服务，集成 Github，允许 root 访问，支持 FUSE？

[编辑]
六。建议在 Travis-ci 机器上运行用户模式 ​​Linux，以模拟 FUSE。总结在 Vi.s 帮助下取得的进展：

1. 要使用更多内存、网络访问和对文件系统的访问来设置 UML，请执行：

   /li>

在用户脚本中，调用：

2. 如果您使用 gcc，请设置 PATH 变量：

   /li>

3. 如果您需要 procfs，请在 UML 中执行：

   /li>

4. 对于 Python，您应该在 UML 中激活虚拟环境：

   /li>

activate在启动 UML 之前，可以通过发出以下命令找到路径：

我仍然无法运行 FUSE：

简而言之：

观察 CI 对独立开发人员的优势持续集成对独立开发人员是否重要？

有没有适合独立开发者的 CI 服务器？

它们通常会消耗大量 RAM，并且是基于服务器代理的。

在我看来，它们需要：-轻量级（RAM）-简单-与 GitHub 兼容

你能引用我吗？

许多软件公司吹嘘他们已经将新功能快速增量发布到生产环境中。在我在大型 X 公司的后端项目中，我们有大版本（每季度发布 1 个）。我们使用 Scrum 进行为期 2 周的冲刺和系统集成测试，这是在发布到生产之前在相邻团队和客户之间完成的最后阶段（他们有自己的测试包）。我们的团队仅对我们的后端服务（分别为我们的测试包）使用与夜间回归测试的持续集成。我们还使用 Jira、git、nexus、stash 等现代敏捷工具进行代码审查、spock、junit 和 teamcity。

由于这些团队很忙，我们无法承受团队之间频繁的集成测试。我们由 QA 开发人员编写的回归测试最多需要约 10 小时（针对具有 terabutes 数据的数据库检查了许多功能）。对于拥有数百名消费者和 24/6 全天候工作的业务而言，我们所有的后端服务都至关重要。为了投入生产，我们所有的消费者也必须运行他们的集成测试。这需要大量的协调和时间。我们总是在周末的非工作时间发布。

因此，快速发布非常冒险且耗时。我想听听成功案例以及如何实现快速发布？这真的可行吗？

在我们的项目中，我们有多个组件由具有单独 git 存储库的不同团队开发。所有组件都有提交作业和打包作业，并将工件发布到工件。

当我们想要将所有组件部署为一个系统时，问题就来了。

由于所有这些组件都部署到单独的服务器上，然后彼此交互以发挥作用。由于将某些较新版本的组件部署到其中一台服务器上，因此会出现很多时间不一致。

例如。我有组件 A、B、C 并希望在部署和测试管道中移动以下版本 A1、B1、C1。我如何确保没有更新版本的组件部署到 QA 环境（服务器）。我使用 Jenkins 作为我的 CI/CD 工具。看来我需要一些集成或轻量级配置管理工具来管理我的系统的版本控制作为一个整体，包括我可以在部署管道中推广的所有组件。

我希望我能描述我的问题。解决这种情况的建议将非常有帮助。

谢谢，

我在 Visual Studio Team Services 中有一个解决方案，它有 2 个 Web 应用程序（特别是一个用于 WebAPI 服务的项目，另一个用于使用 MVC 的实际站点）。

我正在尝试设置对 Azure 的持续交付，但我能找到的所有信息似乎都假设您的解决方案中只有一个 Web 应用程序（这对于除了最简单的项目之外的所有项目来说似乎有点不切实际！）。

开箱即用的持续交付过程似乎只是挑选并部署它找到的第一个 Web 应用程序（不一定每次都是同一个项目！）

我尝试指定部署设置文件，但这似乎会影响目标而不是正在部署的项目，因为它似乎只是“选择”一个要部署的项目，并且每次部署每个已编译的程序集以及所有依赖项时而不仅仅是实际部署的项目的二进制文件和依赖项，这可能会导致 MVC 为给定名称查找重复的控制器匹配项的问题（这当然可以通过在路由配置中指定控制器的命名空间来解决，但这似乎不太理想，仍然不能解决整个问题）。

理想情况下，我想找到一种使用单个构建部署两个项目的方法，但作为一个临时解决方案，我对两个由单个解决方案的签入触发的构建感到满意，每个构建都可靠地部署 1 2 个 Web 应用程序中的一个。

有谁知道这是否可能？我想我可以编写自己的自定义构建模板，但我希望有一个更简单的答案（尤其是因为我无法想象这不是其他人面临的问题！）

我确实发现了这个问题TFSPreview.com and Azure Continuous deployment for multiple solutions in TFS但由于这已经很老了，而且专门讨论的是 AzureWebRoleProjects 而不是 Web 应用程序被部署到较新的 Azure 网站功能，我希望有更多正面回答？

我创建了一个网站（一个 Ruby on Rails 应用程序），我想将其开源，以便社区可以做出改进。源代码已经在 GitHub 上公开可用。但是，我想设置我的服务器，以便当我接受拉取请求时，代码会自动部署到生产中。

我怀疑我是第一个想到这种事情的人，所以也许已经有一个工具可以处理这个问题。目前我使用 Capistrano 来部署我的应用程序。也许有一个插件可以添加这种行为。我还想避免公开目前仅存在于服务器上的生产 API 密钥。

如果工具/插件尚不存在，我需要做什么才能实现此类行为。

I have coded two different modules for Puppet one which ensures Tomcat7 is installed and running and another one which deploys a web application into Tomcat webapps folder.

However, if I run puppet as a daemon with these two modules, the application is deployed every time pupped sync with puppetmaster, so I guess I should do the following:

1. Add tomcat module to the list of manifests to be execute by such node. In this way I will be sure that Tomcat is up and running every 30 minutes.

And then:

A. Invoke a no-daemonize one-time task on puppet agent through the command below using tags to specify I want to run only the deploy application module.

puppet agent --server MYSERVER --no-daemonize --onetime --tags deploy_app

B. Modify my deploy application module somehow, maybe specifying the version of the application in the artifact , to deploy automatically from puppetmaster instead of calling puppet agent.

What is the right approach? What are companies usually doing to run this kind of tasks with Puppet?

I guess that if you deploy from puppetmaster it is difficult to know when was exactly deployed your application, so you are losing control in the deployment process, what I guess is not good.