Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
103 lines (57 sloc) 5.67 KB

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.