可靠交付
更频繁的部署是很好的选择，但是在实现它们的同时维护高质量的代码则完全不同。
每个人都在谈论转向自动化工作流程，这也就不足为奇了。 我们所有人都希望为我们的产品和应用程序部署更多的特性和功能，并且我们希望尽快完成。
但是，自动化并不是我们应该轻视的事情，因为它带有一些不容忽视的风险。 最主要的是，比以前更快地移动意味着更少的时间来保证质量。
这就是为什么我们需要自动化才能双向工作的原因。 升级和改进我们的应用程序，并允许我们根据其对用户的性能进行学习和适应。 我们想强调对于开发团队和用户来说必不可少的。
更快的部署！=更好的代码质量
我们希望确保开发团队为他们的工作和构建感到自豪，同时为用户和客户提供优质的产品。
为了超越竞争对手，比以往更快地构建更好的产品，交付功能和创新的动力，是促使公司迈向自动化工作流程的动力。 确实，将持续集成引入组合可以帮助我们更快地合并和部署代码。
随着频繁的代码发布，生产中会出现更多的问题和错误。 现在，由开发人员和质量检查团队来确定如何确定一切正常，并在部署到生产中之前检测问题。
反馈循环不应以质量检查结束
在开发过程的一小部分中，开发团队编写并部署了代码之后，是时候让质量检查人员通过手动或自动测试方法对其进行测试了。 当他们发现问题时，会向开发团队报告问题，他们将应用所需的修复程序，重新集成代码等。
换句话说，我们在测试和开发阶段之间有一个反馈循环。 这是每个良好开发周期的基础，它可以帮助我们随着时间的推移学习和改进。
但是反馈循环与整个开发周期相关，它们并没有在临时环境中以QA / dev部署和测试元素结尾。 众所周知，生产倾向于表现出意想不到的和意想不到的行为，甚至有人会说问题和错误是凭空出现的。
在生产和开发之间存在另一个反馈循环，以帮助开发团队以实时和真实的用户行为了解其代码在“真实世界”中的行为。 当前，此部分的反馈来自设置警报，搜索日志以及在最坏的情况下客户抱怨寻求支持的情况。
不幸的是，我们的反馈循环还不够好，也无法逃避生产中的问题。 不同的环境以不同的方式起作用，通常，您的工程师会花费其一周的20％以上时间来尝试发现和解决这些问题 。
反馈循环至关重要，要获得整个软件交付供应链中的应用程序完全可见性，唯一的方法就是在每个步骤中都建立反馈循环，而不仅仅是质量保证。 而且，我们需要确保所获得的信息可靠，并且能够为我们提供了解正在发生的事情所需的正确信息。
改善反馈，一次循环
部署更快的外部压力在质量保证和开发人员之间造成了差距，导致无法在较短的时间内生成良好的代码。 发现问题后，将其扔回去，而无需正确的信息来解决它。
在某些情况下，开发团队将不得不搜索大量的日志文件以检测生产中发生的单个问题，从而首先了解用户的操作导致了该问题。 由于当前缺乏代码和用户在生产中的行为的可见性，因此无法避免此过程。
因此，我们拥有一个自动化的工作流程，并且反馈循环不间断。 但这不仅仅在于“使之工作”，还在于随着我们获得的每一个机会而使其变得更好，更强大。 使CI和反馈回路更有价值的方法是在方法的每个步骤中为它们提供可靠的数据。 此数据应包括：
- 执行栈和字节码
- 完整的变量状态（覆盖完整的源代码）
- JVM状态：线程，环境变量
- 相关日志语句（包括生产中的调试和跟踪）
- 事件分析（频率，失败率，部署，应用程序）
并且由于这是至关重要的信息，因此我们必须确保它是可靠且可操作的。
为此，我们可以设置警报，以尽快发现错误，为每个功能添加无尽的日志，和/或使用不同的监视和检测工具，从而做到这一点。 在团队内部，我们可以强调团队之间的代码审查，在预生产环境中验证性能，应用单元测试等等。
但是，所有这些选项都比实际的修补程序更像创可贴，尽管它们确实可以促进更好的工作流程，但最终可能会影响产品的性能。 不仅如此，这些选项不会提供增强和完善循环所需的完整上下文。
我们已经与一些企业客户（例如银行，医疗保健提供商等）进行了交谈，并了解到他们也在环境中遇到此问题和需求。 组织规模越大，就越难以处理和解决这些问题。 更不用说在登台和生产中发现并修复各种问题和错误的成本。
最后的想法
自动化的工作流程还不够，尽管它们可以帮助加快开发速度，但我们需要确保它们在此过程中也能推广更好的代码。 通过向过程中添加有价值的信息来改善反馈循环，这不仅对开发人员和运营团队有帮助，而且对质量保证也有帮助。
通过允许QA团队向开发人员提供完整的环境，它将有助于赋予他们质量。 这样，质量保证可以提供全面的数据，并帮助结束“无法复制/重新创建”的循环，这是开发和质量保证之间的主要对话。
翻译自: https://www.javacodegeeks.com/2018/07/continuous-delivery-reliability.html
可靠交付
1651
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
