DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。
—维基百科
1、以前我们从需求–>设计–>实现–>测试–>发布的过程都是使用的瀑布模型,造成频繁发布,程序的包也比较大,给运维带来了很大的工作量。
2、开发研发出新功能后,告知运维上线,但运维不想频繁的上线,以免导致系统不稳定,研发改动的内容不会告知运维,导致出错后,又在互相扯皮
3、以前需要投入大量人员的密集型开发和维护体系已经走不下去了,多年保留下来的技术也已经没有办法支撑和满足公司的转型和升级。
支持开发和运维之间的紧密合作,迅速而高质量的满足商业需求
⽬前,在⾼速竞争的市场,如何快速地把应⽤推出,如何快速地交付新的服务,成为IT不可避免的问题。那么,⼀套增强开发及运维之间的集成,协作及沟通的⽅法是很有必要的。⽽DevOps恰巧就能协助各个企业解决这个问题,快速地把应⽤交付出来。
当实现整个DevOps的交付过程当中,必须要确保流程的变⾰、新式⼯具的推⼴、或者新⼯作流程推⼴的时候是不影响安全性,应⽤的兼容性,以及应⽤的性能,这是DevOps所需要带来的⼀个价值。
但其实DevOps的最终目标是要实现持续集成。
代码部署频率提高46倍,变更前置时间快2555倍,变更失败率降低7倍,故障恢复时间快2604倍。
透明化设计、开发、测试、运维过程、缩短开发周期时间和提高测试的效率和部署频率
将流程标准化,将软件开发、部署过程中配置、脚本、操作规范化,提升工作的可持续性和可扩展性。
缩短客户反馈时间,提高可用性、提高变更成功率,减少故障。
减少冗余重复工作,提高效率,将有限时间花在更有价值的工作上,提高公司的整体战斗力。
记得当时最开始的时候,都是我们自己写脚本实现半自动化的部署功能,启动服务,一直监控某一文件夹大小是否大于20M,当文件夹大小大于20M时,则把旧文件夹的部署包备份并删除,停止旧的程序。启动新的程序。
后来随着一些持续集成工具被研发出来,可以实现自动部署,其中Jenkins的使用比较频繁。
Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具,起源于Hudson(Hudson是商用的),主要用于持续、自动的构建/测试软件项目、监控外部任务的运行(这个比较抽象,暂且写上,不做解释)。Jenkins用Java语言编写,可在Tomcat等流行的servlet容器中运行,也可独立运行。
通常与版本管理工具(SCM)、构建工具结合使用;常用的版本控制工具有SVN、GIT,构建工具有Maven、Ant、Gradle。
GitLab 是一个用于仓库管理系统的开源项目,使用Git作为代码管理工具,并在此基础上搭建起来的Web服务,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。
开源免费,社区免费版本适合中小型公司;
差异化的版本管理,离线同步以及强大分支管理功能;
便捷的GUI操作界面以及强大账户权限管理功能;
集成度很高,能够集成绝大多数的开发工具;
支持内置HA,保证在高并发下仍旧实现高可用性。
Jenkins的工作流程大概分为以下几步:
开发者将新版本push到git server (Gitlab)。
Gitlab随后触发jenkins master结点进行一次build。(通过web hook或者定时检测)
jenkins master结点将这个build任务分配给若干个注册的slave结点中的一个,这个slave结点根据一个事先设置好的脚本进行build。这个脚本可以做的事情很多,比如编译,测试,生成测试报告等等。这些原本需要手动完成的任务都可以交给jenkins来做。
我们在build中要进行编译,这里使用了分布式编译器distcc来加快编译速度。
jenkins的工作原理是先将源代码从gitlab中拷贝一份到本地,然后根据设置的脚本进行build。我们可以看出,整个系统的关键就是那个build脚本,用来告诉jenkins在一次集成中需要执行的任务。
不过我之后是用的Github作为git server。但其实差不多,先讲到这里,重点难点还是在之后jenkins的安装配置使用上。(后期会出专题)