问题标签 [continuous-delivery]

我知道这是一个模糊的问题，但我正在寻找有关团队如何将安全性与持续交付/部署集成的博客或信息。我们每天多次部署到 AWS，我正在寻找团队为流程增加安全性的一些方法。

我看过一个演示文稿，其中一个团队使用 cucumber 进行了一些 nmap 测试，这并不是我想要的，但可能是在应用程序节点部署后，在它们进入负载均衡器接受流量之前对它们进行一些自动化测试。

在最近的一次采访中，我被问及我们公司的持续集成水平。当我开始描述我们所做的事情时，面试官插话并问我等级编号——对我来说听起来像是 CMM 等级。当我告诉他我不知道我现在的公司有什么级别时，他似乎对我的回答很不高兴。

我无法在网上找到任何此类信息。

有人可以请一些光吗？

我需要创建一个构建管道，其中包含多个相互依赖的项目。这是一个简化的插图：

管道应该工作，以便当更改提交到任何项目的 SVN 存储库时，该项目会自动构建。此外，在构建 A 或 B 之后，它会触发 C 的构建。

每个构建都会生成具有唯一版本号（“XYBuildNumber”）的二进制文件，并且 C 必须获取 A 和 B 的版本号作为参数，以便可以使用这些版本构建 C。C 应该默认使用 A 和 B 的最新成功构建，但也应该可以使用旧版本的 A 或 B 手动触发 C（例如，如果我们想要部署其中一个项目的旧版本）。

创建这样的管道可以在Go上开箱即用，但我的公司认为它太昂贵了。（2014-02-27 更新：Go 不是开源和免费的！）所以现在我试图找出如何使用 Jenkins 来实现同样的事情，但还没有找到方法。我只找到了在 Jenkins 中创建简单的线性和菱形管道的说明，但没有找到具有多个独立上游项目的管道。

在我的 Android 应用程序中，将有一项服务会生成一些数据（统计信息），例如（int、time、long、boolean）。

所以我的问题是：保存这些数据的最佳方式是什么？（例如在数据库或文件中等）

注意：我的应用程序无法将数据发送到任何服务器，该数据将来会被应用程序用于某些用例。

我的公司正在使用 Jenkins 进行持续集成，我正在尝试转向 CD。我正在使用 git hub 作为代码存储库。现在我们正在将特性分支合并到一个 uat 环境中，当一个特定的特性被接受时，特性分支将被合并到我们的生产分支中。这显然很危险，因为可以同时测试两个更改并分别部署。理想情况下，我们会在不重建的情况下测试和部署一个包，但我很难看到这是怎么可能的。如果两个人在两个不同的功能上工作，第一个完成，打包并进入测试，第二个完成并打包没有第一个？但是，我怎样才能在不使其他功能的测试失效的情况下部署包呢？我'

任何帮助将不胜感激。

此外，如果您查看http://ptgmedia.pearsoncmg.com/images/chap5_9780321601919/elementLinks/fig5_6.jpg 我担心的是签入 1 在通过验收测试时可以部署并且该包将被部署，但是什么如果验收测试失败？签入 5 包含与签入 1 相同的问题，因此在签入 1 修复或删除之前无法部署到生产环境。删除更改会很烦人，因为可能需要删除多个提交，并且修复 + 测试可能需要很长时间。

采用这个基本的构建管道（带有 gradle 任务）：

1. 编译/运行单元测试（gradle clean build）
2. 集成测试（gradle integrationTest）
3. 验收测试（gradle acceptTest）
4. 部署（gradle myCustomDeployTask）

根据 Jez Humble 的“持续交付”一书，您应该只构建一次二进制文件。因此，在上述理论管道中，在第 1 步中，我们清理、编译和构建 WAR，在第 2 步中，我们运行集成测试（使用第 1 步中的编译代码），在第 3 步中，我们运行验收测试（使用已编译的步骤 1 中的代码），并在步骤 4 中部署 WAR（在步骤 1 中构建）。到目前为止，一切都很好。

我正在尝试在 Jenkins 中实现这个管道。因为每个作业都有自己的工作区，所以步骤 2、3 和 4 最终会重新编译代码并构建 WAR，这违反了只构建二进制文件一次的“持续交付”口头禅。

为了解决这个问题，我使用了“ Clone Workspace SCM ”Jenkins 插件，它将从第一个构建压缩工作区，并成为构建 2、3 和 4 的工作区的源。但是，gradle 仍然重新编译每个构建中的代码步骤，因为它显然使用文件的绝对路径来确定是否需要执行任务。由于插件将文件移动到了新的工作区，因此绝对路径发生了变化，这使得 gradle 认为它需要从头开始，而不是执行增量构建。

现在我们可以在 Jenkins 中共享工作空间，但这也令人不悦，因为可能会针对共享工作空间运行两个作业。

那么如何在坚持持续交付、Jenkins 和 Gradle 的最佳实践的同时使用 Jenkins 和 Gradle 实现上述管道呢？

背景：

我的团队一直在使用 Jenkins 为我们的 Grails 应用程序运行持续集成 (CI)。我们正在尝试通过设置部署管道并将按钮部署到多个环境（Dev、Itg、Prod）来更接近持续交付。我们曾尝试使用 Jenkins Tomcat 插件来部署我们的代码，但在 Tomcat 上偶尔会遇到 PermGen 问题，并且必须在部署后手动重新启动它。

问题：

1. Jenkins 是用于 Grails 自动部署的正确工具吗？
2. 我们如何才能自动部署到 Tomcat 而无需事后手动重新启动它？

我有一个 Web 应用程序，只要一个功能准备就绪，我们就会部署到生产环境中，有时可能是一天几次，有时可能是发布之间的几周。

目前，我们不会为我们的项目增加版本号，并且所有内容都已在版本0.0.1-SNAPSHOT中放置了一年多。我想知道为 Web 应用程序进行持续交付的 Maven 方式是什么。在每次提交时提高版本号似乎有点矫枉过正，而且永远不会像我们现在所做的那样提高版本号，这似乎也是错误的。

对于这种类型的 Maven 使用，推荐的最佳实践是什么？

这个问题实际上是两个方面的：

• 在单个文件中推进项目版本号pom.xml（可能有很多）。
• 更新所有依赖组件中的版本号以使用彼此的最新版本。

目前我们正在运行一个 C#（基于 Sharepoint 构建）项目，并且已经实现了一系列自动化流程来帮助交付，这里是详细信息。

1. 持续集成。DEV环境下频繁编译部署的典型CI系统。
2. 部分包装。每周，都会确定伴随修复的缺陷列表，并从完整包中获取相应的程序集以形成部分包。部分包在后续环境中进行部署和测试。

在这个管道中，有两个包正在验证中。额外的努力用于为部分包建立一个新系统（网站、脚本、流程等）。然而，一些因素阻碍了它的改进。

1. 构建和部署时间太长。在开发人员的机器上，对程序集的每一次修改都会在 IIS 中触发大约 5 到 10 分钟的重新部署。此外，重建整个解决方案需要 15 分钟（甚至更长时间）。（这个项目最痛苦的部分）
2. 地域差异。每一个最终的包裹都被送到另一个办公室，因此手动操作是不可避免的，并且包裹尺寸最好小。

我将非常感谢您提出意见以推动持续交付实践。谢谢！

我目前正在阅读“持续交付：通过构建、测试和部署自动化实现可靠的软件发布”，引起我注意的部分是管理应用程序的配置设置。

书中提出的是，所有配置设置都被外部化并集中在某种存储库中，无论是 LDAP 目录、ESCAPE 服务器还是其他类似的存储库，然后从那里检索。

这听起来对我来说真的很有吸引力，因为这种方法可以提供许多切实的好处，但是在谷歌搜索了一下之后，在我看来这并不是一种广泛使用的方法。

我知道有一篇关于这个主题的十二因素应用程序文章，但它建议使用环境变量而不是集中存储库。这种方法似乎是最常用的一种，但与基于存储库的解决方案相比，它感觉像是一种肮脏的方法。

那么，中央配置存储库方法是否在现实世界中以任何重要的方式使用，如果没有 - 原因是什么？