初遇DevOps
最早接触到DevOps是在2018年8月26日，那时首先接触到的就是大名鼎鼎的Jenkins，当时看了多篇关于持续集成和持续部署的文章，蠢蠢欲动，便开始了第一套DevOps环境的搭建
Jenkins
第一套DevOps是用Jenkins+Ansible+GitLab搭建的，那时只是了解Docker的好处，并没有使用Docker搭建整套环境，还是基于传统虚拟服务器搭建的整套流程。
Jenkins不仅可以编写groove脚本、pipeline 流水线等，还能与maven集成自动构建，深深感受到了Jenkins的强大，同时大量的用户为其贡献了许多插件，有很多实践问题都可以在网上搜索到解决方案
搭建过程：
最后顺利实现了静态网站持续集成、持续部署，详见：
Docker+GitLab
随着容器化技术在国内越来越流行，容器普及度越来越高，其带来的环境隔离极大推动了DevOps的落地，使得无需使用python环境隔离，可以直接利用容器技术实现跨平台和环境隔离，并且利于迁移和部署
于是在2019年4月开始研究GitLab官方文档，发现其早已原生支持流水线，并依托其GitLab-runner可以直接实现整套DevOps环境
因此，经过不断摸索，完整的搭建的基于Docker和GitLab的DevOps环境，搭建过程见：
由于国内当时对GitLab流水线使用的并不多，因此遇到的很多坑都需要翻查官方文档和国外的实践记录，比如：
DevOps 带来的好处
2019年7月将手上的一个小型项目尝试使用完整的DevOps流程开发，开发小组选择敏捷开发方法，所有的开发工具都尽量的适应快速的需求变化，同时投入非常少量的开发人员，分工明确，从一开始一周发布一次到最后一天可以发布多次
开发人员已经完全从运维中脱离，全团队没有专门的运维人员，极大的提高了开发效率，精简了人员构成，一旦构建失败，开发人员可以根据邮件通知的内容排查上线失败问题，调整代码和配置后重新提交
面板提供了流水线统计图，如果出现频繁的失败还是需要人工介入，查看问题原因
当前的问题
尽管使用了基于Docker+GitLab的流水线实现了完整的DevOps流程，但对于监控和日志部分仍然处在很多问题
- 尽管上线的是单体应用，服务器和应用的健康状态都无法得知，也没有相应的告警
- 应用的日志没有被外部服务收集，无法进行快速分析
- 没有实现完整的测试流程，生成测试覆盖率报告等
- 没有实现0停机上线，在容器切换时仍需停机1-2分钟
- 没有实现灰度上线、蓝绿部署等，上线失败需要手动回滚
未来探索方向
全面容器化服务治理方向
- 国内对容器化有非常多的实践
kubernetes作为容器调度成为大多数服务治理的选择- 容器隔离、迁移和伸缩带来的巨大优势
容器与传统应用部署结合方式
- 以半全自动方式落地
DevOps，采用Mesos+marathon方式同时兼容传统服务部署和容器化部署 - 兼容分布式服务治理
- 国外有大量的实践案例
- 日志收集体系完备
- 以半全自动方式落地