持续集成与敏捷软件开发
如今在生产方式上存在很多复杂因素和障碍。现在，如果你不敏捷，它实际上是一个地狱，增加了新的功能。因此，许多公司和初创公司转而采用敏捷方法，并开始使用CI来实现软件开发的灵活性。
关于敏捷转型的公司有很大的嗡嗡声，例如芒果，汇丰银行，Edreams等许多公司正在进行敏捷转型。这似乎很容易，但实际上对于大公司而言，改变他们已建立的所有流程并改变思维方式是一项挑战。但在这个快速发展的世界里，现在是必须的。
说实话，你会发现很多公司声称它们是敏捷的。这是问题所在，不幸的是，每家公司都不同地理解敏捷。在Apiumhub，我们为不同行业的不同国际公司和小型创业公司工作，并得出结论，要真正实现敏捷，您必须做TDD和CI。在本文中，我想讨论持续集成在敏捷软件开发中的重要性。
首先，为了保持同一页面，让我们看一下软件开发中敏捷方法的核心。敏捷意味着持续，迭代和渐进的演变。它可以帮助软件开发团队保持专注，无论环境如何变化，都可以让团队适应它们，同时确保快速交付价值。为什么？因为它基于快速反馈，灵活性，团队输入，持续改进和高质量结果的交付。
多年来，软件开发团队一直在使用敏捷开发方法来提高软件质量和流程质量。这种迭代和增量开发实践帮助他们找到通过协作开发发展的解决方案。而且他们中的大多数人会告诉你，没有什么可以像团队对持续集成的承诺那样构建或破坏敏捷性。投资CI可以快速反馈代码变化，节省了大量的金钱和时间。以传统方式，主要依赖于手动测试的团队可能会在代码更改后的几个小时甚至几天内收到反馈。在这段时间内，会进行其他更改，并且很难确定问题。
什么是持续集成(Continuous Integration)
我们是Martin Fowler的忠实粉丝，我们总是阅读他的博客并强烈支持他的观点。他说，持续集成是一种软件开发实践，需要团队成员经常将代码集成到共享存储库中。基本上每个人至少每天集成一次，这导致每天多次集成。集成通过自动构建进行验证，该构建运行回归测试以尽快检测集成错误。通常，一旦团队成员实施了CI，他们就永远不会切换回来，他们坚持持续集成，因为他们发现CI导致更少的集成问题，并且能够更快地开发高质量的软件。
很多人说它最初被用作极限编程（XP）的一部分。正如通常有几个人在同一个项目上工作一样，CI可以帮助开发人员跨越彼此的代码并防止集成问题。CI与配置管理，编译，软件构建，部署和测试等其他最佳实践协同工作，从而创建单一自动化和可重复的流程。
持续集成可帮助软件开发团队真正实现敏捷，适应快速的业务变化，确保正在开发的软件保持同步。在每一天结束时，他们知道他们的代码工作正确并且正确集成; 组件一起工作。即使某些东西没有整合或某些东西不起作用，它也很快被发现。
CI规则规定程序员不要在一天结束时留下任何未整合的东西。这是非常重要的！构建不应该在破碎的状态下过夜。此外，无论谁在办理登机手续时打破了建筑物，都必须再次修理。
持续集成(CI)与测试驱动开发(TDD)
如果持续集成的想法是快速发现问题，给每个开发人员提供有关其工作的反馈，那么必须有一种方法来快速评估该工作。测试驱动的开发 - 另一种敏捷方法填补了这一空白。基本上使用TDD，您可以构建测试，单元测试，然后开发功能，直到代码通过测试。随着代码的每个新增功能，其测试可以添加到构建集成工作时运行的测试套件中。这可确保新添加的内容不会破坏现有代码。并且可以快速通知“打破构建”的开发人员以在早期阶段解决问题。
将持续集成与测试驱动的开发相结合，使更多人处于敏捷的保护伞下，因为它允许敏捷方法更有效地工作，相互完成。
作为CI的TDD为您提供快速反馈 - 敏捷方法论的关键要素。TDD和CI确实简化并加快了开发新软件的过程，使得通过可靠的MVP尽可能快地推出新的可扩展产品成为可能。
CI的好处
现在，让我们更深入地了解CI，看看它为敏捷软件开发团队带来的关键优势。
-
降低风险
更频繁地集成代码可以降低失败风险，降低重做工作超支的风险。经常集成工作意味着应用程序的当前状态与开发人员拥有的应用程序状态之间的差距较小，这意味着假设的范围会减少，并且每个人都停留在同一页面上。
-
快速查找问题
在持续集成测试的帮助下，定期进行检查并立即发现问题。就像在房子里有火警。它警告软件开发团队何时出错以防止出现大问题。
-
自动化流程
敏捷就是效率。使用CI可以节省大量时间，自动执行重复的手动过程，这很慢。
-
质量保证
持续集成有助于随时发布可部署的软件。从客户的角度来看，这是一个至关重要的好处，因为不遵循此方法的项目通常会遇到延迟发布。此外，CI可帮助软件团队忘记发布周期与部署产生的无法预料的问题。
-
对质量软件的信心
持续集成的应用为生产高质量软件提供了更大的信心。每次构建时，软件团队都知道测试是针对软件运行的，以验证行为，遵守项目编码标准，结果是功能可测试的产品。
-
整个团队的透明度
测试结果应显示在构建管道上。如果构建通过，则会增加团队的信心。如果失败，开发人员可以轻松地要求他的团队成员帮助他确定可能出错的地方。测试应该是团队成员之间透明的过程。
敏捷转变软件开发，使其更容易，可扩展，更灵活，更快捷。我真的希望在阅读完我的文章之后，你确信敏捷正在做TDD和CI。这是您的安全网，快速找到您的错误，修复它们并构建工作软件。当软件团队应用CI时，他们不怕添加新功能并破坏现有代码。他们知道，通过这样做，他们比其他团队更有效率，敏捷团队是能够快速获得反馈并快速应对不断变化的环境的团队。CI使适应性，灵活性，可扩展性，可维护性和质量成为可能。
至于业务，持续集成有很多好处; 将产品更快地推向市场，更好地响应不断变化的需求，小频繁迭代，不断发展等。这为客户创造了可扩展的优质产品，这是敏捷性的前提。
For new contacts with Agile, project managers and scrum protagonists may look similar or even the same. But it is important to recognize the differences between the two, the possible overlap of certain tasks, and how they complement each other in large projects. ( 对于刚接触Agile的人来说，项目经理和scrum主角可能看起来相似甚至相同。但重要的是要认识到两者之间的差异，认识到某些任务可能重叠的地方，并认识到它们在大型项目中如何相互补充。)
Roles are key in Agile: The business fable of The Chicken and the Pig explains breakfast: pigs and chickens in the Scrum process. It’s a way to differentiate between roles in the Scrum/Agile world. (角色是敏捷的关键：鸡和猪的商业寓言解释了早餐：在Scrum过程中的猪和鸡。这是一种区分Scrum/Agile世界中角色的方法。)
Scrum Master is considered to be a project manager in many projects, which is actually a misunderstanding. At the same time, I often see people who argue that Scrum Master is completely different from project managers. So what is Scrum Master’s responsibility? What can we do to become a qualified Scrum Master? ( Scrum Master被认为是许多项目开发中的项目经理，这实际上是一种误解。与此同时，我经常看到那些主张Scrum Master和项目经理完全区别的人。那么Scrum Master的责任是什么？我们可以做些什么来成为一名合格的Scrum Master？)
Without a good product owner, the Scrum project will not succeed. It must be decisive, not only by referring to the required responsibilities, but also by embedding the following thinking patterns: 1) To continuously protect the best interests of customers in terms of functions provided. 2) Protect the organization as a whole in terms of strategic direction and return on investment. (如果没有一个好的产品所有者，Scrum项目就不会成功，他必须具有决定性，不仅要求提到所要求的责任，而且还要嵌入以下思维模式：1) 在提供的功能方面不断保护客户的最佳利益，2) 在战略方向和投资回报率方面保护整个组织。)
Role and Responsibilities - The product owner who represents the company’s ownership of the product is a member of the Scrum team. However, the product owner has no authority over other members of the team, as is the case with Scrum Master. The product owner is responsible for the long-term care of the product and the success of the product. (代表公司拥有产品的产品负责人是Scrum团队的一员。但是，产品所有者对团队中的其他成员没有权限，与Scrum Master相同。产品负责人负责长期照顾产品，并负责实现产品成功。)
Scrum in a Nutshell: Scrum relies on which are periods of time when software development is actually done. A Sprint usually lasts from one week to one month to complete an item from the backlog. The goal of each Sprint is to create a potential shippable product. (Scrum依赖于软件开发实际完成的时间段。冲刺通常持续一周到一个月，以完成积压的项目。每个冲刺的目标都是创建一个潜在的可交付产品。)
A product owner is the guardian of the product vision and goals, because it focuses on delivering business results and values for Scrum projects. So the question is how to be the best product owner? Based on our experience, we believe that the product owner should possess some key qualities. (产品所有者是产品远景和目标的守护者，因为它专注于为Scrum项目提供业务结果和价值。所以问题是如何成为最好的产品拥有者？根据我们的经验，我们认为产品所有者应该具备一些关键的品质。)
A self-organizing team is a team that has the autonomy to choose how best to do its work, rather than being guided by others outside the team. ( 自組織團隊是一個團隊，擁有自主選擇如何最好地完成工作，而不是由團隊外的其他人指導。)
The Scrum team shares different tasks and responsibilities related to product delivery. Every role is closely related. It is recommended that Scrum team members work together in the same place as possible. Let’s look at these roles from the perspective of responsibility, authority and characteristics. (Scrum團隊分享與產品交付相關的不同任務和職責。每個角色都密切相關。建議Scrum團隊成員盡可能在同一位置一起工作。讓我們從責任，權限和特徵的角度來看看這些角色。)
The main goal of Scrum rules is to optimize the development process and minimize waste of time. Scrum Master is responsible for ensuring that everyone follows Scrum project-related rules. These rules combine Scrum processes so that everyone knows how to play. (Scrum規則的主要目標是優化開發過程並最大限度地減少浪費的時間。在Scrum Master的是負責確保每個人都遵循的Scrum與項目相關的規則。這些規則將Scrum流程結合在一起，以便每個人都知道如何玩。)