随着系统越来越大，开发人员、站点、服务器越来越多，微服务化推进，......等等原因，实现自动化的devops越来越有必要。
当然，真实的原因是，在团队组建之初就预见到了这些问题，所以从一开始就决定这一块要自动化。
带来的实质好处也是显而易见的，人力成本的节省、规范化的流程、可追溯的发布历史、解脱双手（重复性劳动）、避免人为操作产生的错误等等。
1.目前市面上的成套的产品要么贵的要死，要么不支持本地部署，要么就还是一个demo级别的东西，最重要的还是每个公司或者产品都有自己的一些特殊环境或者业务再里面。不一定都适合。反正是比较难找到好用的，而且是成套的产品来。期待一个devops界的SAP，而且还要便宜！
2.几个老大哥产品还是做得很牛逼！比如jira，confluence，jenkins，sonar。官方文档非常完善，网上教程多。接口完备。不像某些产品，看上去高大上，一用起来就是各种坑
3.懂开发的运维觉逼是牛逼的程序员！（^_^）
4.人真的非常重要，不然流程什么的，呵呵，都是个屁......
当然，目前这套工具还有很多不完善的地方，随着不停的使用，或者变化的需求来进一步变化。 gitlab
开源的git仓库，主要有几个用途
1.源代码管理
分支管理规则可以参考gitflow，或者规定一个合适自己的就好，微服务化后，一个站点或者说一个项目参与的开发人员只有有限的几个人。用了简单的方法，master作为发布用分支，每次迭代开发使用新分支，上线前合并到master；线上简单的fix则直接在master分支上提交。
2.配置文件管理
放在gitlab上，主要是为了方便管理，以及追溯修改历史。当然，我们有自己的配置中心，能走配置中心的都尽量走配置中心，只有必须是文件配置管理的才放在gitlab上。
3.发布脚本管理
jenkins需要使用到的发布脚本。根据环境、源代码语言、部署方式等有所不同
jira敏捷开发管理工具，管理需求、研发迭代等。在加上他们家公司的wiki做知识库管理基本稳了。
jira用下来发现还是相当强大！各种自定义可配置。页面、字段、流程等等全可配置。有http open api可以直接调用修改信息、触发流程等
使用的发布流程也比较简单。开发创建发布任务，然后提交给测试，测试在jira上操作发布到测试环境，准线上环境，线上环境进行测试等。准线上环境测试完后要发布到线上需要让具有leader权限的人进行一次审核，一方面是让leader知道有什么东西上线了，另一方面也是安全控制的一些原因（比如说节假日前夕最好是不在做更新等，要做更新就得报备，不然出问题节假日就得嗝屁）。
截图是比较历史的版本了，最近在jira里面找了一个进度条插件，然后把构建发布的实时进度直接反馈到jira的页面上。这样就不用再打开发布系统查看发布进度了，进一步提高使用体验。
发布流程工作流，根据自身的情况设计的
这一块，是我们自己开发的一个简单系统。主要作用是衔接各个开源工具的使用。作为一个粘合剂系统使之分散的各个子工具能链接为一个整体。
虽然，jira里面有jenkins插件，jenkins里面有jira的插件，但是组件对各个系统都有版本要求，然后组件使用上也蛮不方便的，最后也有一些需求要解决起来相当麻烦，所以才有了自己的发布系统。
功能还是比较简单，一个前端小伙弄弄页面什么的1个礼拜就完事了，关键还是把当下的各种新技术都秀了一波，虽然页面挺丑的。几个系统的接口调用自己研究写一写也就几天就完事了。
主要完成的几个功能
1.发布配置管理
站点或者系统的开发语言，部署的目标系统，要部署那些主机，是不是docker容器方式，docker要部署几个示例，部署方式并发、串行发布，要走那一个nginx，绑定的域名，绑定的端口等等信息。
在新的系统或者站点发布的时候由运维和研发协调填写，后期则由运维来维护，比如扩缩容等