DevOps is Hard、DevSecOps is Even Harder
— Enterprise Holdings.
Enterprise Holdings. 的 IT 团队超过 2000 人，在 2018 年的演讲中介绍了 Enterprise Holdings 的 DevOps 是如何转型的。咱们通过打造一个不只包涵了 pipeline 的 CI/CD 平台，将其称之为 SDLC。在最开始的 200+ 个利用中，咱们挑选出 5 个来作为试点。过后的状况证实这次 DevOps 转型打算是胜利的，咱们的团队有 4 + 位工程师和两位架构师，从 2 年半前就开始了整个平台的开发工作，依据业务需要确保平台能够适配各种云服务、也要适配已有的中间件，咱们也在一直对 CI/CD 平台进行改良，以适应所有业务场景。其的指标是让开发人员更专一于具体的我的项目开发，让工具去解决一些通用性的问题。为了达到目前的成果，咱们做了很多对于平台的需要收集及问题反馈相干的经营工作，所以在过来的一年里，咱们曾经将此套平台服务于 70% 的利用中，并且这个数字还在继续的减少。
在 DevOps 转型过程中，咱们的角色并不是软件的开发者，但咱们撑持了利用开发团队和他们所开发的利用，咱们的服务工作介于应用程序与基础设施之间。在咱们的角度来看，应用程序的开发应该是这样的：
l 开发人员在本地开发
l 在仓库中查看源码
l 在构建服务器上构建利用
l 运行平安扫描
l 打包公布到 JFrog 的 Artifactory
l 公布利用到不同的环境测试
l 所有测试完结后，公布到生产环境
这个模式很简略，然而也很高效，然而为了实现这个流程做了十分多的事，咱们开发了一些被称之为共享库的模版，并将此和打包程序、自动化脚本、ansible 脚本等一起存储到源码仓库中进行版本治理，同时提供给利用团队去应用。为了撑持咱们的利用团队按上述流程实际，咱们应用了很多工具。
继续集成工具链包含：git、maven、gradle、Artifactory、Bitbucket、BlackDuck、jenkins
继续交付工具包含：Ansible、jenkins、Bitbucket、Artifactory、Oracle、Tomcat 等
工具应用简略，所以就会有人通知你 DevOps 是简略的，但这种说法是不负责任的，不能认为应用了某个工具，咱们就实际了整个 DevOps 理念。咱们公司的 it 团队由超过 2000 人组成，这些人开发了大量的应用程序，咱们要保障整个团队都能失常的工作。尽管每个团队应用的技术栈不同，应用的平台不同，但咱们须要找到这些人的共同点，以便在咱们的 DevOps 平台上更好的适配所有团队和开发者以及超过 200 个的利用。咱们须要保障所有人都能利用咱们的平台，并且保障平台实时可用，为此咱们在 jenkins 的下面应用 groovy 开发了很多 pipeline 模版、自动化脚本、jenkinsfile 等供其余团队应用。这样咱们就能疏导开发人员应用工具的时候是依照咱们指引的形式去应用的，并且在这个过程中咱们设置了很多关卡，明确通知了开发人员如果进行这些校验、他们的应用程序是无奈失常的被构建的。这样的后果就是，开发人员应用咱们定义好的模版，主动进行平安扫描，收集元数据，并把利用包上传到 Artifactory 中对立治理。之后咱们的团队就能够通过这些元数据所收集的后果，去反查到你的应用程序包含什么。咱们在模版中保护了一个 json 串，通知你这个模版会做什么事、收集什么数据。
下面都是说的 CI 的内容，接下来咱们探讨下 CD。很遗憾，到目前为止咱们依然没有方法将所有的 CD 流程自动化，咱们有太多的开发场景和平台，有大量简单的工作等着咱们去做。在咱们的 CD 体系中 ansible 负责了大量的工作，咱们应用 jenkins 去治理咱们的公布流程、并通过 ansible 去执行公布工作，最重要的是，咱们收集了部署中的数据（如公布的环境、公布的工夫、测试的后果等等），并把这些数据以元数据的形式回写到 Artifactory 中。在这个过程中你须要定制开发一些自动化的测试脚本，并把他们利用到 pipeline 中。
咱们的构建工作运行在一个 jenkins 中、测试工作运行在另一个 jenkins 里，这样的形式保障咱们的利用有一点点安全性。
在部署过程中咱们存在的最大的一个问题就是，每次部署不仅仅部署一个利用，可能会波及到很多利用同时公布，咱们为了解决这个问题，让利用运维团队去梳理了应用程序间的依赖关系，以及部署的程序。并且保护了一个清单来对整个公布进行阐明。Jenkins 会依照这些当时定义好的清单来进行公布，并收集到过程中的问题、哪个 stage 失败、是否影响到了其余的工作等等。并把这些问题同步到 pipeline 中以及 Artifactory 的元数据上。咱们给了所有开发者对 jenkins 的只读权限，这样能够确保所有的相干开发者都能够看到这些问题，并及时对问题进行修复。咱们通过这种形式，把一次公布由 4 小时缩减到 1 小时。
那么接下来，咱们要保障的就是每个人都依照这个规范去执行就能够了
接下来咱们议论一些平安的话题
平安是咱们组织中十分重要的一部分，施行起来也有很多艰难。在咱们不足安全意识的时候，咱们都应用普通用户。这些普通用户，实际上领有这些流程运行的权限。应用程序的团队甚至能够随便去应用有破绽的组件，每当咱们查看到这些问题的时候，往往这些问题曾经被引入到测试环境和生产环境了，咱们须要应用到很多开源软件，然而引入这些开源软件须要破费至多一个月的工夫去评估它的平安问题是否会对咱们的应用程序带来影响，这样的流程是与麻利开发模式不合乎的。
每一天都有十分多的破绽被提交到公网上，所以咱们心愿咱们的平安问题不应该仅仅由平安团队负责，开发、测试、运维团队的所有工程师都应该对平安器重起来，所以咱们抉择把平安扫描放到咱们的 CI/CD 流水线里。咱们强制所有利用流水线中必须减少平安扫描，如果没有这个 stage，那么这条流水线是无奈通过的。尽管开始的时候大家不违心承受，然而过了一段时间，开发人员发现平安团队找他们修复破绽的这种事变得越来越少，大家也就缓缓常态化了平安扫描这个步骤。这样平安团队也将分心的把工夫破费在钻研破绽对应用程序的影响上，缩小了与开发团队测试团队的沟通老本。另外咱们制订了流水线平安的 SLA，来定义一个构建的所有依赖是否满足上线需要。在这个过程也不是齐全顺利的，咱们发现每条流水线里都进行平安扫描十分破费工夫和资源，所以咱们改良了计划，每次扫描只扫描一些新的依赖、组件以及新的破绽特色，这样也大大的进步了平安扫描的效率。
将来工作中，咱们会持续与咱们所有反对的团队放弃继续的沟通，咱们要随时理解反对的团队的所有想法和产品，结合实际状况，向他们展现咱们的 CICD 平台是如何给他们带来收益的，确保最终每个团队都能够采纳咱们的最佳实际，被动来接入咱们的平台。总结来说，你所晓得残缺的 CI CD 应该是这样的，它不仅是开发，不仅是平安，更是运维、测试。所以 pipeline 根本等同于所有。咱们真的想确保咱们所有的过程的设计是平安的，这是咱们团队每个人的指标，咱们真正专一于在基础设施团队外部全面整合。整合内容包含服务器环境、网络、技术栈等等，而实际上这些整合都是依赖于咱们的 CICD 平台建设的。
欢送观看 JFrog 杰蛙每周二在线课堂，点击报名：
https://www.bagevent.com/even…