Questions tagged «continuous-integration»

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

8
使用CI工具运行流程是否合理？
在我的公司中，我们经历了不同的Cron工作（在多个系统上）的泥潭，并且手动启动了流程，这些流程使我们的业务正常运转，这是多年的权宜之计和后来的疏忽的结果。 有一天，出于明显的原因，我们将需要提出一个更加集中的解决方案。 我们一直在考虑的一个想法是使用我们的持续集成软件（Jenkins）运行这些过程，这似乎是合乎逻辑的。 我的问题是：其他公司也在这样做吗？这是普遍接受的做法吗？这是否与名称中隐含的CI工具的定义不冲突？还有其他选择吗？ 注意：https： //wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins 詹金斯声称，它专注于“监视外部运行的作业的执行情况，例如cron作业和procmail作业”。我不确定这是否正是我在说的。
7
当构建几乎总是被破坏时如何保持效率
我在一个中型团队中工作，该团队共享相同的源代码，并且有持续的集成，但是由于我们所有人都必须在同一个分支中工作，因此构建几乎总是被破坏。 我们还有一条规则，该规则最近被引入以减轻损坏的构建，该规则指出在构建为红色时不允许任何人签入。 话虽这么说，一天中每个人都只有几个10-15分钟的窗口，我们可以在那里办理登机手续。 并且随着团队的成长，签到机会的窗口会进一步缩小。这迫使开发人员在本地积累他们的更改，从而导致更大的更改集，这甚至更加难以确保更改不会破坏任何内容。您可以看到恶性循环。 您能推荐什么使我在这样的环境中保持有效的工作。另外，请记住，我是开发人员，而不是经理，并且不能改变流程或其他人的行为。
4
如何使用github，分支机构和自动发布进行版本管理？[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 到目前为止，我已经了解了大多数基本的Git / Github概念，但是仍然很难理解全局。 到目前为止，我已经设法使这些事情起作用： 推送提交 与分支机构合作 将Github与Travis CI（一个持续集成系统）集成 通过Travis CI，可以自动构建对master的每次提交，并将该发行版作为ZIP放在Github上的发行版之下。 但是到目前为止，我只从事项目的alpha / beta版本工作，因此我还从未见过实践中的版本发布。 因此，我想了解更多有关版本控制，维护单独的版本，修复版本等信息。 我将如何确保发生以下情况： 我的项目有不同的版本，例如版本1.1.0和2.0.0 能够在版本上推送修补程序，将版本提高到1.1.1或2.0.1，等等。 使一个持续集成系统在提交时自动构建该版本，如果成功，则发布该特定版本的发行版。 我怀疑以下选项之间： 每个版本都需要使用标签吗？如果是这样，一个持续集成系统如何构建自动发布？ 我应该为每个版本创建分支吗？如果是这样，那将不会创建大量的分支（例如1.1和2.0分支，修补程序当然会进入该分支） 我将如何指定版本号？是否可以使用一个指定版本号的配置文件，还是可以使用更智能的方法？在这种情况下，这很重要，这将是一个Java项目。
4
CI如何用于解释语言？
我以前从未使用过持续集成系统（CI）。我主要使用MATLAB，Python或PHP进行编码。这些都没有构建步骤，我看不到如何将CI用于我的工作。一家大型公司的大型项目中的一位朋友告诉我，语言并不重要。 如果没有构建步骤，我看不到CI对我有什么用。我可以将CI视为可以运行单元测试的测试环境。我想念什么吗？
6
持续集成科学软件
我不是软件工程师。我是地球科学领域的博士生。 大约两年前，我开始编写科学软件。我从未使用过持续集成（CI），主要是因为起初我不知道它的存在，而且我是唯一使用此软件的人。 现在，由于该软件的基础正在运行，因此其他人开始对它产生兴趣并希望为该软件做出贡献。计划是其他大学的其他人正在实施核心软件的添加。（我担心他们会引入错误）。此外，该软件变得非常复杂，并且变得越来越难以测试，我也计划继续进行开发。 由于这两个原因，我现在越来越多地考虑使用CI。因为我从未接受过软件工程师的培训，而且周围的人都没有听说过CI（我们是科学家，所以没有程序员），所以我很难开始我的项目。 我有几个问题想向我寻求建议： 首先简要说明该软件的工作方式： 该软件由一个包含所有必需设置的.xml文件控制。您只需通过将路径传递到.xml文件作为输入参数来启动软件，它就会运行并创建带有结果的几个文件。一次运行可能需要30秒钟。 这是一个科学软件。几乎所有的函数都有多个输入参数，它们的类型主要是非常复杂的类。我有多个具有大型目录的.txt文件，用于创建这些类的实例。 现在让我们来问我的问题： 单元测试，集成测试，端到端测试？：我的软件现在大约有30.000行代码，具有数百个功能和约80个类。开始为数百种已经实现的功能编写单元测试对我来说有点奇怪。因此，我考虑过简单地创建一些测试用例。准备10-20个不同的.xml文件，然后运行该软件。我猜这就是所谓的端到端测试？我经常读到您不应该这样做，但是如果您已经拥有可以运行的软件，那么也许可以开始吗？还是尝试将CI添加到已经运行的软件中只是愚蠢的想法。 如果功能参数难以创建，如何编写单元测试？ 假设我有一个函数double fun(vector<Class_A> a, vector<Class_B>)，通常，我需要首先读取多个文本文件来创建类型为Class_A和的对象Class_B。我考虑过要创建一些虚拟功能，例如Class_A create_dummy_object()不读取文本文件。我还考虑过实现某种序列化。（我不打算测试类对象的创建，因为它们仅依赖于多个文本文件） 如果结果变化很大，如何编写测试？我的软件利用了大型蒙特卡洛模拟并可以迭代地工作。通常，您需要进行约1000次迭代，并且每次迭代都基于Monte Carlo模拟创建约500-20.000个对象实例。如果一次迭代的一个结果只有一点点不同，则整个即将到来的迭代将完全不同。您如何处理这种情况？我认为这对端到端测试来说很重要，因为最终结果变化很大？ 对于CI的其他建议，我们深表感谢。
2
在VCS中存储软件版本号是一种好习惯吗？
产品版本（例如）v1.0.0.100不仅代表软件的唯一生产版本，而且还有助于识别该产品的功能集和修补程序阶段。现在，我看到两种方法来维护产品的最终程序包/内部版本/二进制版本： 版本控制。一个文件存储着版本号。持续集成（CI）构建服务器将具有脚本来构建软件，该脚本使用此签入的版本号将其应用于所需的软件的所有区域（二进制文件，安装程序包，帮助页面，文档等）。 环境和/或构建参数。这些在版本控制之外进行维护（即，它们不依赖于快照/标签/分支）。构建脚本以相同的方式分配和使用数字，但是它们只是以不同的方式获取值（将其提供给构建脚本，而不是让脚本知道相对于源树在何处获取该值）。 第一种方法的问题在于，它会使跨主线分支的合并变得复杂。如果您仍然维护同一软件的2个并行发行版，并且自上次合并以来两个主版本的版本均已更改，则将在合并两个主干之间时解决冲突。 第二种方法的问题是和解。回到1年前的发行版时，您将仅依靠标签信息来标识其发行版号。 在这两种情况下，版本号的某些方面可能在CI生成之前是未知的。例如，CI构建可能会以编程方式放入第4个组件，该组件实际上是自动构建编号（例如，分支上的第140个构建）。它也可能是VCS中的修订号。 跟上软件版本号的最佳方法是什么？是否应始终在VCS中维护“已知”部分？如果是这样，主线分支之间的冲突是否成为问题？ 现在，我们通过CI构建计划（Atlassian Bamboo）中指定和维护的参数来维护版本号。在合并到我们的master分支机构之前，我们必须小心一点，即在开始构建CI之前已正确设置了版本号。关于Gitflow工作流程，我认为，如果在源代码管理中跟踪了版本号，我们可以保证在创建release分支以准备发布时正确设置了版本号。质量检查人员将在该分支机构上执行最终的集成/烟熏/回归测试，并在签收后进行合并，master这表示发布承诺。
9
说服一个孤独的开发人员使用单独的构建工具，而不是IDE一键式构建
此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 7年前。 在Java和Scala编程的多年中，我从未使用过Ant，Maven，Gradle或任何这些Java构建工具。在我工作过的所有地方，都有一个构建经理来负责所有这些工作-我将使用IDE在本地进行编译以进行开发和单元测试，然后检查源代码，并通知构建经理完成了必要的工作。为共享环境编译每个人的文件。 现在，我处于合同之间，我一直在从事我自己的自筹资金项目，现在正好可以实际赚钱。我什至有潜在的投资者在排队，并计划在未来几周内向他们展示Beta版本。 但是一直以来，我只是单击IDE上的build按钮，它会创建Jar文件，并且效果很好。当然，传统的观点建议我“应该”编写自己的Ant / Maven / Gradle脚本并使用它而不是IDE，但是在我的情况下（单独工作）它的具体优势是什么？ 我已经阅读了一些有关如何使用这些构建工具的文章，看起来我将编写数百行XML（或Groovy或其他内容）以一键完成IDE的工作（IDE生成的该项目的Ant XML超过700行）。它看起来容易出错并且很耗时，对于我的情况来说是不必要的。更不用说学习曲线了，这将使我为使产品准备向人们展示而正在做的所有其他工作都浪费了时间。
6
连续交付在实践中如何工作？
连续交付听起来不错，但是我多年的软件开发经验表明，在实践中它是行不通的。 （编辑：为了明确起见，我总是有很多测试会自动运行。我的问题是关于如何使每次签入都充满信心，我知道这是CD的完整格式。替代方法不是一年周期每周两次（如果正确完成，有些人可能会认为它仍然是CD），两周或一个月的迭代；在每个迭代的末尾都包含老式的质量检查，以补充自动化测试。 无法全面覆盖测试。对于每件事，您都必须投入大量时间-时间就是金钱。这是有价值的，但是可以花费时间以其他方式为质量做出贡献。 有些事情很难自动测试。例如GUI。甚至Selenium也不会告诉您您的GUI是否不稳定。没有笨拙的固定装置，很难测试数据库访问，甚至无法覆盖数据存储中的奇怪情况。同样的安全性和许多其他事情。只有业务层代码才可以有效地进行单元测试。 即使在业务层中，大多数代码也不是简单函数，其参数和返回值可以很容易地隔离以进行测试。您可能会花费大量时间来构建模拟对象，这可能与实际实现不符。 集成/功能测试是对单元测试的补充，但是它们需要大量时间才能运行，因为它们通常涉及在每个测试中重新初始化整个系统。（如果不重新初始化，则测试环境会不一致。） 重构或任何其他更改都会破坏很多测试。您花费大量时间修复它们。如果只需要验证有意义的规范更改，那很好，但是测试常常由于无意义的低级实现细节而失败，而不是真正提供重要信息的东西。通常，调整主要集中在重新测试内部，而不是真正地检查正在测试的功能。 错误的现场报告无法轻松地与代码的精确微版本相匹配。
11
照顾您的持续集成系统
我在团队中的角色之一是构建人员。我负责维护/更新我们的构建脚本，并确保我们在连续集成服务器上“顺利”构建。我通常不介意这份工作，尽管经常感觉好像我一直在保姆CI服务器。 该工作有时会很烦人，因为如果构建中断，我必须放弃我正在研究的故事并调查构建失败。建设失败每天都在我们的团队中发生。有时，开发人员只是在提交之前未在本地进行构建，因此测试在CI服务器上失败。在这种情况下，我想快速联系遇到“错误提交”的人，以使构建不会太长时间损坏。有时（不那么频繁）在CI服务器上存在需要调试的奇怪情况。 我知道许多成熟的团队都使用持续集成，但是关于良好实践的材料并不多。 我的问题是否指出我们的持续集成还不是很成熟，或者这仅仅是工作的一部分？ 要遵循哪些良好做法？成熟的持续整合的特点是什么？ 更新资料 除了回答一些评论外，我将进行更新。我们有一个简单的命令，它完全可以执行构建应用程序时构建服务器的操作。它将编译，运行所有单元/集成以及一些基于UI的快速测试。 阅读每个人的答案，感觉我们可能有两个主要问题。 当构建失败时，CI Server不会抱怨得太大声。 开发人员并不觉得确保自己的提交成功完成是每个人的责任。 使我的团队变得更困难的是，我们有一个庞大的团队（超过10个开发人员），并且有几个离岸团队成员甚至在不上班的时候都会投入工作。因为团队规模很大，并且我们确定经常进行小型提交是首选，所以有时我们一天中确实有很多活动。
9
您如何扩展集成测试？
我正在研究用于扩展我们当前产品上不断增加的集成测试数量的技术和策略，以便使它们（人类）能够成为我们开发和CI流程的一部分。 在大约200多个集成测试中，我们已经达到1小时的标准以完成完整的测试运行（在台式机上运行），这对开发人员在常规推送过程中容忍运行整个套件的能力产生了负面影响。这正影响着积极地去管教他们创造良好的动机。我们只对关键的场景进行前后集成测试，并且我们使用的环境可以反映生产，该环境是在每次测试运行时从头开始构建的。 由于运行需要时间，因此无论测试运行有多集中，都会造成严重的反馈循环和许多浪费的周期，等待机器完成测试运行。别介意对流程和进度，理智和可持续性造成更大的负面影响。 我们希望在该产品开始变慢之前进行10倍以上的集成测试（虽然还不知道，但似乎还没有开始使用功能）。我认为在某些时候，我们必须合理地期望要进行几百或几千个集成测试。 明确地说，要防止这种情况成为关于单元测试和集成测试的讨论（永远不要交易）。我们正在使用TDD进行单元测试，并在该产品中进行集成测试。实际上，我们在服务体系结构的各个层进行集成测试，这对我们有意义，因为我们需要验证在将体系结构中的模式更改为其他领域时，我们在何处引入重大更改。系统。 关于我们的技术栈的一些知识。我们目前正在（CPU和内存密集型）仿真环境上进行测试，以从头到尾运行我们的测试。由组成noSql后端（ATS）的Azure REST Web服务组成。我们通过在Azure桌面模拟器+ IISExpress中运行来模拟生产环境。每台开发机仅限于一个模拟器和一个本地后端存储库。 我们也有一个基于云的CI，它可以在相同的仿真环境中运行相同的测试，并且与我们当前的CI提供程序一起在云中进行测试所花费的时间是其两倍（2小时以上）。就硬件性能而言，我们已经达到了云CI提供程序SLA的极限，并且超出了他们在测试运行时间上的允许范围。为了公平起见，他们的规格还不错，但显然是内部脏台式机的一半。 我们正在使用一种测试策略，为每个逻辑测试组重建数据存储，并预加载测试数据。在全面确保数据完整性的同时，这对每个测试增加了5-15％的影响。因此，我们认为在产品开发的这一点上优化该测试策略几乎无济于事。 总而言之，它的缺点是：尽管我们可以优化每个测试的吞吐量（即使每个测试的吞吐量提高多达30％-50％），但在不久的将来，我们仍然无法通过数百个测试有效地扩展规模。现在1小时甚至还远远超出了人类可以忍受的范围，我们需要在整个过程中进行一定程度的改进以使其可持续。 因此，我正在研究可以采用哪些技术和策略来大大减少测试时间。 编写更少的测试不是一种选择。让我们不要在这个线程中争论那个。 尽管价格昂贵，但绝对可以选择使用更快的硬件。 无疑，在并行环境中在单独的硬件上运行测试/方案组也是肯定的选择。 围绕正在开发的功能和场景创建测试分组是合理的，但最终无法证明完整的覆盖范围或对系统不受更改影响的信心。 从技术上讲，可以在云规模的暂存环境中运行而不是在台式机模拟器中运行，尽管我们开始将部署时间添加到测试运行中（在测试运行开始时每个部署时间大约20分钟以部署内容）。 将系统的组件分成独立的逻辑部分在一定程度上是合理的，但是由于组件之间的干扰预计会随着时间而增加，因此我们认为在此方面的里程有限。（即，更改是无效的，可能会以意想不到的方式影响其他人，这在系统逐步开发时经常发生） 我想看看其他人在这个领域使用什么策略（和工具）。 （我必须相信其他人在使用某些技术集时可能会遇到这种困难。） [更新：2016年12月16日：我们最终在CI并行测试上投入了更多资金，以讨论结果：http：//www.mindkin.co.nz/blog/2015/12/16/16-jobs]
7
持续集成：哪个频率？
我总是在每次提交后启动构建，但是在这个新项目中，架构师只是要求我将频率更改为“每15分钟构建一次”，而我只是不明白为什么这是一个很好的理由，而不是“以每次提交为基础”。 首先，一些细节： Objective-C（iOS 5）项目 10名开发人员 每个构建实际上需要大约1分钟的时间，其中包括构建和单元测试。 集成服务器是Mac Mini，因此这里的计算能力并不是真正的问题 我们将Jenkins与XCode插件一起使用 我的观点是，如果您在每次提交时都进行构建，那么您现在就可以查看出了什么问题，并且可以直接更正您的错误，而不会过于困扰其他开发人员。另外，这样我们的测试仪就不会受到UT错误的困扰。他的论点是，开发人员将被“构建错误”邮件淹没（这不是完全正确的，因为可以将Jenkins配置为仅针对第一个损坏的构建发送邮件），并且如果频率频繁，则无法正确完成指标构建数太高。 那么，您对此有何看法？
8
防止分支堆积
随着我们变得越来越大，我们开始遇到问题，其中的功能使其可以分阶段进行测试，但是到所有测试和批准的新功能都在分阶段进行测试时。 这创造了一个环境，在该环境中我们几乎永远无法投入生产，因为我们拥有经过测试和未经测试的功能的组合。我敢肯定这是一个普遍的问题，但是我还没有找到对我们有用的资源。 一些细节： BitBucket上的GIT Jenkins用于脚本部署到Azure 我希望找到一种隔离特征的方法，使它们在环境中移动并仅推送准备就绪的产品。
3
分支机构中断持续集成吗？
我认为这篇文章《成功的Git分支模型》在经验丰富的DVCS用户中是众所周知的。 我hg主要使用它，但是我认为这种讨论对任何DVCS都适用。 我们当前的工作流程是每个开发人员克隆主存储库。我们在自己的本地仓库上编写代码，运行测试，如果一切顺利，则推送给主服务器。 因此，我们希望设置诸如Jenkins的CI服务器，并通过将来的预配系统（厨师，木偶，ansible等）改善我们的工作流程。 实部 好了，以上介绍的模型很好用，但分支机构可以破坏CI。Feature分支应该与原点同步（根据文章，它将是development分支），以使CI和合并更加顺利，对吗？ 说爱丽丝和鲍勃正在研究两个功能。但是爱丽丝第二天就完成了。鲍勃的功能需要一个星期。到Bob完成时，他的更改已过期（也许Alice重构/重命名了某些类）。 一种解决方案是，每天早晨开发人员必须master/origin检查是否有任何更改。如果Alice提交了，Bob应该拉入并合并到他的工作区中，以便他的功能分支是最新的。 这是个好方法吗？ 这些分支是否应该存在于主存储库中（不是本地克隆？），这意味着每个开发人员都应向GitHub / Bitbucket上的主存储库授予特权，以便他们可以创建新分支吗？还是在本地完成？ 最后，如果分支未与同步，则本文介绍的模型应打破CI origin/master。既然我们要进行夜间构建，开发人员是否应该在离开工作之前进行合并和合并，并且CI也要在每个功能分支上运行？
5
持续集成工具在一个单独项目中提供什么优势？
如果您正在做一个单独的项目-您是否会使用CI工具从存储库中进行构建？我在团队环境中使用了Hudson和Cruise Control，在该环境中，任何人只要签入任何东西就必须立即构建。 我认为版本控制的价值仍然显而易见，但是我是否需要在每次提交后进行构建，就像我只是在本地计算机上进行构建一样，没有人提交？
9
如何在没有技术专长的情况下领导开发项目
我在整个职业生涯中都是动手开发人员，并且喜欢使用代码。我一直对团队负责人感到不满，他们对某项技术几乎没有专门知识，却坚持要求一定的实施。 现在我发现自己在镜架的另一侧。我是使用C＃实现的胖客户端的主要开发人员，但是我的专长是构建Java Web应用程序。虽然我知道我可以使用任何一种语言来利用设计模式和OO范式，但是在编码标准，项目生命周期工具和发布/分发过程方面我迷失了。我毫不怀疑我可以在一两个月内掌握基础知识，但是有一些经验只能随着时间的推移而积累。 我应该怎么做，如何避免成为我在开发时讨厌的项目负责人？
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.