持续集成系统思考记录

1、基于ansible tower来管理测试环境机器,使用zabbix或nagios来作为进程监控和rpm一致性检查;使用任务流增加配置中心的调用来同步部署测试环境;DB如何处理?如何区分环境?

2、缺乏发布效率的数量呈现。例如 提交->发布→快速验证(测试)→运行监测数据 总共的耗时要多久,我们可否逐步降低;目前的效率很慢。如要提高效率需要重构jatsci架构,优化编译、打包、部署流程;尤其是编译效率

3、运维同学已经开始慢慢支持制作镜像,基于镜像发布。持续集成系统要如何适应;

4、提交->发布→快速验证(测试)→运行监测数据 中包含代码检测。而目测试对于代码检测一直侵入不够;snoarqube平台可以作为基础的平台来使用。结合开源c++插件以及其他插件做一个综合代码检查工具;做到一次扫描多重检查;

5、运行监测数据中目前为0;检测ui、cgi接口、后台接口、压测等各种测试的数据、以及服务器、进程的性能数据;日志异常检测等;

6、如何自动生成测试数据;

开发的测试工具得不到推广使用的原因:

对实际使用者:

1、门槛高,不好用,不够傻瓜;

2、给对方增加工作量,心理抗拒;

3、维护成本高,不想要接入;

4、效率低,使用工具与手工效率相差不大;

5、工具跑的过程中出现问题,不方便开发同学调试,难用;

6、推广成本高,推广起来需要改造现有流程,可能大部分人都是抗拒的;

7、部门墙,与其他部门的工作范围有重合。或者与对方利益有冲突;

8、没有解决对方的关键痛点

对ld:

1、没有量化、直观、可视化的效果呈现出来,方便ld们统计和使用;

2、指标非ld们实际需要的指标;

3、统计精度不够细

4、需要对异常指标作出基本判断,并给出明显的提示或建议;

原文地址:https://www.cnblogs.com/carterzhang/p/11287660.html

时间: 2024-11-08 18:23:22

持续集成系统思考记录的相关文章

建立可持续集成系统(Jenkins)

在软件工程实践中,需要将开发完成的最终产品交付给用户(或发布给测试部门),就需要我们将源代码编译为可执行文件.将各个分别开发的模块集合为一个完整的系统,这个过程成为系统集成,我们用一个系统来描述这个集成过程. 集成系统:输入指定的软件资产,输出根据软件资产生产出的软件产品以及其他副产品的系统. 对于一般系统而言(以VC开发为例),软件的生产过程包括:源码获取,源码检查,源码编译,测试,部署.经历以上几个过程之后得到一个可用的系统. 故一般而言集成系统通常会按照顺序经历以下几个模块组成: 1. 版

Jenkins自动化构建系列:01敏捷开发、自动化构建与持续集成

<SVN与TortoiseSVN实战系列>已写完,今天新开一个<Jenkins自动化构建系列>,上周听了Bob Jiang老师的Agile1001公开课,一直想写个总结,这篇关于敏捷开发.自动化构建与持续集成的思考就作为开题篇吧. 敏捷是什么? 敏捷是一把伞,这把伞下边有XP.Scrum.FDD...,当然也包括自动化构建.持续集成,其实符合敏捷思想的开发方法.工具,如Jenkins都可以属于敏捷开发的范畴,上课时的PPT: 敏捷到底是什么? 其实关于敏捷的定义有很多,Bob Ji

持续集成方案

大纲 构建 版本控制 部署 单元测试 架构文档化 命名约定 数据库伸缩性 自动化 反馈 实践 引言: 持续集成的前身: 在使用持续集成之前,很多开发团队都是用每日构建(nightly build).当时,微软使用这个实践很多年了.谁破坏了构建,就要负责监视后续的构建构成,直至发现下一个破坏了构建的人. 为什么要使用持续集成? 对于大多数项目来说,采纳持续集成实践是向高效率和高质量迈进的一大步.它保证那些创建大型复杂系统的团队具有高度的自信心和控制力.一旦代码提交引入了问题,持续集成就能为我们提供

通过静态分析和持续集成 保证代码的质量 (PRQA )2

续上.... 第二章 部署示例:Jenkins and PRQA 工具 第一节 Jenkins 作为持续集成系统 现在有很多持续集成工具,既有免费的,也有商业的.最近的研究显示,Jenkins正发展成为最受欢迎的持续集成工具.Jenkins是Hudson持续集成系统的一个分支,但是Jenkins拥有最活跃的生态系统. 在MIT许可下,Jenkins是免费的,但是和一些开源软件一样,Jenkins也有付费版本,并会提供技术支持.虽然Jenkins是一个开源项目,但是对核心代码所作的所有修改,都由核

使用Docker实现丝般顺滑的持续集成

持续集成(Continuous Integration,简称CI)作为先进的项目实践之一,近年来逐渐受到国内软件公司的重视:但对于许多朋友来说,可能从未听说过持续集成这个词,抑或只是了解概念但并没有实践过. 什么是持续集成?它对软件开发有哪些好处呢? 持续集成的概念 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题.尤其是近些年来,敏捷(Agile)在软件工程领域越来越红火,如何能在不断变化的需求中快速适应和保证软件质量也显得

持续集成之戏说Check-in Dance(转)

add by zhj: 先说一下持续集成的定义,这是ThoughtWorks首席科学家Martin Fowler在<持续集成>第二版中给出的,“持续集成是一种软件开发实践.在持续集成中,团队成员频繁集成他们的工作成果,一般每人每天至少集成一次,也可以多次.每次集成会经过自动构建(包括自动测试)的验证,以尽快发现集成错误.许多团队发现这种方法可以显著减少集成引起的问题,并可以加快团队合作软件开发的速度.” 这里是<持续集成>第二版的一些简单介绍:http://www.infoq.co

有容云老司机带路, 使用Docker实现丝般顺滑的持续集成

持续集成作为最先进的项目实践之一,近年来逐渐受到国内软件公司的重视:但对于许多朋友来说,可能从来都没有听说过持续集成这个词,抑或只是了解一个概念但并没有实践过. 什么是持续集成?它对软件开发有哪些好处呢? 持续集成的概念 持续集成,Continuous integration ,简称CI. 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题.尤其是近些年来,敏捷(Agile) 在软件工程领域越来越红火,如何能在不断变化的需求中快

在Python Web项目中使用Jenkins进行持续集成

在一个项目的开发过程中,往往会有一些需要反复执行的操作,比如编译.测试.部署.具体于Flask项目,我一般使用nose执行单元测试.fabric进行部署.pylint执行代码质量检测等.这些频繁需要执行的步骤,是非常枯燥的,那何不交给机器来自动执行呢?最近,我参与的一个校内团队也遇到了类似的问题,于是打算调研一下相关的工具. 还是习惯性地查阅了下Kenneth Reitz大神的python-guide,果然找到了关于CI的章节.选来选去,最终没有选择Python Stack的Buildbot,而

fir.im weekly - 「 持续集成 」实践教程合集

我们常看到许多团队和开发者分享他们的持续集成实践经验,本期 fir.im Weekly 收集了 iOS,Android,PHP ,NodeJS 等项目搭建持续集成的实践,以及一些国内外公司的内部持续集成系统的经验,供大家集中研究,参考借鉴. 先来看看国内外一些公司的实践经验: Continuous Deployment at Instagram Instagram 的开发团队每天保持着 30 - 50 次后端代码部署,几乎全程无人参与,完全自动化.这听起来很疯狂,但一切确实在这样运转.来这里看看