https://github.com/yuxingxin/devops

DevOps实践总结
https://github.com/yuxingxin/devops

devops git gitflow gitlab gitlab-ci gitlab-runner

Last synced: 6 days ago
JSON representation

DevOps实践总结

• Host: GitHub
• URL: https://github.com/yuxingxin/devops
• Owner: yuxingxin
• Created: 2017-09-14T08:49:08.000Z (over 7 years ago)
• Default Branch: master
• Last Pushed: 2022-08-04T11:26:41.000Z (over 2 years ago)
• Last Synced: 2025-04-04T05:51:09.081Z (28 days ago)
• Topics: devops, git, gitflow, gitlab, gitlab-ci, gitlab-runner
• Homepage: https://devops.yuxingxin.com/
• Size: 836 KB
• Stars: 15
• Watchers: 2
• Forks: 5
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# DevOps实践总结

* **版本控制&协作开发**：Git命令操作、Gitlab、GitFlow工作流

* **自动化构建和测试**：Maven、Gradle、Node、Cocoapods

* **持续集成&交付**：Gitlab-CI，后期可以拓展到**Jenkins**

* **容器平台**：Docker、Ubuntu、CenterOS、Debian

  后续要做的计划：

* 监控、警告&分析：zabbix

* 日志管理：syslog —> LogStash

* 配置管理等![](https://ws3.sinaimg.cn/large/006tNc79ly1fjj3mmpqhvj31kw0zkatq.jpg)

* 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分支

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

   ![](https://ws3.sinaimg.cn/large/006tNc79ly1fjnpyome2kj30go07cdgf.jpg)

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

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

   ![](https://ws4.sinaimg.cn/large/006tNc79ly1fjnpzejypuj30go0ccmyh.jpg)

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

   ![](https://ws4.sinaimg.cn/large/006tNc79ly1fjnpzn1o6hj30go0ccq48.jpg)

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