编者按：这篇博文是CloudBees和Autodesk.乔治斯旺是Autodesk Build Platform的高级主管，他在2018 AllDayDevOps会议的主题演讲中分享了过去三年来Autodesk使用CI/CD管道迁移到DevOps的经验教训奏鸣曲。天鹅现在可以添加"DevOps"转型领袖"的一长串成就。DevOps.com网站斯旺被评为2018年最佳DevOps转型领导者，因为他领导他的工程团队并实施了"全产品"DevOpsAutodesk。此DevOps转型由三个关键业务因素驱动。首先，Autodesk正在从永久性维护模式转向订阅许可模式，在这种模式下，客户希望经常定期提供新内容。其次，Autodesk一直致力于成为一家云平台公司，这要求他们采用现代的DevOps实践。第三，在瞬息万变的市场中保持竞争力意味着采用现代社会工程实践，在协作和开发共享软件的方式上变得更加协作，利用共享参考开发、构建和部署平台。筒仓走开，而且，一个新的冒险，Autodesk的环境对于一个大型企业的大多数人来说可能听起来非常熟悉。四年前斯旺加入的时候。Autodesk在桌面、web和移动平台上拥有大约200种产品。产品团队通常不经常发布。两个星期被认为是最快的，而一年是发展缓慢团队是高度孤立的，用于开发和部署产品的工具也是如此。"我们各自为政，拥有人类已知的所有工具，"斯旺说工程人员以他们的执行速度而自豪，而执行管理层则看重这种过度分享/协作。"如果一个现有的组件完成了他们所需的90%，他们会复制它并添加自己的10%，而不是现有组件的内部来源。该公司的大部分业务都是通过收购实现的，因此这加剧了这一点问题。尽管如此因此，Autodesk是将复杂产品推出市场的专家，但很明显，他们的工具、流程，而围绕开发和部署的文化是老派的，需要这样做重构。天鹅让开发人员将精力集中在新内容的开发和部署上，让他们在一个全新的环境中自动进行内容发布和测试，只有在测试失败的时候才会回来。Autodesk的新目标是，该系统允许每个内容开发人员每天推送两次部署，即每次部署约4000次一天。那个vision并不是从整个产品的DevOps概念开始的，但现在它做到了。如果对源代码、产品文档、API文档甚至配置文件的更改意味着服务或应用程序被自动重建并部署到所需的所有端点，这不是很好吗？如果客户看到的产品在代码和文档之间总是一致的，这不是很好吗？国际客户难道不喜欢在英文版的同时提供本地化内容吗？最后，如果他们能够在Jira积压工作中使用一个史诗，并在桌面、web服务和移动应用程序上执行受此影响的部署，这难道不是更美妙吗？旅程从高管的支持和支持开始。幸运的是，寻求这一点的时机很好——业务需求与DevOps的方式非常一致救命，斯旺他说："如果我们在几年前就尝试过这种方法，而高管的重点是本地化的快速执行，我认为它不会取得这么好的进展。"，高管们看到了好处，并出资组建了一个团队来实施CI/CD.之前Autodesk可以向现代的CI/CD管道发展，更新其开发工具是非常重要的。工程从Perforce迁移到GitHub Enterprise，并设置Artifactory来存储所有二进制文件。在对词源进行考证的同时，也对其进行了考证。用于部署桌面产品的部署基础设施仍然能够满足需要，但是他们需要一个全新的云部署基础设施。因此，Autodesk构建了自己的部署平台，用于将容器部署到Amazon ECS上。项目跟踪在Jira中处理，Slack用于协作和通信.Autodesk然后在这个平台上创建了它的CI/CD管道，并使用CloudBees核心中的管道插件对其进行了编排。最初这个管道只用于开发和部署源代码。然而，管道很快就扩大到包括部署整个管道所需的资源产品第一个扩展是基于对文档源使用降价语言的文档管道。管道接受降价，使用Metalsmith生成HTML，对其进行测试，将其发布到Artifactory，然后将内容推送到各个目标。因此，现在文档的源可以放在软件旁边，或者作为组织内部的回购，或者作为回购自Autodesk 75%的收入来自非英语客户，下一个项目是增强软件和文档的管道，以包括持续本地化。这样，每当软件中的资源被更改（例如错误消息或UI组件），它就会自动本地化为目标语言。他们做了同样的文件内容。最后，Autodesk需要一种更好的方法来管理开源、第三方和内部构建的二进制文件的生成和管理。他们通过添加组件CI/CD管道来解决这个问题。组件驻留在它们自己的GitHub repo中，每个组件都有自己的Jenkinsfile，可以在发布到之前构建、测试和打包二进制文件手工艺品。课程他们从中吸取了一些教训方式：变革型领导"非常重要，"斯旺说，请注意，如果没有滚啊滚啊我们的参考解决方案并不停留在实现上。成功必须被定义为有一个解决方案，工程师喜欢*并且*被70%以上的工程团队使用。斯旺说："我们从来没有停止销售，营销，唠叨，羞辱和帮助团队，直到我们到达那里。最初的迁徙得到了完全的白手套治疗。我们根据客户的需求和我们的管道能力对客户进行分层。为了扩大迁移规模，我们需要投资于自助式的入职工具、文档和培训。他们的筒仓式历史意味着团队拥有自己的共享二进制文件副本，并且在某些情况下还对源代码进行了本地修改。找到共享组件的所有者，并将源代码和二进制文件统一到单个GH repo和Artifactory文件夹中仍然是一项工作挑战。处理带降价的文档非常棒。源代码与代码一起存储，所有DevOps最佳实践都适用。开发人员对文档的投入更多，因为他们知道如何处理请求（而不是在一些外来的文档工具中进行审阅和编辑）。最后，这鼓励团队在编写源代码的同时编写文档代码。本地化可以是连续的。它在自动翻译、翻译词典存储内容、建立一个计算场来进行翻译等方面花费了大量的投资，但是这种技术是可以让其他人来完成的同样。自动化只是第一步。如果工程不采用DevOps研究与评估（DORA）等推荐的流程和最佳实践，那么团队就无法充分利用这一点自动化。他们的今天的GitHub开发平台：4000个用户，16000个GitHub存储库，每天1800万个Git命令-获取、克隆和提交。人工制品：储存1-1/2百万个工件并以180万的速率下载白天。云蜂编排核心：选择Jenkins pipeline插件是因为提供了技术支持，特别是对于转换。目前，Autodesk的4000名工程师中有一半正在为每个周。科达西声纳检查功能缺陷检测。白源和Checkmarx用于安全漏洞检测和许可合规。吉拉对于bug跟踪和项目管理，处理200-150万问题a年。汇合内部维基：400000页数。松弛：8000个用户和7000个空闲频道.CI/CDtodayAutodesk的CI/CD管道并不是一个专注于集成和部署软件的管道。它由多条集成在一起的子管道组成，如下所示图表：Autodesk具有a： 用于生成和部署产品生成中使用的二进制文件的组件管道。通过这种方式集中，Autodesk可以控制对共享内容所做的更改，并管理可以在中使用的二进制版本生成。源开发和部署桌面、云和移动内容的代码管道平台.文档基于降价的管道。公司中确实存在生成和发布API文档的管道，但尚未集成到参考中管道。本地化管道。软件资源或文档可以自动翻译为Autodesk支持什么对斯旺来说，下一个挑战是什么？建立团队，以一种完全自动化、可重复和符合SOC2的方式，每天成功部署本地化源代码和文档4000次。激动人心的时刻就在眼前！其他资源阅读如何释放DevOps的力量学习如何开始DevOps之旅发现DevOps中的顶级专家