前言
随着DevOps的普及，极大地减少了dev和ops的沟通协调，大幅缩短了开发到部署的耗时，发布也由原来的开发运维一起通宵变成研发人员7×24小时自由发布。通过这篇文章给大家讲一讲如何通过研发工作平台让研发交付更加高效。
100%定义工程
公司早在2018年就落地了DevOps，但更多还是聚焦在资源管理、环境管理、CI/CD上，很多工作依然需要研发走流程然后由运维人员手工执行，一定程度上也会影响研发的效率。（研发通宵上线没有提前告知运维留人值守，凌晨电话打不通的情况时有发生）那么有没有一个可能就是让研发人员100%自定义自己的工程呢？
为了解决这个问题，我们对工程全生命周期可能用到的功能进行了梳理，并全部通过研发工作平台可视化、场景化地提供给研发人员。下面具体从一个工程的全生命周期来给大家介绍一下我们是如何实现研发人员100%自定义工程。
1、定义工程
创建工程我们引入了工程模板，研发人员根据工程的用途，选择合适的工程模板，系统会自动生成代码和git仓库，生成的代码也会上传到对应的git仓库里面，并默认赋予创建者git的owner权限。模板中还整合了公司标准组件，相关配置也会给出合理的默认配置。大幅减少新人的学习和配置成本，同时也保证了公司技术栈的相对统一。
2、需求管理
当一个工程创建后或者有产品迭代需求的时候，就需要进入研发阶段，这个时候只需要通过研发平台创建一个需求即可。早期我们创建一个需求需要填写的信息多达15项，经常有产品经理或者研发人员不懂如何填写导致流程无法正确创建。
公司大部分团队都是敏捷开发，每天创建60+新需求，每次都要重复填写信息也是一件非常麻烦的事情，为此我们提供了基于模板的快速创建功能，大幅减少了需求创建带来的困惑和耗时。
3、资源配置
代码开发完成需要进行测试时，研发人员可以通过研发工作平台在对应工程的详情页面进行资源的配置。
（应用资源配置）
研发人员可以自主地完成资源的配置（默认会推荐一个最小可用的标准配置），完成资源配置后还需要配置域名，通过域名管理界面，点击解析即可自动生成各个环境对应的测试和正式域名。
（域名解析）
一个工程最基本的配置就完成了，研发人员还可以根据实际情况选择使用其他公共服务。比如：配置中心、调度任务、灰度发布、在线诊断、数据同步等通用服务，减少重复造轮子，缩短研发时长。
4、数据库配置
绝大多数工程都需要用到数据库，我们也通过平台提供了申请数据库权限的功能。申请后系统会自动创建相应的连接信息并将这些信息写入到工程默认的配置中心里面，研发人员只需要在代码中使用配置项即可完成开发，相关信息也会进行脱敏处理，避免信息泄露。
（申请数据库界面）
除了支持一键申请数据库权限外，还支持数据库自助变更操作。
（变更表界面）
所有的变更必须通过工程详情页面发起，执行后我们会自动完成工程和数据表的关联，通过工程和数据表的关联解决数据归属的问题，为后续数据治理奠定了基础。
目前我们已经实现了90%+的工程和数据表的关联，未关联的也在陆续评估是否仍在使用，对于未使用的也会备份后进行下线。（对于这块感兴趣的可以留言，后续分享相关技术实现）
5、需求发布
配置好资源，接下来需要把代码发布到相应的环境了，关于CI/CD①、缩短编译构建时长②之前也有文章介绍，这里不再赘述。
这里重点介绍需求详情页面，之前我们发布一次代码需要在多个系统来回切换，打开几十个浏览器tab标签，通过一系列的整合，我们将一个需求发布的所有操作功能整合到一个页面，只要在这个页面即可完成流程、发布、代码合并、数据变更等本次需求研发的所有发布工作。
（需求详情页面）
目前完成一次测试环境到线上的发布，平均耗时约10分钟，所以整体来说耗时还是比较长的，我们通过数据分析发现，大量的工程在一个需求下，推送测试环境的次数高达百次，不少工程编译成功率也不足50%，对于这种情况我们进行了调研，发现部分团队把测试环境当开发环境使用，很小的修改就会进行发布，甚至都没有自己本地编译。为了反映这一情况，我们在需求详情页面添加了相关统计数据的展示，让大家重视这个数据，减少发布次数和提高成功率。
（工程发布统计）
我们对比2021年和2020年数据的时候发现，发布次数减少16%，编译构建的成功率由69%提升至87%。
松管控、强卡点
为了保证研发的合规、质量、安全等，对于一些关键节点也需要进行卡点，效率和质量自古难两全。那么如何让他们融合更加违和呢？接下来给大家分享一下对于质量和安全是如何进行卡点。
前面已经提到，我们的整个研发流程是基于JIRA来实现的，整个研发主流程如下：
（研发主流程）
为了让研发流程尽可能的流畅，我们对于产品迭代和bug修复类的需求，业务部门是可以自助走完流程。这个调整极大程度地减少了由于流程带来的耗时。
为了保证质量，我们引入了QA审核，QA会在发布后对于本次需求进行审核，早期这个审核是先审的，通过分析之前的数据发现，整体合格率较高，所以我们调整为后审。调整后合格率确实出现了小幅的下降。QA人员通过和各业务方沟通分析了下降原因同时给他们提出了一些要求以及我们调整的初衷，一个季度后基本恢复到正常值。
（刚调整时）
（调整一个季度后）
我们还提供单元测试功能，业务方可以根据实际情况决定是否进行单元测试（目前正在试运行阶段，整体效果不太理想，大部分工程都很少或没写单测）。
（触发单测）
研发环节也增加了预发布环境（必要），支持灰度发布（非必要），尽可能的让开发的功能进行充分的测试和验证，减少因为发布带来的故障。
为了保证安全，我们把SDL（安全生命周期管理）融入DevOps（也叫DevSecOps）。
研发人员通过研发工作平台创建工程的时候，我们就会提示他需要进行安全评审。一方面将安全评审工作前置，另外也避免开发完成后再来评审影响整体项目进度，如果这个时候未进行评审，当研发人员在操作域名解析的时候会也会再次提示。
（工程创建成功界面）
（域名解析失败提示）
研发人员在发布代码的时候，我们还会对代码的软件成分进行分析③，看是否引用了不安全的组件。工程的依赖组件信息也会展示在研发工作平台的工程详情页面。
（工程安全信息）
除了评审和软件成分分析，我们还在研发流程中加入了人工安全测试的流程，由于人工安全测试耗时较长，可能影响研发的发布时间，所以对于安全测试的选择业务方是可以自主控制的。
（安全测试选择）
选择不需要测试的，我们也会定期进行复盘和抽样测试，对于选择上线前安全测试的我们会严格进行测试，且发现的问题必须修复才能上线。对于选择不需要安全测试和上线后测试的需求，如果发现了高危及以上的安全问题，将扣除相关研发人员安全积分。这样也可以反向让他们合理的选择安全测试的时间。
6、工程下线
相信大家公司都会遇到很多“老项目”无人负责，运维人员也不敢轻易处理。这个问题我们通过产品+运营策略已经做到所有工程都有负责人且负责人属于在职。
如果业务下线了，工程负责人就需要评估相关的工程是否需要下线，对于下线这种操作多数情况是“费力不讨好”的事，所以导致“老项目”越来越多，为了解决这个问题，我们一方面引入成本的概念，倒逼业务方有一定的动力来下线工程，另外我们也提供了完善的自动化下线功能，确保“老项目”平稳下线。功能上线半年多，已有8%的工程通过此功能平稳下线。
