个推持续集成最佳实践

软件开发过程中,开发成员经常需要把自己工作集成到项目中,通常每个成员每天至少集成一次。如果项目较小,对外部的依赖较小,那么软件集成可能不会是什么问题。但是目前很多软件项目特别是互联网项目面临着需求不明确,系统架构复杂,任务分配混乱等一系列问题,从而给持续集成带来许多麻烦。也给整个项目带来不必要的风险。因此一个有效的持续集成系统越来越重要。

个推平台是一个极其复杂的分布式系统,整个系统包含了 RPC 调用,高速缓存,集群同步等各种复杂的场景。整个团队只有二十来个人却维护了近百个模块的开发和测试工作,如果没有一套有效的机制,很难想象如何完成这些任务。持续集成在其中扮演了非常重要的角色,借助于 Git、Docker、Jenkins 以及 Nexus 等工具,我们搭建了自己的持续集成环境,并一步一步的摸索出了自己的最佳实践,这篇文章将会和大家一起分享我们是如何利用这些技术提高团队的生产力的。

个推持续集成系统的组成

使用git作为版本控制库
相比于同类项目版本系统,git有一项非常显著的优势,就是版本分支(branch)的合并(merge)十分方便。
使用docker搭建测试环境
作为一种新型的虚拟化方式,相对于传统的虚拟化方式有着众多的优势。例如,docker虚拟容器的启动可以在秒级实现,并且对系统资源的利用率很高。另外,docker的管理,迁移和扩展也更轻松有效。
使用jenkins作为持续集成服务器
Jenkins为开发人员提供了非常有效的持续集管理。其强大的插件系统和明确的构建逻辑,使得构建流程的创建非常简便。

Docker在持续集成系统中的作用

测试作为软件项目重要的一环,一般都需要开发团队搭建一套独立的测试系统。但作为持续集成的一个环节,此测试系统又异于一般的测试系统。主要原因为,持续集成测试系统主要用来做回归测试,而且需要支持快速大量的代码升级。基于docker的特性,以及持续集成的需求,个推采用docker为持续集成搭建了一整套测试系统。

镜像准备:docker 的运行基于镜像文件,而每个项目所需的镜像文件又不同。因此需要独立分析每个项目的需求以及未来扩展需要,创建出不同版本的镜像文件。目前,个推主要有4大类镜像,分别支持前端,后端,工具类等项目。以前端为例,个推采用了前后端分离的开发模式,因此此镜像主要用来支持web 前端的服务运行。

服务包准备:为了能在docker里运行所需要的服务,需要docker实例中安装相应的服务包(service package)。 一般有两种方法,一种是将相应的服务包在镜像文件中安装,另一种以docker 卷的形式动态映射到docker实例。 两种方式有其优劣,第一种方式使得每次docker 容器的启动非常迅捷,而第二种方式则更为灵活。这个需要根据不同的需求选择合适的方式。
下图为docker 在整个持续集成系统中的作用。Jenkins 作为主服务器将代码和docker 统一的管理起来。

个推持续集成流程

下面以user模块为例,对持续集成的流程进行阐述,如下图所示:

从图中可以看出,我们系统的git分支包括dev,master两个分支:

dev:开发分支,开发人员维护,开发人员将最新代码提交到这个分支,Jekins监视这个分支,任何代码改变都会触发自动化测试
master:发布分支,这个分支上的版本是自动化测试通过后的版本,且自动化打包监控这个分支

图中的每个长方形代表一个Jenkins Job。下面将对每个Job进行说明:
? user: 监控user代码库的dev分支,当每次有新的代码提交时,就会自动触发构建任务。编译代码,同时生成code style,测试覆盖率等关于代码质量的报表。成功后将触发user-docker任务。
? user-docker: 打包user工程,重启user的docker实例以便于使用全新的user包。成功后将触发testcase任务
? testcase: 验收测试,检测改变是否满足业务需求所定义的验收条件。成功后将触发marge任务
? merge:将user的dev分支merge到master分支
? user-pkg: 监控user代码库的master分支,当有代码改变时,执行mvn package打包操作
经过上面的几个步骤,从代码提交到打包的整个过程就自动化起来了。

总结

目前越来越多的公司开始重视持续集成系统,但是缺乏定制化的系统真的能满足复杂的需求吗?当模块之间的联系越来越复杂,集成的频率越来越大,运行环境的不断升级 等等,缺乏定制的持续集成系统是否能达到预期,个推在docker 上找到了解决方案。 虽然仍然有许多挑战,但随着技术的升级和完善,我们终会越做越好。

原文地址:http://blog.51cto.com/13031991/2108082

时间: 2024-11-04 04:00:30

个推持续集成最佳实践的相关文章

解密个推持续集成

软件开发过程中,开发成员经常需要把自己工作集成到项目中,通常每个成员每天至少集成一次.如果项目较小,对外部的依赖较小,那么软件集成可能不会是什么问题.但是目前很多软件项目特别是互联网项目面临着需求不明确,系统架构复杂,任务分配混乱等一系列问题,从而给持续集成带来许多麻烦.也给整个项目带来不必要的风险.因此一个有效的持续集成系统越来越重要. 个推平台是一个极其复杂的分布式系统,整个系统包含了 RPC 调用,高速缓存,集群同步等各种复杂的场景.整个团队只有二十来个人却维护了近百个模块的开发和测试工作

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

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

一个Web 持续集成工作实践

一个web的持续基础实践: https://mp.weixin.qq.com/src=3&timestamp=1494325174&ver=1&signature=wFVC0E6YlKsNsCYnhs8XlMdRTmtwBU8qMW4YCsNoryvcIAGD8hPCnOCaXb5WisyGrmEOVUJVd1n2FRjV3ohyUWuTDUGMGhkDPXAlvd6t0RtNSivqrMRgof1KJcnZrAvzTYkjURSzDPjk8wR5vq8ASUOarm9mFlUad

来自京东、唯品会对微服务编排、API网关、持续集成的实践分享(上)

架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享. 第三期:微服务.微服务架构以其高度的弹性.灵活性和效率的巨大提升,快速受到各领域架构师和技术决策者的关注.它的基本理念是将一个肥大的系统拆分成若干小的服务组件,组件之间的通讯采用轻量的协议完成.我们本期小组交流会来探讨一下,现在互联网公司的微服务实践情况. 嘉宾:京东章耿.原唯品会石廷鑫.七牛陈爱珍 本文是对此次交流的整理,分了上下两篇文章. 第一轮:自由交流 京东章耿:大家好,我是京东基础架构部平台中间件的章耿,主要负责京东的

Linux-GitLab+Jenkins持续集成+自动化部署

GitLab+Jenkins持续集成+自动化部署 什么是持续集成? (1)Continuous integration (CI) 持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译.发布.自动化测试)来验证,从而尽快地发现集成错误.许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件. (2)没有持续集成 项目做模块集成的时候,发现很多接口都不通==>浪费大量时间 需

【持续集成】GIT+jenkins+snoar——jenkins发布php、maven项目

一.持续集成 1.1 什么是持续集成? continuous integration (CI),持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员,每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化构建(包括编译.发布.自动化测试)来验证,从而尽快的发现集成错误.许多团队发现这个过程可以大大减少集成的问题,让团队能够更快的开发内聚的软件. 1.2 持续集成最佳实践 维护一个单一的代码库 使构建自动化 执行测试是构建的一部分 集成日志及历史记录 使用统

Maven实战(四)——基于Maven的持续集成实践

Martin的<持续集成> 相信非常多读者和我一样.最早接触到持续集成的概念是来自Martin的著名文章<持续集成>.该文最早公布于2000年9月,之后在2006年进行了一次修订.它清晰地解释了持续集成的概念.并总结了10条实践,它们分别为: 仅仅维护一个源代码仓库 自己主动化构建 让构建自行測试 每人每天向主干提交代码 每次提交都应在持续集成机器上构建主干 保持高速的构建 在模拟生产环境中測试 让每一个人都能轻易获得最新的可运行文件 每一个人都能看到进度 自己主动化部署 原始文章

《.NET最佳实践》与Ext JS/Touch的团队开发

概述 有不少开发人员都问过我,Ext JS/Touch是否支持团队开发?对于这个问题,我可以毫不犹豫的回答:支持.原因是在Sencha官网博客中客户示例中,有不少项目都是基于团队模式开发的. 那为什么会出现这个问题?我觉得问题的关键在于不知道如何去进行模块独立调试或做最终的整合.对于这个问题,我觉得<.NET最佳实践>这本书(下 文中简称为实践一书)或许会给大家带来一点启示.虽然这本书是针对.NET而写的,但我觉得,这对于Ext JS/Touch,甚至于其他开发语言的开发,还是有不错的借鉴意义

[首发]国内某大型银行的持续集成与交付实践

一.背景 随着架构的不断演进以及微服务技术在我行的深入应用,应用部署发布的复杂性大大增加,简单的代码配置管理模式.人工的版本记录及手工部署等发布操作和管理的模式,效率低.操作风险较大,因此急需从整体上提升我行软件持续交付的能力,降低应用部署发布的操作风险.通过引入构建自动化及可视化的软件交付流水线,整合从开发.构建.测试.部署.发布.运维等多个环节,加强各职能团队协助和沟通,全面实现项目构建持续自动化管理. 二.实施方法 1. 总体架构 DevOps是一组能够帮助软件开发团队极大的提高其软件交付