Devops 的介绍
一:DevOps 是什么DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快..
一:DevOps 是什么
DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。
DevOps试图通过发展开发和运营团队之间的伙伴关系,弥合这条鸿沟。DevOps活动强调软件开发人员和IT运营部门之间的沟通、协作和整合。
DevOps促进协作,通过自动化和编排改善过程为协作提供方便。换言之,DevOps本质上将敏捷活动的持续开发目标扩展到持续集成和发行。DevOps是利用云解决方案的优势,将敏捷实践与过程组合起来。敏捷开发和测试方法帮助我们实现应用程序的持续集成、开发、构建、部署、测试和发行目标。
构建自动化
自动化构建运用Gradle、Apache Ant和Apache Maven等构建自动化工具,帮助我们创建应用程序构建。
自动化构建过程包括将源代码编译成类文件或者二进制文件、提供第三方库文件引用、提供配置文件路径、将类文件或者二进制文件打包成包文件、执行自动化测试用例、在本地或远程机器上部署包文件和减少包文件创建中的手工作业等活动。
持续集成
简言之,持续集成(CI)是一种软件工程实践,在这种方法中,开发人员的每次签入(Check-in)都使用如下任一种方法验证。
“拉”机制:在计划的时间点执行自动化构建。
“推”机制:在存储库中保存更改时执行自动化构建。
这一步之后,对源代码库中最新的更改执行一次单元测试。持续集成是一种流行的DevOps方法,要求开发人员将代码每天数次整合为Git和SVN等代码库,以验证代码的完整性。
然后,自动化构建验证每次签入,使团队可以及早发现问题。
CI(甚至CD)是公司同步DevOps存档的基线。在组织中如果没有很好地实施CI和CD,就无法实施DevOps。
云配给
在本章前面,我们已经介绍了云计算的基本知识。云配给为架构即代码(Infrastructure as Code ,IAC)敞开了大门,使整个过程变得极其高效,因为我们在很大的程度上将涉及人工干预的过程自动化了。
现收现付的计费模式使所需的资源更加容易承受,不仅对大型组织,对中小规模组织和个人也是如此。
云配给有助于改进和创新,因为以前的资源约束从成本和维护的角度阻碍了组织的进一步发展。一旦我们在基础设施资源上拥有了敏捷性,就可以考虑自动化运行应用程序所需软件包的安装和配置。
配置管理
配置管理(CM)系统中的更改,更具体地说,就是服务器运行时环境。我们可以使用市场上的许多工具实现配置管理。流行工具包括Chef、Puppet、Ansible、Salt等。
让我们来考虑一个需要管理多个同类配置服务器的例子。
例如,我们需要在每个服务器上安装Tomcat。如果需要改变所有服务器上的端口、更新某些软件包或者为某些用户提供权限,该怎么办?这种情形下的任何修改都是人工的,也就是一种容易出错的过程。因为所有服务器都使用相同的配置,可以利用自动化手段。
持续交付
持续交付和持续部署是可以互换使用的术语。但是,两者之间还是有一些小的差别。
持续交付是在任何环境中以自动化方式部署一个应用程序并提供持续反馈以改善其质量的过程。持续交付和持续部署中的自动化方法不会改变。但是批准过程和其他小细节可能改变。
持续测试和部署
持续测试是端到端应用程序生命期管理过程中很重要的阶段,包括功能测试、性能测试、安全性测试等。
Selenium、Appium、Apache JMeter和许多其他工具都可以用于相同的目的。另一方面,持续部署是部署应用程序,包含对生产环境的最新更改。
持续监控
持续监控是端到端交付流水线的骨干,开源监控工具就像冰淇淋勺的头部。
我们必须理解,这是一种分阶段的方法,不一定要一次性完成各个阶段的自动化工作。每次选择一种DevOps实践、实施并理解其好处,然后再实施另一个,这是更有效的做法。
这样,我们可以安全地评估组织文化改变带来的改善,消除应用程序生命期管理中的手工劳动。
二:DevOps 常用的工具
- 代码管理(SCM):GitHub、GitLab、BitBucket、SubVersion
- 构建工具:Ant、Gradle、maven
- 自动部署:Capistrano、CodeDeploy
- 持续集成(CI):Bamboo、Hudson、Jenkins
- 配置管理:Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
- 容器:Docker、LXC、第三方厂商如AWS
- 编排:Kubernetes、Core、Apache Mesos、DC/OS
- 服务注册与发现:Zookeeper、etcd、Consul
- 脚本语言:python、ruby、shell
- 日志管理:ELK、Logentries
- 系统监控:Datadog、Graphite、Icinga、Nagios
- 性能监控:AppDynamics、New Relic、Splunk
- 压力测试:JMeter、Blaze Meter、loader.io
- 预警:PagerDuty、pingdom、厂商自带如AWS SNS
- HTTP加速器:Varnish
- 消息总线:ActiveMQ、SQS
- 应用服务器:Tomcat、JBoss
- Web服务器:Apache、Nginx、IIS
- 数据库:MySQL、Oracle、PostgreSQL等关系型数据库;cassandra、mongoDB、redis等NoSQL数据库
- 项目管理(PM):Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker
对于其他工具可自行查阅,符合的才是最好的
三:需求层面上来说敏捷和瀑布差异
瀑布:一次性把需求提完,这样在开发过程中会存有些地方可能没想到,在客户使用过程中会有很多感觉不好用,开发的软件达不到预想的效果。
敏捷:一小部分完成,投入使用,预估效果和收益。以滴滴平台为例,先开展出租车业务(先看市场反应和收益效果)在开展顺风车,网约车等业务,让客户慢慢的接受产品,如果一次性开展所有业务,到会让使用者感觉乱,不知道如何使用。
备注:敏捷模型,会要求业务员和开发人员一起工作和沟通。
更多推荐
所有评论(0)