如何从开发流程层面实现更高效的持续交付
本文从开发流程角度分析了持续交付的实现，开发人员的沟通问题会拖延发布日期，必须客观地观察，才能了解成员之间的问题和流程缺陷，可视化的系统有助于找到问题所在，并在最短时间内解决，使用工具或系统管理工作数据是有效提高效率的方式之一。
如今，许多企业组织都在实施持续交付的做法。但想要提高持续交付的效率，很多时候会觉得是在构建自动化测试和环境部署的时候出了问题，不过我们认为还有其他因素导致我们发布软件版本时有些压力和阻碍，只是不确定问题是什么。
我们开始观察每一个软件版本发布过程并记录下看到的内容。例如，完成流程的每个步骤所花费的时间，是人为手动还是自动化发布，参与项目协作的人数有多少，以及发现导致新版本延迟发布的问题。一旦我们有足够的数据，我们就可以开始分析它并寻找解决方式，这些会成为我们要解决的最重要的问题。
在观察时保持客观是很重要的，不要让自己的偏见掩盖实际发生的事实，特别是在尝试改进项目流程和系统时非常有价值。
为什么要专注于改善我们的发布流程
原因是显而易见的，在软件版本发布时常常不像我们预计的那样顺畅，既不能无阻碍又无法实现频繁发布，从而影响了我们的交付能力。
在改进的过程中，能与技术专家共同合作能更快优化发布流程。与专家合作的好处在于他们尊重数据和事实，并且也非常热衷于让事情变得更好。同时上文提到的收集了大量数据，就可以显示出我们的问题，这意味着我们专注于解决实际问题而不是假设。例如，数据显示我们在测试分段环境中部署的插件比我们想象的要少得多，因此我们就可以轻而易举地处理这个阻止我们轻松部署的问题。
稳定发布不代表所有东西都必须在现在发布
如果某些改进真的非常重要，那在最快的时间内发布是不可置疑的。问题在于，当我们想要选择本周的候选版本时，由于各种原因，团队认为需要包含最后一分钟的“紧急”更改。这意味着推迟选择发布候选版本以及对发布周期的连锁效应，或者工作必须加班加点，即便赶在最后发布了，有时也会影响版本质量。
我们开始有这样的疑问，“为什么它必须在这个版本中出去？”，“如果我们本周不发布更改会怎么样？”或“它能等到下一个版本吗？”。要获取答案其实非常困难，因为对于团队来说开发已经是一个压力很大的情况，这些疑问的提出会被视作阻止他们进行更改。但事实上，当我们试图频繁地发布更改，更新迭代时，但其实是可以等待下一周时，它确实是违反了原则。因为我们会忘记了一点，软件版本发布的关键是稳定。
通过讨论并提出这些问题，我们意识到有些变化根本不紧急，因此不需要赶工。这样做的好处是我们的版本更加顺畅，需要修复错误的程序更少了，显然发布的压力也减少了，然后我们可以更专注于如何进行周期性规律地发布。
使用数据来识别问题和改变习惯
改变习惯是很难，因为习惯是长期这样做的结果，但你必须努力停止旧习惯并用新习惯取而代之。选择合适的时机发布可以突出发现我们的发布周期中的问题，并有助于解决修复问题。
我们可以尝试一些方法来帮助我们养成良好的习惯。例如，如果参与发布过程的人员将发送电子邮件作为主要通信方法的话，那一般会有数小时的延迟。必须了解到，在收件人阅读并理解电子邮件之前，发件人其实还没有传达任何信息。如果收件人正在开会，或者每天只会定期检查电子邮件，那么可能会延迟更久才能看到它。
为了改变这种电子邮件习惯，我们引入了一段时间的“物理提示”。在公众区域设立一个项目展示板，在上面写了候选版本号，每个人都可以补充和查看，信息会像涟漪一样扩散到所有人。那你就会知道整个发布周期里你的任务，以及目前的各任务进度。这也会激励你赶紧去做任何你应该做的事情，这也有助于推动版本发布流程。
展示板有另一个好处，让人们面对面交谈，相互了解并开始感觉像一个团队。它帮助我们降低了因沟通不畅导致的流程拖延的风险，使我们团队合作，并帮助我们形成了更好的沟通习惯。
总而言之，通过更有用的习惯来取代无效的习惯，展示板只是其中一个例子，你可以找到更多适合的“好习惯”。同时，一旦找到好习惯，那么就会形成行为雪球，在滚动中不断地变大，你甚至可以在这个好习惯的基础上再进行优化。如果你想了解更多，我强烈推荐可以在网上搜索 Helen Lisowski 的“Good of Good（Agile）Habits”研讨会。
应用科学思维方式来理解问题
当我第一次开始观察发布时，为了改进它们，我们可能不知道如何理解问题。这时候与经验丰富的敏捷专家，精益和系统思想家合作的好处就显现出来了。事实证明，我的整个观察，收集数据和分析的方法，都应用科学思维方式来理解问题的话会事半功倍。
如何应用科学的思维方式来理解问题，包括你认为接下来会发生什么，并根据实际发生的事情调整你的后续步骤。它有四个主要步骤：
第1步：
设定你的此次发布的目的和内容，有哪些是挑战，有哪些是日常。对我们来说，大部分会是按需发布，但这并不意味着我们每分钟都会发布，我们可以需要找到一种顺畅无bug的方式发布我们想要的改进。
第2步：
了解项目当前的开发进度和发布状况。这就是收集和分析的数据的来源，我们基本上有一个电子表格形式的价值流程图。
第3步：
建立阶段性的小目标，即您的第一个里程碑。从你当前的状态到你的最终目标往往是一个太大的跳跃，为了取得进展，确定一个更容易实现的中间目标是有帮助的。比如对我们来说，可以将发布周期从15天减少到10天，而不是直接把目标定在3天。
第4步：
确定并执行以达到目的。这是同样需要数据分析，数据向我们展示了我们最大的问题是等待发布的队列时间过长。队列是“死”时间，在此期间没有任何事情发生，我们只是在等待下一个过程发生。所以我们就可以将第一个改进重点放在减少或消除队列时间上。
通过上面描述知道我们要通过科学思维方式来实现改变，这里有一个例子，我们尝试将一个环境插件自动化安装到我们的测试板块。这听起来像是一个自动化过程，但是经过判断后，我们认为它是破坏的构建，主要原因是只支持手动进行部署，那么手动部署让工作的效率降低，结合数据分析，手动部署会让开发人员分心，导致发布进度被延迟。所以为了自动化流程 ，那必须延迟或者放弃这个环境插件的安装。
目前运用工具来实现自动化进程是最快提升测试效率的一种办法，市面上也有很多能实现自动化测试功能的工具或者平台，国内有 EOLINKER，国外有POSTMAN 等等。所以对于在国内的环境，运用好的自动化工具，能帮你更好地实现项目运转，提高开发测试效率。有兴趣的点击了解 EOLINKER：https://www.eolinker.com
改善版本的非技术方面的好处
显而易见的好处是缩短了周期时间。周期为10天，我们两周内不能发布超过一次。在进行了几次执行之后，当然我们不会满足，继续优化自动化交付，往后再减少一半，直到可以在一天内发布。
其他一些重要的好处包括：
- 更好的沟通和工作关系
- 自动部署到测试暂存环境意味着团队可以更快地完成测试，从而减少周期时间和反馈循环
- 改善我们糟糕的自动化测试
- 将发布的成本从15天减少到1天，减少到1人等
- 发布后需要修复缺陷的补丁较少
总结
- 可视化的系统和数据有助于找到问题所在，并在最短时间内解决
- 当试图说服管理层将时间和资源投入项目时，客观数据和分析图表非常有用
- 开放式办公室并不意味着他们沟通良好，设立展示板之类的办法可以促进团队合作
当对持续交付复盘时，很容易只关注持续交付的技术部分，毕竟，这是大多数人和开发资源所关注的地方。但是，也请查看整个发布周期，根据在项目自动化的流程和所需时间，找到在此期间其他非技术因素阻碍了发布。了解发布周期流程中的所有步骤，找到问题并改进，再确保团队的沟通方法有效并合作，才能有助于实现持续交付。
参考资料：Sylvia MacDonald,Continuous Delivery - It’s Not All about Tech!
地址：https://www.infoq.com/articles/continuous-delivery-not-about-tech/