Enterprise Holdings. 的IT团队超过2000人，在2018年的演讲中介绍了Enterprise
Holdings的DevOps是如何转型的。我们通过打造一个不只包涵了pipeline的CI/CD平台，将其称之为SDLC。在最开始的200+个应用中，我们挑选出5个来作为试点。当时的情况证明这次DevOps转型计划是成功的，我们的团队有4+位工程师和两位架构师，从2年半前就开始了整个平台的开发工作，根据业务需求确保平台可以适配各种云服务、也要适配已有的中间件，我们也在不断对CI/CD平台进行改进，以适应所有业务场景。其的目标是让开发人员更专注于具体的项目开发，让工具去解决一些通用性的问题。为了达到目前的效果，我们做了很多关于平台的需求收集及问题反馈相关的运营工作，所以在过去的一年里，我们已经将此套平台服务于70%的应用中，并且这个数字还在持续的增加。
在DevOps转型过程中，我们的角色并不是软件的开发者，但我们支撑了应用开发团队和他们所开发的应用，我们的服务工作介于应用程序与基础设施之间。在我们的角度来看，应用程序的开发应该是这样的：
·开发人员在本地开发
·在仓库中检查源码
·在构建服务器上构建应用
·运行安全扫描
·打包发布到JFrog的Artifactory
·发布应用到不同的环境测试
·所有测试结束后，发布到生产环境
这个模式很简单，但是也很高效，但是为了实现这个流程做了非常多的事，我们开发了一些被称之为共享库的模版，并将此和打包程序、自动化脚本、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杰蛙在线课堂
关注公众号“JFrog杰蛙科技DevOps”，获取课程通知
来源：oschina
链接：https://my.oschina.net/u/4455305/blog/4315952