云科技时代|微软的软件工程现代化转型( 五 )


CSEO有一个独立的供应商 , 负责评估应用程序中的可访问性 , 但这在开发过程的后期发生 。 为了进一步向上游推进 , CSEO推动在开发过程中采用可接入洞察工具 , 并将公开与可接入功能相关的 Bug 作为管道工作流的一部分 。
此外 , CSEO通过将基础设施集成到任务管道中 , 使工程团队能够利用正在部署的防护 , 并且正在推广持续集成的实践 , 以便所有生产环境中的版本(包括热修复程序)均来自主版本并持续应用所有适用的合规步骤 。 每个发布请求都必须具有成功的构建 , 以确保主版本处于可用状态 , 并且始终可以为进入生产环境而做好准备 。 在主版本中维护高质量代码将最大程度地减少构建失败 , 从而最终降低投入生产的时间 。
2.9 安全地部署到客户
CSEO在创建一个环境 , 使团队在构建想法和原型之前先对其进行测试 , 并且CSEO实际上专注于以一种快速失败、安全失败的思维方式来鼓励客户接受有风险的创新 。 CSEO提高对客户服务更新速度的关键 , 是以一种一致、精简且流程化方式向客户提供安全部署 。 增量式暴露和性能标签是通过受控部署向用户部署新功能的关键 , CSEO可以迅速开始接收客户反馈 。 CSEO通过利用服务指标(例如交付流水线中的等待时间和故障)在流程中进行检查和平衡 , 从而捕获性能下降并在超过预定义的阈值时启动自动回滚 。 实现安全的部署实践 , 结合精简和良好管理的管道 , 是实现持续集成、持续部署(CI/CD)模型的两个关键元素 。
2.10 启用代码重用
虽然数量很少 , 在CSEO的服务中不到5% , 但CSEO仍在支持使用本地服务器和加入域的Azure虚拟机的应用程序 。 这导致需要不断修补服务器、升级软件并执行基本的基础设施维护任务 。 这也阻碍了CSEO扩展应用程序以适应增长的能力 。 CSEO将继续进行投资 , 以将这些应用程序转换为基于Microsoft Azure平台即服务(PaaS)和基于软件即服务(SaaS)的解决方案 , 从而利用Azure的规模和可用性 。 CSEO通过提供体系结构指南和工具以实现该目标 , 包括迁移数据、将现有功能重构为API , 并通过重用他人已经发布的API来构建轻量级应用程序等 。
促进数据和代码重用以更快地构建解决方案并与面向服务的体系结构保持一致 , 这要求开发人员可以轻松地发布和发现API 。 CSEO通过创建一套通用的开发一致性API准则以及一个用于发现的中央目录和搜索体验 , 来构建API经济 。 CSEO正在根据API准则集成验证 , 并使团队能够将API发布集成到Azure DevOps管道中 , 并且正在定义并提供一组常见的API运行状况分析 。 CSEO还将继续致力于实现“内源”式增长的实践 , 来实现API外部代码的共享 。 这将帮助将现代软件工程实践扩展到微软内部的其它组织 , 在这些组织中业务主导的工程或“影子IT”正在出现 。 3:工程生产力
CSEO正在基于最新的Azure工具(例如Azure DevOps)在通用工程系统中为工程师提供一流的统一标准和实践 。 一致的开发环境使CSEO工程师可以在项目和团队之间平稳过渡 。 改进的自动化、一致性和集中式工程系统 , 使软件工程师能够更好地专注于开发的核心角色 。 这也减少了入职培训的时间 , 并使CSEO工程师在整个项目中更加灵活 。
3.1 提高一致性
CSEO正在创建和支持标准 , 以规范CSEO组织实践 , 同时继续让团队在这些边界内进行自我管理 。 这有助于确保CSEO拥有更精简的团队和更高效的工程师 。 这些标准包括使用以下内容:
-- Azure DevOps中常见的工作项分类和路径结构 。 通过标准化工作项分类和区域以及迭代的路径结构 , CSEO允许工程师通过提供一致的机制将每个团队的工作与CSEO目标和优先级联系起来 , 从而专注于工程 。 CSEO正在促进从Azure DevOps进行CSEO范围的查询 , 以提供可交付成果 , 例如合规性、可访问性和交付计划 。


推荐阅读