公司和团队希望快速行动。 这包括频繁发布，不断更新产品并保持团队成员对新技术的关注。 这些需求导致了持续集成和持续交付实践的兴起。
当前对CI / CD周期的广泛理解为测试-构建-部署阶段增加了很多自动化，但是却错过了整个发行周期中的关键步骤。 在下面的文章中，我们将了解为何CI / CD周期在部署后仍未结束，以及如何将缺少的链接添加到工作流中。
CI / CD工具链中缺少的链接
当前的CI / CD工作流程存在软件工程中最大的误解之一：如果有这么多团队在代码投入生产时遇到相同类型的问题，那么团队在进行自动化和CI / CD的方式上就必须有根本性的突破。
进一步探究为什么会发生这种情况，在过去几年中，我们与数百个开发人员团队进行了交谈，我们发现了一些共同点，即为什么他们在快速移动时会受到负面影响。
主要的问题是，当人们想到CI / CD时，他们经常有意甚至无意地将CI / CD视为一个周期，该周期始于代码提交，而当新代码部署到生产环境时结束。 最大的误解是CI / CD工作流程在将新代码部署到生产中时结束。 团队倾向于认为，当代码泛滥时，自动化就会停止。 这是完全错误的。
监视是CI / CD周期不可分割的一部分，自动化部署需要更智能的监视。 您想知道某个版本何时引入新错误而不依赖于用户报告，并拥有修复该问题所需的所有信息。
甚至扎克伯格也改变了主意和工作流程，2014年，公司将座右铭从“快速行动并打破事情”变为“快速发展，并拥有稳定的基础设施”。 社交网络需要确保应用程序和功能稳定，而没有生产中断的风险。
根本原因分析如何自动化？
世界已经发生了变化，但是大多数开发和运营团队都使用过时的方法对Java应用程序进行故障排除。 识别和调查错误的最先进技术已有数十年历史，无法满足当今的需求。
为了使您始终关注应用程序中的问题，您必须使自动化过程更进一步，并利用自动根本原因检测。 克服CI / CD障碍的企业和初创企业的工程团队正在通过在整个软件发布周期的各个阶段（从构建，测试，部署和监视）制定策略来做到这一点。
当Comcast的工程团队在发布后对其旗舰X1 XFINITY平台进行调试时面临挑战时，对他们保持尽可能高的效率至关重要。 该团队将OverOps与他们的自动部署模型集成在一起 。
OverOps提供了完整的自动根本原因分析，并有助于将识别和修复关键应用程序错误的时间减少90％以上。 这使公司能够提高应用程序的可靠性，员工效率，敏捷性和创新率。
加入我们即将举行的网络研讨会 ，了解您的团队如何识别已知和未知错误，如何通过自动根本原因（ARC）分析进行调查并将可靠性集成到软件交付供应链中。
447
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
