在软件开发领域，有许多人能够按照指示完成任务，但只有少数特别的人能够成为决策者。是什么让后者如此特别？是他们思考周围事物的方式。他们以自己的能力提出问题并进行自研究，他们不会盲目依赖伟人所说的东西，他们挑战并在这个过程中获得掌握，塑造自己成为决策者。
遵循上述哲学，本文将专注于“为什么应该选择它”而不是“如何”。这里的“它”指的是“持续集成、构建与部署”。明确地添加了部署这个词，因为觉得它是一个相当相关的术语。不会过多地涉及乏味的理论，但会用简单的语言来包装它。它是一个自动化的过程，可以持续构建项目并部署它。
让尝试回答应该关心的问题，即“为什么应该选择它”。采用持续集成、构建和部署有很多驱动因素——将一一访问它们。在阅读本文时，不要考虑“如何”。有各种在线资源可供大多数人利用。很少有人会提供知识来决定它是否适合场景。在本文结束时，相信中的许多人将能够在这方面做出更好的决策。
从现在起，将把“持续集成-构建和部署”称为CIBD（是的，很懒:)）
想象一下集成和部署团队所花费的努力。每当需要发布/补丁时，可怜的人不得不在办公室度过夜晚以实现可怜的成功。真正的痛苦是构建时间，寻找-协调错误修复，单元测试，烟雾测试，测试团队协调，创建-部署部署包和通知利益相关者等等。这是一个相当长的清单。迫切需要自动化，答案是采用CIBD。
CIBD将自动执行项目构建过程，通常是在源代码控制服务器上的每次代码提交后，如果有任何错误，它会抛出错误。这将确保错误能够及时被发现并修复，从而避免在最后一刻发现问题导致的交付延迟。
错误指的是构建错误、断开的链接或任何其他可怕的错误。错误会给人带来很大的麻烦，第一个挑战是找到它们，更大的挑战是解决它们。特别是在构建需求不频繁的情况下。在这种情况下，当集成器开始集成所有模块时，他/她会发现其中有很多致命问题，然后一切都会堆积到一个程度，导致交付推迟。有时，它为客户创造了关键的业务风险。为了纠正这一点，CIBD是解决方案。
CIBD会持续构建代码块，最好是在源代码控制服务器上的每次代码提交后，并在发现任何错误时抛出错误。罪魁祸首（中的一个人）将被迫修复它。有了CIBD，肯定会纠正最后一刻的恐怖发现，并帮助顺利交付。
有了CIBD，可以通过源代码控制提交日志轻松找到导致构建失败的罪魁祸首。这将在团队成员心中植入积极的恐惧——没有人愿意他/她的名字因错误行为而被突出显示，并面临夸大的指责，使他们在提交任何内容到服务器之前对代码和单元测试格外小心。这将纠正很多返工。
为了实现大规模自动化，可以加入一些辅助工具，如静态代码分析工具、自动化单元测试工具、代码覆盖率工具、自动化系统测试工具、健康监控器、配置管理工具。添加这些将使整体流程更加强大，并进一步节省时间、努力和成本。
这是分析的时代——预测性的、描述性的，无论任何*性。CIBD将为提供构建的统计数据，包括成功、失败比率，以及团队基础的分割，无论想到什么，都会以非常花哨的图表显示。这在向管理层炫耀报告时将非常有用。