Jenkins构建常见问题
-
项目构建失败常见原因
-
原因一：连接SVN失败
- 检查 Jenkins环境是否能够连接到 svn
-
原因二：SVN更新代码冲突
- 检查 项目空间里是否存在 SVN 冲突文件
-
原因三：shell脚本错误
- 检查 Jenkins项目配置里的shell脚本是否存在错误
-
原因四：项目编译失败
-
iOS项目：检查编译日志。（注：编译日志等同于XCode的编译日志）
-
代码编译错误 -
开发者证书配置错误
-
-
android项目：检查编译日志。（注：编译日志等同于Android Studio的编译日志）
-
代码编译错误 -
网络下载jar包错误
-
-
-
持续集成－反模式
-
[x] 不频繁的或充满缺陷的部署
-
问题
- 花很长时间部署某个构建版本，而且部署过程很脆弱。
-
症状
-
测试人员花很长时间才能将缺陷记录关闭。注意，这个症状可能并不是完全由不频繁的部署导致的，但它是可能的原因之一。
-
对用户故事的测试或者被客户验收需要花很长时间。
-
测试人员正在找的bug是开发人员很长时间之前修复的
-
没有人信任UAT、性能或持续集成环境，当某个版本发布将要发布时，人们仍旧表示怀疑。
-
很少做演示。
-
应用程序很少被证明是可以工作的。
-
团队的进度比预期的慢。
-
-
可能原因（常见的一些原因）
-
部署过程是非自动化的。
-
没有足够的硬件。
-
硬件和操作系统的配置没有被正确地管理。
-
部署过程依赖于团队无法掌控的系统。
-
没有足够多的人员理解构建和部署过程。
-
测试人员、开发人员、分析人员和运营人员在开发期间没有充分协作。
-
开发人员没有遵守纪律，通过小步增量方式的修改保证应用程序一直处于可工作状态，因此经常破坏原有功能。
-
-
-
较差的应用程序质量
-
问题
- 交付团队无法实施有效的测试策略。
-
症状
-
总出现回归bug。
-
缺陷数量持续增长，即使团队花很多时间修复它们（当然，这个症状只是表明你是否有一个有效的测试过程）。
-
客户抱怨产品质量低。
-
无论什么时候接到一个新的功能需求，开发人员都抱怨，看上去很害怕。
-
开发人员总是抱怨代码的可维护性，但却一直没有变好。
-
实现新功能的时间逐渐变长，并且团队进度开始落后。
-
-
可能原因（本质上说，这个问题有两个源头：测试人员与交付团队的其他成员的协作不畅以及自动化测试写得很差，或者不充分）
-
在特性的开发期间，测试人员没有与开发人员协作。
-
用户故事或特性被标记为“完成”，但没有写全面的自动化测试，也没有测试人员的验收，或者没有在类生产环境上给用户演示。
-
没有立刻修复已发现的缺陷，也没有写自动化测试用来检测回归问题，而是直接放到了待办列表中。
-
开发人员和测试人员在自动化测试套件开发方面没有足够的经验。
-
对于所用的技术或平台，团队并不了解写哪种类型的测试最有效。
-
没有足够的测试覆盖率，开发人员工作时无防护网，可能是因为他们的项目管理者没有给他们预留实现自动化测试的时间。
-
系统只是个会被放弃的原型。
-
-
-
缺乏管理的持续集成工作流程
-
问题
- 不适当的构建过程管理
-
症状
-
开发人员的签入不够频繁（应该至少一天一次）。
-
提交阶段总是处于失败状态。
-
缺陷的数量一直保持在较高水平。
-
在每次发布之前都有一个较长时间的集成阶段。
-
-
可能原因
-
自动化测试运行时间太长。
-
提交阶段运行时间太长（理想情况下应该少于5分钟，超过10分钟是无法接受的）。
-
自动化测试有间歇性失败，还是误报。
-
没人得到许可就回滚别人的提交。
-
没有足够多的人理解持续集成过程，也没有足够的人做出改变。
-
-
-
较差的配置管理
-
问题
- 环境不是专属的，应用程序无法用自动化过程可靠安装。
-
症状
-
生产环境中总是又些莫名其妙的故障。
-
每次新版本部署都是紧张且令人担心的事情。
-
一个较大的团队专门对环境进行配置和管理。
-
部署到生产环境中的版本常常不得不回滚或打补丁。
-
生产环境中无法接受的当机时间。
-
-
可能原因
-
UAT和生产环境有差异。
-
没有对生产环境或试运行环境的变更管理流程，或者变更管理流程很差。
-
在运营、数据管理团队和交付团队之间协作不畅，沟通不充分。
-
在生产环境和试运行环境中的缺陷事件的监管有效性不足。
-
应用程序中的指南和日志不充分。
-
对应用程序非功能需求的测试不充分。
-
-
网友评论