Questions tagged «continuous-integration»

在软件工程中，持续集成（CI）经常执行对完整软件产品的持续构建和自动化测试。每天至少一次，通常一天几次，有时甚至在每次签入版本控制系统后的次数一样多。

13
要分支还是不分支？
直到最近，我的开发工作流程如下： 从产品所有者那里获得功能 进行分支（如果功能超过1天） 在分支中实施 合并从主分支到我的分支的更改（以减少向后合并期间的冲突） 合并我的分支回到主分支 有时合并存在问题，但总的来说，我喜欢它。 但是最近，我看到越来越多的想法的追随者不要建立分支机构，因为这使得实践连续集成，连续交付等变得更加困难。对于具有分布式VCS背景的人们，他们在谈论如此大的合并实现时尤其有趣。 Git，Mercurial等 所以问题是我们现在应该使用分支吗？
7
有期限的待办事项？
背景 我正在一个团队中实施零停机时间部署。为了实现此目标，我们正计划使用蓝/绿部署策略。我在进行研究时意识到的一件事是进行数据库更改变得多么复杂。重命名列之类的简单操作可能需要3个完整的发布周期，直到完成！ 在我看来，全面实施变更需要多个发布周期，这会带来很多潜在的人为错误。在链接的文章中，它表明2个发行版需要更改代码，而3个发行版需要数据库迁移。 我在寻找什么 当前，如果我们想记住要做的事情，可以在我们的问题管理系统中创建票证，这会造成混乱，并且还可能被管理层转移到以后的冲刺或待办事项中；或者我们可以创建一个TODO注释，它可能会完全被遗忘。 我正在寻找的方式是TODO注释可以有一个截止日期，并且，如果该截止日期已过期，我们的持续集成系统（当前将使用的未定）将拒绝该构建。 例如，如果我们重命名列，则可以为其创建初始迁移，然后创建两个TODO注释以确保创建其余的两个迁移： // TODO by v55: Create migration to move constraints to new column, remove references to old column in app // TODO by v56: Create migration to drop old column 这似乎很容易实现，但是我想知道是否已经存在类似的东西，因为我不想重新发明轮子。 其他想法 考虑到滚动部署和蓝/绿部署被认为是最佳实践，我觉得自己可能在这里遇到了XY问题，但我找不到能够减轻数据库更新麻烦的解决方案，这似乎很奇怪。如果您认为我正在完全研究错误的内容，请在评论中告诉我！就是说，我给出的数据库示例只是一个示例，我认为带有到期日期的TODO注释在其他情况下也将很有用，因此即使我正在接近这种特定情况，我还是很想回答我的问题也是实际问题。谢谢！ 编辑：我只是想这可能会有所帮助的另一种情况。如果在准备就绪时使用Feature Toggles来打开应用程序的某些部分，则必须小心清理它们，否则最终可能会出现Toggle Debt。带有截止日期的评论可能是记住这一点的好方法。
9
如何为多个客户端维护同一软件的不同定制版本
我们有多个具有不同需求的客户。尽管我们的软件在某种程度上实现了模块化，但是几乎可以肯定，我们需要在这里和那里为每个客户调整一些模块的业务逻辑。所做的更改可能太微小了，不足以证明为每个客户端将模块拆分为一个单独的（物理）模块是合理的，我担心构建会出现问题，从而造成链接混乱。但是，这些更改太大且太多，无法通过某些配置文件中的开关进行配置，因为这会导致部署期间出现问题，并且可能会带来很多支持问题，尤其是对于修补程序类型的管理员而言。 我想让构建系统创建多个构建，每个客户端一个，其中更改包含在单个物理模块的专用版本中。所以我有一些问题： 您是否建议让构建系统创建多个构建？如何在源代码管理（尤其是svn）中存储不同的自定义项？
9
我们如何避免CI驱动的开发……？
我正在与其他许多常规贡献者一起进行一个由研究主导的大型开源项目。因为该项目现在很大，所以一个财团（由两名全职员工和几名成员组成）负责维护该项目，持续集成（CI）等。他们只是没有时间进行外部集成虽然贡献。 该项目由一个“核心”框架组成，该框架包含大约半百万行代码，由联盟维护的一堆“插件”，以及几个外部插件，而我们大多数都不是。甚至没有意识到。 目前，我们的CI正在构建核心和维护的插件。 我们面临的主要问题之一是，大多数贡献者（尤其是偶尔的贡献者）并未构建90％的可维护插件，因此，当他们提议对核心进行重构更改时（这些日子经常发生），他们在GitHub上发出拉取请求之前检查了代码是否在其计算机上编译了。 代码工作正常，他们很高兴，然后CI结束了构建，问题开始了：在由联盟维护的插件中编译失败，表明贡献者未在其计算机上构建。 该插件可能依赖于第三方库（例如CUDA），并且用户不希望，不知道该怎么做，或者只是出于硬件原因而不能编译该损坏的插件。 因此，那么-PR永远处于永远不会合并的PR的边缘-或贡献者在损坏的插件的源中抓取重命名的变量，更改代码，推入他/她的分支，等待CI会完成编译，通常会收到更多错误，并重复执行该过程，直到CI满意为止-或财团中两个已经超额预定的永久物之一提供帮助，并尝试在其计算机上修复PR。 这些选项都不可行，但我们只是不知道如何做不同。您是否曾经遇到过类似的项目情况？如果是这样，您如何处理这个问题？有没有我在这里看不到的解决方案？
16
程序员应该修复别人的失败构建吗？[关闭]
一位程序员将一些工作委托给SVN存储库，然后回家。他离开后，哈德森的自动构建失败了。另一位程序员看到了这一点，并在查看了代码更改之后，发现问题是缺少一个库。他将此库添加到SVN中，下一个构建成功完成。 第二个程序员是做正确的事情还是应该等到第一个程序员解决了这个问题之后？
8
自动还原失败的提交
我的一位同事告诉我，他正在考虑使我们的CI服务器还原失败构建的提交，因此HEADin master始终是稳定的（至少在通过构建时如此）。 这是最佳实践master吗？还是比在开发人员修复它之前让它崩溃更成问题？ 我的想法是，还原提交会使读取提交和修复的任务变得更加复杂（开发人员必须先还原还原，然后提交修复，这也会使混乱git log），我们应该离开提交然后提交固定。尽管我看到了master稳定的优点，但是这种失败提交的还原并不能说服我。 编辑：不管是master开发分支还是其他任何开发分支都没有关系，但问题仍然存在：CI系统是否应还原使构建失败的提交？ 另一个（冗长）编辑：好的，我们git以一种奇怪的方式使用。我们认为，分支的概念与真实CI背道而驰，因为提交分支会使您与其他开发人员及其更改隔离开来，并在您不得不重新集成分支并处理可能的冲突时增加了时间。如果每个人都致力于master此冲突，则将冲突减至最少，并且每次提交均通过所有测试。 当然，这迫使您只推稳定（或破坏构建）并更仔细地编程，以免在引入新功能时破坏向后兼容性或进行功能切换。 以此方式进行CI时需要权衡取舍，但这超出了问题的范围（有关此问题，请参阅相关问题）。如果您愿意，我可以改写这个问题：一小群开发人员在功能分支中一起工作。如果一个开发人员提交的内容破坏了该分支的构建，则CI系统是否应还原提交？
9
在版本控制挂钩中运行单元测试是一种好习惯吗？
从技术角度来看，可以添加一些前/后推钩，以在允许某些特定的提交合并到远程默认分支之前运行单元测试。 我的问题是-最好将单元测试保留在构建管道中（因此，将损坏的提交引入仓库），还是最好不要允许“不良”的提交发生。 我确实意识到我不受这两种选择的限制。例如，在将合并提交提交到仓库之前，我可以允许所有提交分支和测试。但是，如果您必须在这两种解决方案之间进行选择，那么您将选择哪种解决方案，以及出于哪些确切原因？
2
为什么build.number是语义版本控制的“滥用”？
我解释提出了构建系统（摇篮/ Artifactory的/詹金斯/厨师），以我们的高级建筑师之一，他所提出的意见，我认为我的那种不同意，但我没有足够的经验，真正权衡上。 该项目构建了一个Java库（JAR）作为工件，供其他团队重用。对于版本控制，我想使用以下语义方法： <major>.<minor>.<patch> 其中patch指示错误/紧急修复，minor指示向后兼容的发行版，并major指示API的大规模重构和/或向后不兼容的更改。 就交付而言，这就是我想要的：开发人员提交一些代码；这将触发构建到QA / TEST环境。一些测试已经运行（一些自动化，一些手动）。如果所有测试均通过，则生产版本会将JAR发布到我们的内部仓库中。至此，应该正确地对JAR进行版本控制，我的想法是使用build.numberCI工具自动生成并提供的JAR 作为补丁号。 因此，版本控制实际上是： <major>.<minor>.<build.number> 同样，build.numberCI工具在哪里提供。 架构师对此表示否认，称使用CI版本号是语义版本控制的“滥用”。 我的问题是：这是正确的吗？如果正确，为什么？如果没有，为什么不呢？
12
DVCS是否会阻止持续集成？
假设有一个由十个敏捷开发人员组成的团队。每天他们每个人都从董事会中挑选一项任务，并对它做出一些更改，直到（直到一天结束）他们已经完成了任务。所有开发人员都直接通过主干签入（Google风格，每次提交都是候选版本，使用功能切换等）。 如果他们使用的是像SVN这样的集中式CVS，那么每当其中一个提交时，构建服务器就会针对其他9个开发人员的工作进行集成并测试其更改。构建服务器几乎将全天连续运行。 但是，如果他们使用的是git之类的DCVS，则开发人员可能会等到完成任务后，再将所有本地提交一起推送到中央存储库。直到一天结束，他们的更改才会被整合。 在这种情况下，SVN团队更加频繁地进行集成，并且比git团队更快地发现集成问题。 这是否意味着DVCS比老式的集中式工具更不适合连续团队使用？你们如何解决这个推迟推送的问题？
12
在持续集成对我们有效之前有多少开发人员？
与持续集成相关的开销包括设置，重新培训，意识活动，停止修复最终导致数据问题的“错误”，强制分离关注点编程样式等。 持续集成在什么时候可以收回成本？ 编辑：这些是我的发现 设置是带有Nant的CruiseControl.Net，从VSS或TFS读取。 以下是失败的一些原因，这些原因与设置无关： 调查成本：调查红灯是否是由于代码，数据质量或诸如基础结构问题（例如，网络问题，从源代码管理，第三方服务器读取的超时）之类的其他来源上的真正逻辑不一致所花费的时间掉了，等等，等等） 基础设施方面的政治成本：我考虑过在测试运行中对每种方法执行“基础设施”检查。除了更换构建服务器之外，我没有解决超时的方法。繁文tape节阻碍了系统，没有更换服务器。 修复单元测试的成本：数据质量问题引起的红灯可能表明单元测试写得不好。因此，重写了与数据相关的单元测试，以减少由于不良数据而导致出现红灯的可能性。在许多情况下，必要的数据被插入到测试环境中，以便能够准确地运行其单元测试。可以说，通过使数据更加健壮，然后依赖于该数据的测试就变得更加健壮。当然，这很好！ 覆盖成本，即为现有代码编写单元测试：存在单元测试覆盖率的问题。有成千上万种没有单元测试的方法。因此，将需要大量的工作日来创建这些工作日。由于这很难提供业务案例，因此决定将单元测试用于以后的任何新公共方法。那些没有进行单元测试的人被称为“潜在的红外线”。此处的一个令人感兴趣的观点是，静态方法是如何唯一确定特定静态方法如何失败的争议点。 定制发布的成本：仅Nant脚本到目前为止。例如，它们对于EPiServer，CMS或任何面向UI的数据库部署的CMS依赖版本不是很有用。 这些是每小时进行一次测试运行和过夜进行QA生成时在生成服务器上发生的问题的类型。我认为这些是不必要的，因为构建大师可以在发布时手动执行这些任务，尤其是一个人的团队和一个小的构建。因此，以我的经验，单步构建并不能证明使用CI是合理的。那么更复杂的多步骤构建又如何呢？这些可能很难构建，尤其是在没有Nant脚本的情况下。因此，即使创建了一个，也不再成功。解决红灯问题的成本超过了收益。最终，开发人员失去了兴趣并质疑红灯的有效性。 经过一番尝试，我相信CI的成本很高，并且有很多工作要做，而不仅仅是完成工作。雇用经验丰富的开发人员，而不是搞乱大型项目，比引入和维护警报系统更具成本效益。 即使这些开发人员离开也是如此。优秀的开发人员是否离开并不重要，因为他遵循的流程将确保他编写需求规范，设计规范，遵守编码准则并注释其代码以使其可读。所有这一切都进行了审查。如果这没有发生，那么他的团队负责人就没有做好他的工作，这应该由他的经理接任，依此类推。 要使CI正常工作，仅编写单元测试，尝试保持完整的覆盖范围并确保可运行的系统的基础架构还不够。 最重要的是：人们可能会质疑，从业务角度来看，是否甚至需要在发布之前修复尽可能多的错误。CI涉及许多工作，以捕获少量错误，客户可以在UAT中识别出这些错误，或者无论如何在保修期到期时，作为客户服务协议的一部分，公司都可以获得酬劳。
11
进行持续集成时应何时进行代码审查？
我们正在尝试切换到持续集成环境，但是不确定何时进行代码审查。根据我对持续集成的了解，我们应该每天尝试多次检入代码。我认为，这甚至意味着尚未完成的功能。 所以问题是，我们什么时候进行代码审查？ 在签入代码之前，我们无法执行此操作，因为这会减慢我们无法进行每日签入的过程，更不用说每天进行多次签入了。 同样，如果我们正在检入的代码只是编译但功能不完整，那么进行代码检查就没有意义，因为大多数代码检查最好在功能完成时完成。这是否意味着我们应该在功能完成时进行代码审查，但是未审查的代码将进入存储库？
3
持续集成的简单说明
您将如何定义持续集成以及CI服务器包含哪些特定组件？ 我想向市场部门的某人解释什么是持续集成。他们了解源代码控制-即他们使用Subversion。但我想向他们正确解释什么是CI。在维基百科的文章从来没有正确定义它，在Martin Fowler的文章仅给出以下，这基本上是同义反复其次是“一体化”的模糊解释： 持续集成是一种软件开发实践，团队成员经常集成他们的工作，通常每个人至少每天集成一次-导致每天多次集成。每个集成都通过自动构建（包括测试）进行验证，以尽快检测到集成错误。 更新：我给他们发了这张图片，我找不到一个更简单的图片。 更新2：从市场营销工作组反馈（针对存在3个问题的时间）： 我实际上很喜欢这三个答案–出于不同的原因。我想登录只是为了感谢所有人！ 显然他不能-所以代表他:) 更新3：我已经了解了Wikipedia文章，其中确实包含一些原则，当您仅使用标题时，它们是一个不错的清单： 维护代码库 自动化构建 使构建自检 每个人每天都致力于基线 每次提交（到基线）都应该构建 保持快速构建 在生产环境的克隆中进行测试 轻松获取最新交付物 每个人都可以看到最新版本的结果 自动化部署
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.