DevOps
DevOps copied to clipboard
DevOps实践总结
DevOps实践总结
-
版本控制&协作开发:Git命令操作、Gitlab、GitFlow工作流
-
自动化构建和测试:Maven、Gradle、Node、Cocoapods
-
持续集成&交付:Gitlab-CI,后期可以拓展到Jenkins
-
容器平台:Docker、Ubuntu、CenterOS、Debian
后续要做的计划:
-
监控、警告&分析:zabbix
-
日志管理:syslog —> LogStash
-
配置管理等
-
1.代码仓库
-
以Git工具实现的团队内部代码共享仓库
-
分支保护和权限控制,可轻松地管理和审查成员代码;
-
详细的数据统计,清晰了解团队成员的贡献和提交情况;
-
-
2.编译构建
-
提供的通用构建环境将源代码打包成产品
-
通过脚本命令完成代码编译,生成最终产品
-
无论docker镜像、APK、Jar包都会有被永久保存到服务器,提供随时下载
-
提交代码即可自动完成构建,实现快速迭代
-
-
3.产品版本
-
构建后的产品将依据项目类型而储存在不同的仓库中
-
不限量存放产品历史版本,无视服务器环境之间的差异一键部署;
-
-
4.部署管理
-
推荐Docker技术,自动将应用部署到服务器
-
原来需要几个小时才能部署一次,现在只需要几分钟进行简单配置即可完成一次部署;
-
只需要提交代码,稍等几分钟即可完成一次版本迭代;
-
-
5.集群管理
-
基于Kubernetes集群技术轻松管理数千台服务器
-
部署环境安全隔离,可在同一集群部署多个应用;
-
同时管理多台服务器,同时监控每一台服务器;
-
分布式处理、负载均衡、服务器状态、应用状态数据集中在一起,轻松查看和管理每一台服务器;
-
Workflow(工作流)
-
master分支只用来做合并,合并来自develop分支的内容,测试通过会把develop分支内容合并到master分支上
-
运维每次从master分支取出来最新版本做部署
-
开发人员每次都从develop分支检出feature**(功能)**分支做开发,开发完成以后提交MR(Merge Request 相当于Github的Pull Request),开发组长review code之后合并入develop分支,开发人员删除该feature分支,当有新的功能需求时,重复做上述工作:
新功能需求到来——>检出feature分支 ——> 开发——>完成后提交MR——>组长review code——>合并入develop分支——> 开发人员删除feature分支
-
开发组长push到develop分支后开始由自动化任务做构建,(单元)测试等工作,这一过程一直循坏持续,直到功能开发完成,也称为持续集成(Continuous Integration):它强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
-
发布测试版本:根据产品人员那边进度来安排测试版本发布,发布工作由各开发组长执行,打tag标签
git tag v1.0.1 如有必要可加上构建次数,如:v1.0.0.1 其中最后一位作为构建版本,递增
版本的五个阶段(Base、Alpha、Beta、RC、Release):
Base:此版本表示该软件仅仅是一个假页面链接,通常包括所有的功能和页面布局,但是页面中的功能都没有做完整的实现,只是做为整体网站的一个基础架构。
Alpha :软件的初级版本,表示该软件在此阶段以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的Bug较多,需要继续修改,是测试版本。测试 人员提交Bug经开发人员修改确认之后,发布到测试网址让测试人员测试,此时可将软件版本标注为alpha版。
Beta :该版本相对于Alpha 版已经有了很大的进步,消除了严重错误,但还需要经过多次 测试来进一步消除,此版本主要的修改对象是软件的UI。修改的的Bug 经测试人 员测试确认后可发布到外网上,此时可将软件版本标注为 beta版。
RC :该版本已经相当成熟了,基本上不存在导致错误的Bug,与即将发行的正式版本相差无几。
Release:该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式的版本,是最终交付用户使用的一个版本。该版本有时也称标准版。
-
部署测试服务器也由自动化任务来做,触发这一动作的指令,即为我们的打版本命令,这个过程一直循环迭代直到测试完成,也称为持续交付(Continuous Delivery):它是在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中或者说是测试环境中去。
-
测试完成后,即进入版本的Beta阶段,发布外网,针对开发组长要做的工作就是,把版本合并入master分支,由运维人员从master分支上取出该版本部署,这过程一直持续下去,即为版本迭代;如果我们将整个运维发布 过程也交由自动化任务来做,那就是持续部署(Continuous Deployment):它是在持续交付的基础上,把产品部署到生产环境的过程自动化。
-
后续的工作就是我们一直不断的修复,迭代版本,将版本阶段从RC阶段过渡到Release阶段的过程。