DevOps系列(1)-整体架构

扯闲淡

在进入正式话题以前，先扯个淡，这算是第一篇我正式在博客上发布的随笔吧，以前也一直有想写点什么，将本身多年的工做经验分享出来，供你们参考点评，可是奈何一直对本身的文字功底不自信（其实也确实比较烂，上学期间，语文永远是拖后腿的），固然，最主要仍是由于本身的懒惰，致使一直没有付出行动。

细算下来，到目前为止，我从事.Net开发已经差很少八年了，也算是一只见证了.Net从兴起到衰落（不知道这么说会不会被打）再到逐渐有复苏迹象的老鸟了。在这个过程当中，带过团队，也担任过架构师（当时为了证实本身并不是野路子，2018年还专门拿下了软考《系统架构设计师》认证）。在企业内部Wiki上也写过很多文章，作过很多技术分享，但毕竟是小群体，文章写得再烂(甚至只有提纲，或者只字片语，或者只有一张图)，也能够经过沟通解释清楚，就算真的写错了，也会有不少补救措施，不会产生什么不良影响。而对外发布，对内容的完整性，严谨性以及文字组织能力的要求就要高得多，而这正是我不得不花精力填补的短板。

2020年注定是不平凡的一年，对于咱们这些.Neter来讲更是如此，我不肯定可否经过文字完整的出本身的思想，可是我会尽力，但愿个人文字不会带偏你的思路，固然，若是你能赞同个人观点，并能从中获得一点点启发，那将是我莫大的荣幸。

好了，闲淡扯完了，进入今天的正题吧！

整体架构

在这里，我准备结合本身的工做经历和我的理解，针对当前比较火热的DevOps话题出一个文章系列。可是，在这以前，有必要从总体上梳理一下思路，圈定一下范围，以保证总体思想的一致，并方便后续文章的展开。

这个系列并无涵盖DevOps的所有内容，例如，没有包含服务的链路追踪、日志监控、健康检查等微服务相关的部分，也没有包括集群和容器的监控、管理、健康检查、报警等更偏向运维的部分，而是更多的聚焦在CI/CD上。微服务相关的部分后面可能单会独写一个系列详细探讨，而运维相关部分则不会过多涉及，即便是K8S容器编排也只会点到为止，由于这部分我本身接触的也比较少，不敢瞎写。

概览

注意，这里的Jenkins并不是部署了多套，而是在同一套Jenkins中根据部署环境的不一样划分了多个分组，每一个分组有各自不一样的权限和功能。

流程说明

1. 开发人员每次写完代码以后，Push到源代码仓库（企业中必定会有本身SVN或者Git等私有仓库，这是即便没有DevOps或CI/CD概念也会存在的最基本的基础设施，我后续会直接使用GitHub，所以不会单独介绍这部份内容），自动（或者定时轮询）触发Jenkins构建，完成Nuget包还原，静态代码审查，单元测试，上传报告到SonarQube服务器，若是构建失败，或者代码审查和单元测试报告不达标（实际工做中，因为各类缘由，这个目标比较难以达到），则反馈开发修复，若是达标则构建镜像并发布到开发环境的Docker容器中；
2. 开发人员功能开发完成，并经过开发环境容器测试经过后，将Dev分支合并到Master分支，并发送提测通知到测试人员；
3. 测试人员（能够在分支合并的时候自动触发，或者定时轮询）构建Master分支，大致流程跟开发分支相同，不一样点就是会发布到尽可能贴近生产环境的Docker集群，同时将镜像Push到Harbor镜像仓库；
4. 测试人员测试经过后，通知运维人员安排上线；
5. 运维人员经过手动触发Jenkins的方式，先从Harbor上Pull对应版本的镜像，并逐步分阶段完成到生产环境Docker集群的部署。
6. 剩下的就是生产环境α测试和β测试及一系列的监控了。

总结

DevOps更多体现的是一种思路和流程，可能每一个团队作法都不同，例如，有的团队可能在Dev分支上测试，而在Master分支上构建生产环境镜像；有的团队可能由于环境隔离的缘由，不得不部署多套Jenkins环境等，但归根结底目的是同样的，就是达到全程自动化，减小人力劳动（不知道算不算本身砸本身饭碗）以及各类人力，环境等因素致使出错的几率。

后续的文章我会按照这个思路展开，若是存在考虑不周，或者能够改进的地方，但愿各位大佬们可以及时指出，你们一块儿探讨，共同进步！

最后，但愿.Net生态愈来愈好！