Skip to content
DevOps实践总结
Branch: master
Clone or download
Latest commit 6c67f85 May 21, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
chapter1 Update basic pics May 21, 2019
chapter2 修改图片地址 Sep 18, 2017
chapter3 Track 2 files into repository. Sep 14, 2017
chapter4 修改图片地址 Sep 18, 2017
.gitignore Track 2 files into repository. Dec 24, 2017
README.md 修改图片地址 Sep 18, 2017
SUMMARY.md Track 2 files into repository. Dec 24, 2017
book.json add disqus Sep 14, 2017
config.json add disqus Sep 14, 2017

README.md

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(工作流)

  1. master分支只用来做合并,合并来自develop分支的内容,测试通过会把develop分支内容合并到master分支上

  2. 运维每次从master分支取出来最新版本做部署

  3. 开发人员每次都从develop分支检出feature**(功能)**分支做开发,开发完成以后提交MR(Merge Request 相当于Github的Pull Request),开发组长review code之后合并入develop分支,开发人员删除该feature分支,当有新的功能需求时,重复做上述工作:

新功能需求到来——>检出feature分支 ——> 开发——>完成后提交MR——>组长review code——>合并入develop分支——> 开发人员删除feature分支

  1. 开发组长push到develop分支后开始由自动化任务做构建,(单元)测试等工作,这一过程一直循坏持续,直到功能开发完成,也称为持续集成(Continuous Integration):它强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。

  2. 发布测试版本:根据产品人员那边进度来安排测试版本发布,发布工作由各开发组长执行,打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:该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式的版本,是最终交付用户使用的一个版本。该版本有时也称标准版。

  3. 部署测试服务器也由自动化任务来做,触发这一动作的指令,即为我们的打版本命令,这个过程一直循环迭代直到测试完成,也称为持续交付(Continuous Delivery):它是在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中或者说是测试环境中去。

  4. 测试完成后,即进入版本的Beta阶段,发布外网,针对开发组长要做的工作就是,把版本合并入master分支,由运维人员从master分支上取出该版本部署,这过程一直持续下去,即为版本迭代;如果我们将整个运维发布 过程也交由自动化任务来做,那就是持续部署(Continuous Deployment):它是在持续交付的基础上,把产品部署到生产环境的过程自动化。

  5. 后续的工作就是我们一直不断的修复,迭代版本,将版本阶段从RC阶段过渡到Release阶段的过程。

You can’t perform that action at this time.