Questions tagged «builds»

在我看来，如果最终用户在生产中发现了严重的错误，应该添加一个失败的单元测试来覆盖该错误，从而有意破坏该构建，直到修复该错误为止。我这样做的理由是构建应该一直失败，但这并不是由于自动测试覆盖率不足所致。 我的几个同事不同意说不应该检查失败的单元测试。就正常的TDD惯例而言，我同意这种观点，但是我认为应该以不同的方式处理生产错误-毕竟，为什么要允许建立已知缺陷的成功方案？ 是否有其他人具有处理这种情况的可靠策略？我知道故意破坏构建可能会对其他团队成员造成破坏，但这完全取决于您使用分支机构的方式。

410 unit-testing  tdd  builds 

我在项目中的第一次提交导致夜间构建被破坏，当我们临近发布时，人们遍布我。我想发送一封道歉的电子邮件，听起来应该很真诚，同时暗示这是我的第一次提交，不再赘述。 作为非英语母语者，我很难提出正确的单词。有人可以帮忙吗？

181 continuous-integration  builds  release 

我的组织正在考虑从SVN迁移到Git。反对搬迁的一种论据如下： 我们如何进行版本控制？ 我们有一个基于NetBeans平台的SDK发行版。由于SVN修订版是简单的数字，因此我们可以使用它们来扩展我们的插件和SDK构建的版本号。转移到Git时如何处理？ 可能的解决方案： 使用Hudson的内部版本号（问题：您必须检查Hudson才能将其与实际的Git版本相关联） 手动升级版本以保持夜间稳定（问题：学习曲线，人为错误） 如果其他人遇到了类似的问题并解决了该问题，我们将很乐意听听如何解决。

131 version-control  git  svn  builds  versioning 

在我的大部分编程生涯中，我都在与我一起使用的IDE中使用“ build / compile / run”命令来生成可运行的程序。这是一个按钮，非常简单。但是，随着我对不同语言和框架的更多了解，我越来越多地谈论“构建脚本”（ANT，Maven，Gradle等）来运行项目。我对这些的理解是，它们是给编译器/链接器/ magical-program-maker的指令，用于指定配置详细信息-细节。 我记得在学校时曾写过makefile，但是那时我并没有看到任何特殊的优势（我们只在Unix终端中使用它们，因为在该终端中没有带有“构建”按钮的IDE）。除此之外，我在这里还看到了其他问题，这些问题讨论了构建脚本不仅可以创建程序，还可以做更多的事情- 它们可以运行单元测试以及安全的资源，而与主机无关。 我不能忘记构建脚本对于作为开发人员来说很重要的感觉，但是我想要一个有意义的解释。为什么要使用/编写构建脚本？ Build Script和Build Server的职责讨论了它在更大范围内的作用。我正在寻找构建脚本相对于IDE的“构建/运行”命令或类似的简单方法所提供的特定优势。

97 development-process  builds 

软件包管理系统存在一些编程语言： TeX的CTAN Perl的CPAN Python的点子和鸡蛋 Java Maven 阴谋的哈斯克尔 红宝石宝石 NPM对的NodeJS 前端Javascript和CSS的Bower nuget for C＃ PHP 作曲家 这样的系统还有其他语言吗？C和C ++呢？（这是主要问题！）为什么没有适用于他们的系统？而不是创建包yum，apt-get或其他一般的包管理系统更好？

78 c++  c  builds  packages 

由于多种原因导致上一个构建周期的部署不佳，我竞选办公室使用专用的构建机器执行所有将来的部署，而我的老板接受了这个建议。 但是，我们不必在办公室使用一台实际的机器，而必须与其他几个小组共享一台机器-麻烦的是必须带着所有必要的信息离开我的办公室然后走上楼梯到另一个办公室来执行简单的构建，这让我想知道为什么我一开始就提出这个建议。 最初，拥有一台单独的构建机器的想法是，将我自己的本地编写的代码与其他几名开发人员的代码分开，并从部署中分离出我在机器上拥有的所有劫持文件。这也是为了解决我对ClearCase文件管理系统日益增长的担忧，该系统通常拒绝让我部署某些构建活动，除非我还包括了另一个具有“依赖关系”的活动。 现在，我实际上正在执行此过程，我想知道我是否误解了使用构建机器的全部目的-并且由于我们仅使用该机器将代码部署到我们的测试，登台和生产环境，以及不是针对我们的个人开发人员测试部署，我不确定它是否有任何用途。 那么，使用构建机器的真正原因是什么，我什至接近正确使用它？

74 deployment  builds 

我对内部版本号的看法是，每当创建一个新的每晚内部版本时，都会生成一个新的BUILDNUMBER并将其分配给该内部版本。因此，对于我的7.0版本应用程序，夜间版本将为7.0.1、7.0.2等。是这样吗？那么在内部版本号之后REVISION的用途是什么？还是在每个夜间构建后增加REVISION部分？我在这里有点困惑...我们是否将每个每晚的建筑都称为BUILD？ 此处提到了格式：AssemblyVersion-MSDN

55 builds  versioning 

我解释提出了构建系统（摇篮/ Artifactory的/詹金斯/厨师），以我们的高级建筑师之一，他所提出的意见，我认为我的那种不同意，但我没有足够的经验，真正权衡上。 该项目构建了一个Java库（JAR）作为工件，供其他团队重用。对于版本控制，我想使用以下语义方法： <major>.<minor>.<patch> 其中patch指示错误/紧急修复，minor指示向后兼容的发行版，并major指示API的大规模重构和/或向后不兼容的更改。 就交付而言，这就是我想要的：开发人员提交一些代码；这将触发构建到QA / TEST环境。一些测试已经运行（一些自动化，一些手动）。如果所有测试均通过，则生产版本会将JAR发布到我们的内部仓库中。至此，应该正确地对JAR进行版本控制，我的想法是使用build.numberCI工具自动生成并提供的JAR 作为补丁号。 因此，版本控制实际上是： <major>.<minor>.<build.number> 同样，build.numberCI工具在哪里提供。 架构师对此表示否认，称使用CI版本号是语义版本控制的“滥用”。 我的问题是：这是正确的吗？如果正确，为什么？如果没有，为什么不呢？

35 continuous-integration  versioning  builds  continuous-delivery  semantic-versioning 

因此，我遇到了很多有关直接创建makefile的评论/帖子/等等，以及在2015年如何做是一件愚蠢的事情。我知道诸如CMake之类的工具，实际上我经常使用CMake。事实是，CMake只是为您创建Makefile，并帮助消除了您自己做的乏味。当然，它还添加了许多其他强大的功能……但是最后它仍然是一个Makefile。 所以我的问题是，关于make的“过时”讨论是指整个Make实用程序，还是仅仅是手动编写自己的Makefile的想法？我根本不使用IDE进行C / C ++开发（只是emacs），所以我总是写Makefile。 如果Make被认为已经过时，那么C / C ++开发人员应该使用什么来构建小型个人项目？

31 c++  c  builds  make  cmake 

我在一个中型团队中工作，该团队共享相同的源代码，并且有持续的集成，但是由于我们所有人都必须在同一个分支中工作，因此构建几乎总是被破坏。 我们还有一条规则，该规则最近被引入以减轻损坏的构建，该规则指出在构建为红色时不允许任何人签入。 话虽这么说，一天中每个人都只有几个10-15分钟的窗口，我们可以在那里办理登机手续。 并且随着团队的成长，签到机会的窗口会进一步缩小。这迫使开发人员在本地积累他们的更改，从而导致更大的更改集，这甚至更加难以确保更改不会破坏任何内容。您可以看到恶性循环。 您能推荐什么使我在这样的环境中保持有效的工作。另外，请记住，我是开发人员，而不是经理，并且不能改变流程或其他人的行为。

25 version-control  teamwork  continuous-integration  builds  branching 

想要改善这篇文章吗？提供此问题的详细答案，包括引文和答案正确的解释。答案不够详细的答案可能会被编辑或删除。 如果Java是一种通用语言，而构建程序可以用Java语言来描述，那么为什么这不是编写构建文件的最佳方法，而是使用Ant，Maven和Gradle之类的工具呢？那不是更直接，而且不需要学习另一种编程语言吗？（顺便说一句-这个问题也可以应用于其他语言，例如C＃）

24 java  c#  builds  build-system 

此问题是从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行）。它看起来容易出错并且很耗时，对于我的情况来说是不必要的。更不用说学习曲线了，这将使我为使产品准备向人们展示而正在做的所有其他工作都浪费了时间。

22 builds  continuous-integration  maven  ant 

我在团队中的角色之一是构建人员。我负责维护/更新我们的构建脚本，并确保我们在连续集成服务器上“顺利”构建。我通常不介意这份工作，尽管经常感觉好像我一直在保姆CI服务器。 该工作有时会很烦人，因为如果构建中断，我必须放弃我正在研究的故事并调查构建失败。建设失败每天都在我们的团队中发生。有时，开发人员只是在提交之前未在本地进行构建，因此测试在CI服务器上失败。在这种情况下，我想快速联系遇到“错误提交”的人，以使构建不会太长时间损坏。有时（不那么频繁）在CI服务器上存在需要调试的奇怪情况。 我知道许多成熟的团队都使用持续集成，但是关于良好实践的材料并不多。 我的问题是否指出我们的持续集成还不是很成熟，或者这仅仅是工作的一部分？ 要遵循哪些良好做法？成熟的持续整合的特点是什么？ 更新资料 除了回答一些评论外，我将进行更新。我们有一个简单的命令，它完全可以执行构建应用程序时构建服务器的操作。它将编译，运行所有单元/集成以及一些基于UI的快速测试。 阅读每个人的答案，感觉我们可能有两个主要问题。 当构建失败时，CI Server不会抱怨得太大声。 开发人员并不觉得确保自己的提交成功完成是每个人的责任。 使我的团队变得更困难的是，我们有一个庞大的团队（超过10个开发人员），并且有几个离岸团队成员甚至在不上班的时候都会投入工作。因为团队规模很大，并且我们确定经常进行小型提交是首选，所以有时我们一天中确实有很多活动。

22 builds  continuous-integration 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 有很多不同的持续集成（CI）框架，我想知道哪种框架最受欢迎。您在您所在的公司使用了哪些框架？ 是否有任何理由使一个CI框架比其他CI框架更受欢迎-也许与它提供的功能，集成到其中的东西有关？ 似乎在Java和.net世界中使用持续集成比使用ruby或python要多。为什么是这样？

21 java  c#  development-process  builds 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 乔尔测试的标准之一是日常构建。想法是，如果构建已损坏，则无论谁破坏了它，都可以修复它。如果无法修复该版本，则每个人都必须签出旧版本并进行处理。我可以理解，这对于集中式版本控制而言可能是非常糟糕的，在集中式版本控制中，尽可能避免合并和分支很重要，但这听起来像是分布式版本控制的一个小麻烦。你同意吗？还有其他原因使每日构建很重要吗？

20 joel-test  version-control  builds