Questions tagged «continuous-integration»

持续集成(CI)是经常将开发人员的工作代码副本合并到共享代码库中的过程,以防止或最小化集成问题。对于诸如[Jenkins]或[Travis-CI]之类的特定CI系统的问题,请改用这些标签。


4
如何正确缩放詹金斯?
在我的项目中,我们有一台运行Jenkins Master的AWS服务器+ 1个Jenkins从属服务器(2个执行程序)...并且我们需要更多 以增强构建能力,我们有以下三种选择: 扩大规模:使AWS实例更大,并添加更多执行程序。 向上扩展:扩大 AWS实例并添加另一个jenkins从属进程。 向外扩展:使用jenkins从服务器创建另一个AWS实例,并将其连接到主服务器 我们想做的是2.我们身处一个大组织中,而我们目前的Jenkins Master已经可以访问他需要的每个地方。选项3。“新服务器”很复杂,因为它需要更多的官僚机构的批准,这将需要数周的时间。 所以我的问题是: 选项2是否有任何技术问题?。也许每个詹金斯奴隶的执行者都不知道其他奴隶的执行者? 通常,扩展Jenkins的最佳方法是什么?向上扩展还是向外扩展?

4
持续集成与持续交付/部署有何关系?
以下是连续积分当前内容的引文: ...经常将开发人员的工作代码副本合并到共享代码库中的过程,以防止或最小化集成问题。 好我知道了 但是接着还有连续交付和 连续部署,这就是我不断迷失的地方: 假设通过您沿生产线的某个地方最终将到达目标环境,那么持续集成与持续交付和/或持续部署之间的关系如何。integrationdeliveringdeployed 持续交付和持续部署之间有什么区别? 过去,在将DevOps称为DevOps之前,我们使用了术语,可能有助于理解这些新的DevOps术语,例如: 推动到(或降级从)一些预先PROD目标,任选地与一些类型的再生过程(编译,结合等)的组合中可执行状的东西封装所有相关组件在一起。那应该类似于/接近连续集成吗? 使用FTP之类的工具(如果标准副本无法弥合差距)将其分发到某些目标环境,但尚未在目标中激活它。那应该类似于/接近连续交付吗? 在某些目标环境中安装(或激活),并结合诸如绑定,停止/启动操作等内容。这应该类似于/接近于连续部署吗?

5
如何避免在测试环境中持续集成导致的不稳定?
假设您使用的是持续集成过程,该过程会经常更新某些目标环境,以便每次发生某些更改时,“您”都可以立即测试您的更改。那是CI的目标之一,不是吗? 但是,还要假设您在测试周期中涉及其他人员,例如经理或客户。让其他人参与尝试(中断)您即将进行的更改很有意义,不是吗? 但是,如果您继续在其他人正认真尝试测试的环境中不断交付更改,那么可能会出现多个问题,例如: they 可能会浪费他们的时间来报告问题,而当他们保存(深入)报告时,他们甚至无法自己重现该问题(例如,由于您偶然遇到了同一问题,并且已经将其修复在他们的环境中)。 you 可能无法重现他们报告的问题,因为遇到问题的环境不再相同(您(!!!)可能覆盖了他们的环境)。 那么,您该怎么做(如何配置事物?)来避免此类(令人沮丧的)情况?

4
如何从复杂的分支现实过渡到单分支模型?
在大型组织中,使用瀑布方法通常会导致非常复杂的分支结构(又称分支spagetti)。 可以使用哪些分支策略从复杂的分支现实过渡到基于分支的开发之类的单分支模型? 更新: 要澄清的是,问题是关于迁移/过渡本身,而不是关于之前和之后的方法,这很清楚。 不可能真的是“今天在EOB,我们仍然是拥有数以万计的分支机构的瀑布,但是明天第一件事,我们将切换到基于中继的单分支CI”。

3
AWS中的简单CI / CD容器
我正在使用AWS Code Pipeline和Code Build创建一个新的Docker容器并将其推送到ECR。 我的应用程序是一个基于简单直接的单一容器的应用程序。减少当前运行中的Container并从ECS注册表中重新启动新Container(通过Code Pipeline生成Code Build)的摩擦会更少。 我尝试了使用EC2用户数据的CloudFormation,一侧的自定义脚本以及另一侧的ECS和任务定义的CloudFormation(尚未成功)。我强烈认为必须有更明显,更简单的方法。

2
如何跟踪我的云资源使用情况?
我正在尝试使用Jenkins自动化我的AWS应用程序部署。 现在,如果要在任何环境(例如UAT)中更新应用程序,我们将构建docker映像,找到当前的ECS任务,并使用新映像进行更新,找到正在运行的ECS集群,然后更新任务。 广义上讲,在持续集成环境中跟踪云资源ID(ECS群集ID,ECS任务ID,EC2 ID等)的最佳实践是什么?

2
多个iOS项目的持续集成基础架构
作为iOS开发人员,我一直在为迄今为止我们正在开发的iOS项目创建CI和CCQ(=连续代码质量)基础架构。我们已经将Jenkins和SonarQube用于几乎所有的Web和Android项目(使用VM foreach项目,自动安装和配置CI和CCQ),并且效果很好。但是对于iOS项目,Jenkins需要在运行macOS的计算机上进行构建,因此我不确定是否有完美的解决方案。 我正在寻找一种虚拟化macOS的解决方案。对于每个项目,要创建一个虚拟macOS并将Jenkins作为从站安装在那里,以处理构建。该解决方案看起来很完美,但似乎不合法的是要在macOS上运行两个以上的VM(当然,仅在Mac计算机上) http://images.apple.com/legal/sla/docs/macOS1012.pdf ->点2.B。所以这不是我的情况的解决方案。 我读过的另一种常见解决方案是有一台Mac计算机(也许是MacMini),它将处理所有项目的所有构建。您如何看待这种实施方式?它可以处理多少个项目?开发人员可能需要在自己的项目上进行一些配置(尤其是在SonarQube中),是否安全? 我们可以在同一台计算机上使用不同端口使用多个Jenkins和SonarQube实例吗?这甚至是要考虑的解决方案,还是我在胡说八道? 还有其他可行的解决方案,也许比上面的解决方案更好:)吗? 注意:我不坚持使用Jenkins + SonarQube组合,如果还有其他更适合iOS开发的工具,请与我分享。


1
将Travis-CI与核心PHP项目集成时出现问题[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,使它成为DevOps Stack Exchange 的主题。 3年前关闭。 我试图将用核心PHP编码的项目与Travis-CI集成在一起,但始终失败。 即使我的项目中只有一个文件,Travis也会报告失败。 PHP文件代码: <?php phpinfo(); ?> .travis.yml 文件码 language: php php: - '5.4' - '5.5' - '5.6' - '7.0' - '7.1' - hhvm - nightly

1
Elastic Beanstalk是否适合企业级CD?
我正在与一个使用Jenkins来构建微服务并将其部署到Elastic Beanstalk的项目一起工作。我们将集成分支部署到测试环境,将分支发布到暂存环境,然后将最终主版本构建到生产环境。我这样做有两个问题:首先,这意味着我们最终得到一个矩阵,该矩阵是每个项目每个环境一个构建的矩阵,需要重复的工作;第二,这意味着我们不会在生产中部署经过阶段验证的相同构建工件。 我倾向于放弃Beanstalk,而使用诸如Chef之类的东西迁移到普通的ASG。这将使我们每个项目只有一个构建,生成一个构建工件,并且我们可以将相同的工件部署到阶段中批准的生产中。但是,过渡的前期成本并不微不足道。有什么方法可以更好地使用Beanstalk,从而使CI / CD更可靠,更易于管理? 注意:推广相同的构建工件正是我想要做的,但是从文档中我看不到任何明确的方法;它说明了如何从您的应用程序源部署到EB,但没有说明如何将现有版本升级到另一个环境,除非我设法向右滚动。如果它可以在EB本身中使用,则Jenkins EB部署插件中可能会有一个限制,使其无法专门在Jenkins中完成,但是我还没有找到实现它的方法。

3
Docker标签版本控制的最佳做法是什么?
我最近将我们的CI服务器挂接到git commit上,以构建docker映像。 我们构建了大约8个不同的容器,每个容器都有自己的语言/框架。一些是节点并具有package.json,其他一些是不包含语义版本信息的python服务。 我的问题不是关于如何创建标签,而是关于创建标签的值。 如何确保每个标签对特定图像都有唯一的语义版本号?谁应该是跟踪/增加构建版本的权威?


5
有没有CI工具可以保证分支质量不会下降?
传统上,CI系统仅通过对已提交更改的代码库执行QA验证,监视回归并发送人工干预通知,来对集成分支中的质量级别进行监视。 但是,当检测到这些回归时,分支机构至少在各自的QA验证开始后就已经陷入麻烦,并且将一直处于这种状态(甚至变得更糟!),直到所有罪魁祸首被发现,对其进行了修复并进行了新的QA验证确认分支质量级别已恢复。在所有这些时间里,分支可以被视为正常开发被阻塞。 是否有一个CI工具能够实际防止这种回归的发生,该工具将执行提交前的 QA验证,并且仅当使用相应提交更新的代码库也将通过那些提交前的QA验证时才允许提交。分公司质量水平? 更新:假设CI工具可以调用具有适当覆盖范围的适当的自动QA验证,以能够检测相应的回归。

3
是否在美国托管了iOS版CI / CD?
TL; DR:您是否知道iOS的托管CI / CD提供商,它们的数据中心/构建盒位于亚洲或至少在欧洲?(如果他们提供构建和部署,则奖励点,但是构建是MVP。) 幕后故事: 我们正在针对iOS和Android大规模运行CI / CD:我们同时运行10多个版本,以测试/验证我们的Merge-Request分支,并将主干版本部署到测试人员和涉众。我们正在使用我们非常满意的SaaS /云提供商...除了它们的位置。 我们在亚洲,正如我们的消息来源一样。客户处于一个受到严格监管的行业中,并且为使源保持在本地状态而进行了艰苦的努力,因为他们认为他们的监管者尚无法处理云中的源。请接受这个前提。我了解为什么他们需要放手。但是现在……假设他们做不到。 这意味着:来源在亚洲,但是构建它的CI / CD提供者似乎都在美国(Circle,Buddybuild等)。跨太平洋的带宽很低,尤其是在亚洲工作日。在大多数工作日中,每个克隆在每次构建之前花费的时间会超过60分钟。 对于CI / CD而言,在docker容器上进行Android构建非常容易。但是iOS是问题所在。您要么需要自己去教别人管理OSX并保持大量的构建盒正常运转,要么需要让专家为您解决该问题。 笔记: 我不是在寻求建议,SE社区!这是一个实际的技术问题:在特定的地理位置是否提供满足某些技术要求的某些服务? 我们知道MacStadium可以在爱尔兰提供裸MacOS VM。但这意味着您必须管理自己的整个CI流程,以及我们宁愿避免的许多低级系统管理任务。当然,这也意味着将构建与部署分开。但是延迟似乎是可以接受的。 我们知道其他人拥有更接近我们的云CI / CD平台...但是没有iOS / MacOS支持。 我们知道浅层克隆需要较少的带宽,这可以缓解问题,但是它们还具有其他复杂性,这意味着我们当前的提供商尚不支持它。而且它们在任何情况下都不能完全解决问题。 我们已经尝试过使用非本地GitHub镜像,该镜像解决了一些问题,但没有解决监管问题。它也不适用于许多Webhook,特别是对于我们的CI管道中的新代码至关重要的Merge-Request Webhook。我们可以创建一个代理来监视webhooks,然后将API命令强制中继给其他服务提供者...但这确实是一个难题,而且我们还创建了许多新代码来维护。
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.