本文内容是个人针对实际工作中的问题，进行的一番思考、总结，供中小型公司进行DevOps实践时作一个思路上的参考，我觉得做事情，思路很重要，抛砖引玉...

背景

本文主要探讨中小型公司必要可行的DevOps方案与实践，中大型公司都有自己DevOps方案以及自研框架，直接略过即可。	一般而言，专业的事情还得专业的人来干，大厂有专门负责产品设计的产品业务部，根据市场部、项目反馈设计产品功能，画出产品原型图，产品经理就是干这事的，专门负责代码开发的产品研发部，负责测试的质量保障部QA，负责产品上线运行后问题处理的运维部	而中小型公司人员少：设计、开发、测试、运维配置不全，可能就是以几个开发人员为主，投入到测试、运维方面的精力肯定不多。	但是人少就不搞DevOps了吗？如果要搞，具体要搞哪些方面呢？其实做这些事情搭建一套Jenkins就可以，一劳永逸，以后大家就安心搞开发就行了。但是实现这一整套方案是耗时的，对有经验的人短时间就搞完了，不熟悉的人还要花好几周研究测试，如果有现成的思路、方法做参考，直接拿来套上去 是不是事半功倍。	

我认为就是解决两个问题：哪些是必要做的事情？如何高效率的去做这些事情？
哪些是必要做的事情？中小型公司，虽然人员不多，该做的事还是要做的，麻雀虽小，五脏俱全嘛。如何高效率的去做这些事情？在21世纪了，机器能做的事情，就不会让人去做的。说白了，就是尽量不要人工去做这些事，全部搞成自动化，出了问题告警通知，然后人工介入处理。

一、代码规范检查、构建
代码检查：开发人员水平层次不齐，老员工又没时间去给新人做代码review,那怎么办呢？使用开发规范来约束，大家都按照这个规范来开发，至少能保证基本的代码质量，不至于代码里出现各种野路子，每天下班前用几套规范全量检查代码，对于不符合规范的代码以及谁提交的代码，抛出来发个全员邮件；
代码构建：由于有些开发人员马虎大意、本地IDE问题等直接提交代码，造成编译不通过问题，然后其他人更新代码一编译就报错了，然后找到提交人，等他改完代码提交，大家再更新编译多浪费时间，所以每天下班前应该有一个定时全量构建的环节，构建报了什么错误，谁提的代码，抛出来也发个全员邮件；
开发人员保证代码符合规范、编译无问题，这件事一点儿也不难，出了问题要么是态度问题，要么是马虎大意不严谨，这是技术解决不了的，只能通过管理手段来约束，发个全员邮件，大家都要面子，以后就会重视代码规范和编译问题，养成习惯，产品质量也就有了最基础的保证。jenkins里有丰富的检查插件和编译构建插件，每次部署时先进行代码检查、编译构建，配合GIT提交记录就可以方便的找出问题代码和提交人。