问题标签 [continuous-delivery]

全部-

我已经使用 Jenkins 大约一年了，现在我正在尝试为我的团队设置一个持续交付管道并且有一个问题。

问题

是否可以让 Jenkins 从一个 SVN 分支签出/编译/测试代码，然后，如果一切通过，将该代码推送到另一个 SVN 分支？

对于我的团队，我正在设想以下分支::

每个单独的问题分支都将是稳定分支的副本

但

单个问题分支的提交将转到集成分支。

我希望詹金斯::

1. 在 SVN 中侦听针对集成分支的提交
2. 从 SVN 下载集成分支
3. 编译集成分支代码
4. 运行任何单元测试
5. 如果一切顺利，将新代码提交到稳定分支

那么，Jenkins 是否可以从一个 SVN 分支签出/编译/测试代码并在成功后将该代码提交到另一个 SVN 分支？

感谢您的时间，

杰夫

我最近遇到了这篇 Netflix 博客文章http://techblog.netflix.com/2013/08/deploying-netflix-api.html

他们谈论的是红/黑部署，他们并排运行旧代码和新代码，并将生产流量引导到它们两者。如果出现问题，他们会回滚。

交通指挥如何运作？是否可以使用例如两个 Docker 容器来调整这种策略？

我们有以下蓝=绿部署设计。想法是为了我们

• 将最新代码部署到非活动集群中
• 冒烟测试
• 切换 VIP 使当前的 VIP 处于非活动状态

我们在 go.cd 中相应地创建了管道。但是，我们遇到的问题是，我们希望将最新代码部署到新转换为非活动状态的集群。我们如何确保这个不会再次变得活跃？或者其他人如何进行蓝绿部署？谷歌搜索结果是针对 AWS 的解决方案。我们不使用 AWS 或公共云。

编辑 1

基础设施限制：我们只有两个集群可用的硬件

是什么阻止您在实时集群中运行批处理作业？: 实时集群服务于生产查询，批量加载会占用机器资源，可能会导致在线系统无响应

我正在构建一个具有 2 周冲刺周期的应用程序。我们目前会一次性测试所有功能推出，然后在出现问题时进行热补丁。我们的堆栈是带有 angular 和 mongo 的节点。

是否有人使用任何 SAAS 解决方案进行功能标记或其他任何有助于持续交付的方法？

编辑：试用LaunchDarkly - 将发布更新

Edit2：从试用版更新 - 好的，它在我的堆栈中似乎运行顺利 - 仍需要再测试几周。Launchdarkly 功能标志设置非常简单，因此我将在此处对其进行概述。

安装 SDK

传递自定义参数

将用户属性作为 JSON 对象传递

所有非常简单的文档。

Edit3：现在已经使用了 3 周，并且有一些初步的想法。功能标记驱动开发一直很有用，尽管很难追溯集成我们的一些更强大的功能。能够使用我们的优化目标将 launchdarkly api 用于 A/B 测试指标。

在集成总结中，我看到了指向 ipa 文件的链接

环境：xcode7，mac os server 5.0.4

在集成后脚本中成功集成后，我找不到 ipa 文件。从构建后脚本记录：

我尝试使用环境变量，例如 -ipaPath "${XCS_OUTPUT_DIR}/${XCS_PRODUCT}" 并得到下一个错误

我有一个 chrome 应用程序，我想将它自动部署到 Chrome 应用程序商店，作为我持续交付管道的一部分......

有没有办法用 Travis CI 做到这一点？

Travis 是否提供了一种将压缩的工件上传到 chrome 商店的方法？

是否可以使用 chrome 商店的 cli 构建这样的功能？

我正在 TC 中构建一个持续交付管道，作为第 0 个构建步骤，我希望能够提取我提供给我的提交的唯一版本号。

它看起来像这样：release_4.46。

我想使用“4.46”部分附加到管道的不同步骤，作为最后一步，将我的工件命名为 app_4.46.war。

我已经设法组装了大部分管道（单元测试、jsHint、Maven 构建）并且它已启动并运行，但我无法完成此功能。

任何帮助或指针表示赞赏。谢谢

我正在为一个新项目创建 CI & CD 管道。由于我们使用的是 Docker，所以我的问题是：在 Docker 容器中构建和测试是否更好，所以步骤是：

1. 构建 Docker 镜像
2. 在其中运行应用程序构建
3. 在其中运行应用程序测试
4. 推送 Docker 镜像

或者在 Docker 容器之外，在 CI 通过后，构建镜像：

1. 直接在 CI 服务器上构建项目（容器外）
2. 直接在 CI 服务器上测试（容器外）
3. 构建 Docker 镜像并推送

Sonar 支持单独报告单元测试与集成测试的能力，这很棒： http: //www.sonarqube.org/measure-coverage-by-integration-tests-with-sonar-updated/

也就是说，我们实际上希望从多个不同的角度来看待覆盖范围，以便做出各种投资决策。

例如，我们目前拥有许多测试技术，其中许多已被视为“遗留”。能够查看我的产品的树状图（可能根据复杂性或“代码流失率”来衡量）并查看覆盖哪些测试技术的覆盖区域将会很棒：

• 硒
• 泰勒里克
• RSPEC
• 茄子
• ETC

我们还在构建具有多层测试的分阶段持续交付管道。例如：

• 提交后（确保您的提交不会炸毁开发团队的其他成员，非常快）
• 信心（一组更深入的测试，涵盖所有主要测试用例，比 Post-Commit 稍慢，但仍然相当快）
• 完全回归（我们武器库中的所有测试 - 非常缓慢，但很深）

与测试技术的情况类似，能够将这些层叠加到树形图上以显示每个阶段如何覆盖产品以做出权衡决策，这将是非常棒的。

有没有人能够使用现有的 SonarQube 插件和技术来做到这一点，或者这超出了 Sonarqube 支持的范围？

谢谢！

我有一些关于持续交付版本控制的具体问题。我想我了解全球工作流程或多或少是这样的：

版本控制呢？如何管理构建版本？

假设我们正在开发一个基于 Maven 且带有语义版本控制的项目：major.minor.build.

当开发人员向 VCS 提交更改并且 CI 服务器执行构建时，CI 服务器是否应该增加构建版本并在 VCS 中创建标签？

源代码中是否存在此构建版本？如果是这样，在每次推送到 VCS 之后，开发人员应该更新项目，因为 CI 服务器提交了项目上的更改（版本增量）。

我有点困惑，我想以实际的方式了解 CD 工作流程。