10分钟搭建最简DEVOPS实战

Posted 2021-04-16 前端面试官

10分钟搭建最简DEVOPS实战

为什么有些面试官会问 敏捷、CI、CD、DEVOPS？一般越是管理背景的面试官越容易问你这种问题，比如部门经理或者专家面，考察的点可能是【是否能快速融入团队？】【会不会做事？】【能否担起管理职责？】【知识面和学习能力？】中的一种或几种

许多文章都说devops离小公司很远，基础设施搭建都很费事，当时确实是这样的，但现在我觉得不一样了，DEVOPS的基础设施已经跟上，也可以很省事了，当然如果你不是开源项目的话还是要花点小钱购买服务的

1.需求管理与迭代规划

这种工具就多了，虽然开源项目的话还是推荐用github的issue，但是体验不是很好，所以私有项目用什么也都可以，腾讯家有TAPD阿里家有钉钉，当然了，你用什么别的只要顺手就可以

假设我们第一个迭代就一个功能，一个可以http服务，打开就显示hello world

2.开发

代码管理推荐使用github，然后代码语言就选择nodejs了，使用express框架

3.编写测试

假设我们就先跑一个测试，证明服务可以启动，http请求可以成功，用jest吧

【我启动服务，打开浏览器验证不是更简单？】

以后你总是有机会因为打错字母或者设么原因让它启动不起来的，从长远来看是省人工的，而你又不会总去手动验证，所以机器自动运行更有保障

我们定义一下启动和测试的脚本，然后运行测试

当然了现在这个程度也没有自动，接下来就看持续集成了

4.持续集成

这里推荐使用docker cloud，https://cloud.docker.com

我们要给它准备一个Dockerfile来自动化运行我们的测试

提交到github，然后打开https://cloud.docker.com，创建一个repo

然后填写信息确认创建

然后关联这个github

填写信息然后确认配置自动build

然后我们就要等待build完成了

这样以后在这个列表里就能看到最新代码是否通过了测试

5.持续部署

使用docker的很大原因就是它方便部署，要部署需要调整一下Dockerfile让它暴露端口并默认运行服务脚本

提交并回到docker cloud，编译会自动开始运行，等待编译完成后在服务节点页面

添加服务器

找一个符合要求的服务器，就临时开了个linode的Centos7登录并运行

等待添加结果

然后点击服务菜单添加服务（1），选择自己的仓库（2），选择刚刚的仓库（3）

配置端口，确定部署

经过一段时间的等待，我们的服务终于部署好了

验证可以访问

然后就可以访问页面了

总结一下

到这里，一个最简的devops就完成了，觉得整体工作效率还是会有很大提高的

- 【开发】除了测试还可以在CI的过程增加编码规范、代码异味的自动化测试，这是一劳永逸的。当不小心导致之前功能出问题的时候，机器就能在第一时间通知，人工测试可能很久之后才能测出来，开发都忘记当时改了什么了

- 【测试】只要测试覆盖到了，测试同学不用自己去盯着新版本，有了新版本系统自动就会运行。每个迭代内容独立分支，自动测试脚本可以并行编写或延后开发一个迭代编写，持续集成通过测试的迭代分支才能合入主干，不影响新特性开发，而且测试代码和开发代码一起跟着分支走，自然就是整体测试

- 【运维】运维同学可以通过网页就可以控制服务更新到最新的版本，即使出了问题回滚也通过网页即可，而且历史版本齐全，如果访问压力大了直接在云上多加服务节点即可

当然agile、CI、CD、DEVOPS每个都能提很多优点，我觉得这几个是传统开发最常见的问题，每条优点对应的，解释一下工作效率低的例子

- 不负责任的开发，每个开发完的特性测试都测出一堆bug，而且开发新特性会影响其他特性功能，导致测试同学每次测试都要全面测试。而且往往bug还要修了测，测了修来回几个回合

- 没有时间执行的测试，开发两星期，测试留1天。这样勉强的测试难保发布了不出问题，而且你是测试新开发的功能呢，还是整体测试一下？

- 运维事故发生了，没有开发解决不了，有了开发要等排查问题，加班修复，再更新代码才能恢复

私有项目怎么办呢？

github主要都是开源项目，但是创建仓库的时候是可以使用私有仓库的

每个月要花7美刀，也就是不到50元人民币

类似的docker cloud免费服务就提供一个私有仓库，如果需要更多就阶梯价格，假如你需要5个私有仓库，那和github一样7美刀/月

加起来大约每月额外花100块人民币，不到一个人力成本的十分之一，就对比这几个收益也是非常的值得的

好吧我承认标题党了，做完这些肯定不止10分钟，但是排除npm和docker编译部署等待的时间就只需要复制粘贴点代码，后台填信息提交这些操作肯定是不超过10分钟的，还有就是像我这样把测试直接放到build过程并不是标准的做法，详情参考https://docs.docker.com/docker-cloud/builds/automated-testing/ 标准做法我也还在探索中

现在来看devops是不是没那么难？当然devops并不只是这点代码，核心还是在于避免各个环节的浪费，提升交付速度，避免线上事故的思路。【原文链接】留给文中例子对应代码https://github.com/postor/simple-devops