中小型系统必要可行的DevOps方案实践思路
本文内容是个人针对实际工作中的问题，进行的一番思考、总结，供中小型公司进行DevOps实践时作一个思路上的参考，我觉得做事情，思路很重要，抛砖引玉...
背景
本文主要探讨中小型公司必要可行的DevOps方案与实践，中大型公司都有自己DevOps方案以及自研框架，直接略过即可。 一般而言，专业的事情还得专业的人来干，大厂有专门负责产品设计的产品业务部，根据市场部、项目反馈设计产品功能，画出产品原型图，产品经理就是干这事的，专门负责代码开发的产品研发部，负责测试的质量保障部QA，负责产品上线运行后问题处理的运维部 而中小型公司人员少：设计、开发、测试、运维配置不全，可能就是以几个开发人员为主，投入到测试、运维方面的精力肯定不多。 但是人少就不搞DevOps了吗？如果要搞，具体要搞哪些方面呢？其实做这些事情搭建一套Jenkins就可以，一劳永逸，以后大家就安心搞开发就行了。但是实现这一整套方案是耗时的，对有经验的人短时间就搞完了，不熟悉的人还要花好几周研究测试，如果有现成的思路、方法做参考，直接拿来套上去 是不是事半功倍。
我认为就是解决两个问题：哪些是必要做的事情？如何高效率的去做这些事情？
哪些是必要做的事情？中小型公司，虽然人员不多，该做的事还是要做的，麻雀虽小，五脏俱全嘛。如何高效率的去做这些事情？在21世纪了，机器能做的事情，就不会让人去做的。说白了，就是尽量不要人工去做这些事，全部搞成自动化，出了问题告警通知，然后人工介入处理。
1、代码规范检查、构建
代码检查
开发人员水平层次不齐，老员工又没时间去给新人做代码review,那怎么办呢？使用开发规范来约束，大家都按照这个规范来开发，至少能保证基本的代码质量，不至于代码里出现各种野路子，每天下班前用几套规范全量检查代码，对于不符合规范的代码以及谁提交的代码，抛出来发个全员邮件；
代码构建
由于有些开发人员马虎大意、本地IDE问题等直接提交代码，造成编译不通过问题，然后其他人更新代码一编译就报错了，然后找到提交人，等他改完代码提交，大家再更新编译多浪费时间，所以每天下班前应该有一个定时全量构建的环节，构建报了什么错误，谁提的代码，抛出来也发个全员邮件；
思考？
开发人员保证代码符合规范、编译无问题，这件事一点儿也不难，出了问题要么是态度问题，要么是马虎大意不严谨，这是技术解决不了的，只能通过管理手段来约束，发个全员邮件，大家都要面子，以后就会重视代码规范和编译问题，养成习惯，产品质量也就有了最基础的保证。
怎么做？
jenkins里有丰富的代码质量检查插件代码质量检查插件（FindBugs、CheckStyle、PMD、SonarQube）和编译构建插件（maven gradle），每次部署时先进行代码检查、编译构建，配合GIT提交记录就可以方便的找出问题代码和提交人，然后通过右键通知插件发送全员即可。jenkins是可以单独安装findbug、pmd、checkstyle这几个插件的，而sonar（全名sonarqube）是专业的集成代码质量检查软件，需要采用单独的web服务器安装部署，在jenkins中通过sonar scanner runner进行远程调用，然后在sonarqube控制台安装findbugs、PMD、checkstyle插件，一个完整的sonar服务器就搭好了。
参考：
jenkins+maven配置findbugs+checkstyle+pmd
Java代码质量检查checkstyle, pmd, cpd, p3c,findbugs, jacoco, sonarquebe以及和Jenkins集成
jenkins集成SonarQube-质量检查
jenkins集成Maven-编译、nexus-制品管理、清理工作空间
2、主线业务自动化测试
做哪些测试？
测试肯定是要测的，但是做哪些测试呢？单元测试就算了，国内基本没做的，成本太高，写业务代码时间:写测试代码时间=1:1，甚至1:2,想想就没人做这事，除非你工期不着急，老板有钱任性。中小公司可能没那么多环境，开发和测试环境普遍共用的，至少得有一个测试环境。我觉得在测试环境里，每天或每周做主流程测试就OK了，保证主业务和重点接口没问题就行了。举个例子：运营商支撑系统里开户、产品套餐变更这是主业务，跑一遍主业务走通就行，其他边边角角有点问题不影响大局，如果主业务跑不通，那你这软件还能做个啥，就是这个意思，抓问题就抓重点。
怎么做？.
肯定不是人工去点击测试，也不用那些复杂的框架，用newman测测接口就行。
参考：
API测试工具SoapUI & Postman对比分析
Web API 持续集成：PostMan+Newman+Jenkins（图文讲解）
Newman+Jenkins实现接口自动化测试
3、各个环境自动化部署
这个不难理解，开发人员测试直接在IDE测试就行，那测试环境呢，肯定要更新代码、执行增量SQL脚本、构建、重启；
怎么做？
肯定不是人工去打包、上传、重启，Jenkins写一个pipeline，自动更新代码、构建、重启，至于增量SQL下面会讲；
4、版本升级更新
在售版产品一般都有定期补丁包，项目团队定期更新或产品自动更新补丁包；
怎么做？
肯定不是人工去制作补丁包，结合git命令写一个shell脚本就可以制作补丁包，然后写一个Jenkins pipeline去调一下就行。
参考：
Jenkins实践
5、数据库版本管理
面临的问题
这类问题很多，要单独拿出来说一下，不同的公司问题不一样，我所在的公司就深受困扰：
（1）新项目或新测试环境初始化数据库，各个业务组提供了一堆SQL脚本，让测试或项目团队去手工执行？
（2）针对迭代环境：开发按照迭代走的，每一期都有对应的SQL脚本，建表语句、增减字段、预置数据等等，那测试环境或者项目团队怎么知道哪些脚本对应某个迭代呢，难道通过svn\git提交记录逐个找出来挨个执行？
（3）有些产品的数据库名称是动态的，比如租户不同，数据库名不同，那么针对不同的租户，还需要手工修改脚本后才能去执行？
人工执行会不会漏掉？脚本间是否有依赖，脚本执行有顺序？如果有多个环境要执行多遍？想想这些问题就头大。
另外：针对不同版本，不同环境，脚本执行是否有记录？如果影响比较大的脚本是否需要执行审批？执行错了能否回退？
思考
目前有一些框架Flayway、Liquibase，但不适用于所有场景，之前在一个大公司接触过类似的工具插件，感觉很有必要开发一个通用的数据库版本管理工具，自动记录归属的产品、迭代、顺序、执行记录，并可以自动执行，权限校验等，提供对外接口供jenkins调用自动执行。
怎么做？
参考目前的框架，开发一套通用的数据库版本管理工具，这个也是我近期计划的一件事，等做好了开源出来大家参考。
参考：
数据库版本管理工具
