devops和敏捷
敏捷宣言表示，我们重视工作软件。 反正什么是工作软件？
我们可以谈论在不同环境下工作的软件。 首先是非有形部分（比软件更有效）：
- 创意–我们将要制造的产品的创意必须合理并解决客户的问题
- 设计–我们需要适当解决问题的方法
- 组件–在某种程度上，组件需要正常工作。 我们可以通过单元和集成测试来证明这一点。
然后是整个软件部分：
- 已测试–功能位和非功能位
- 适合设计–做我们想要做的事情。 这是我们从测试中获得的见识。
- 适合目标–是否确实是用户真正想要实现的目标，而不仅仅是我们认为他们需要的目标。
然后还有另外一部分。 由于软件不会“终止”，甚至在发行时也不会终止，因此将会有软件的未来版本。 可能是明年，也可能是下一个冲刺，或者一天50次。 持续“工作”是指：
- 不要破坏任何以前起作用的东西
- 在每个版本中增加新功能的价值
正常运行的软件需要大量工作
其中一些是DevOps的工作。
但是，我们不仅要阐明所有技能。 取而代之的是，我们将使用敏捷的眼镜来了解DevOps的实践如何帮助我们在方法的每个步骤中“使用软件”。
在我们这样做之前，让我们检查一下眼镜。 敏捷是很多事情，但是所有方法论都尝试着重于通用原理。 我们将重点关注以下原则：
- 最小化风险–每种敏捷方法都可以帮助我们应对不确定性的海洋。 为此，我们将承担全面项目和实施的风险降至最低。 我们通过限制工作时间来做到这一点。
- 最大限度地减少浪费–注重有价值的工作和不断改进以减少浪费也是任何敏捷方法的一部分。 回顾是这里的关键工具，但是可视化和从实验中学习也对我们有帮助。
- 早期反馈–没有反馈，我们将无法最小化风险或浪费。 我们希望尽早获得反馈，显然是在最小化部分。
这三个原则指导我们采取更好的做法。 让我们看看它们如何在DevOps上下文中帮助我们在产品生命周期的不同阶段使用工作软件。
尽管构想和设计至关重要，但直到有实际开发时，DevOps的实践才不会出现。 当他们这样做时，我们会将它们与开发人员实践联系起来，但是它们实际上是大量DevOps实践的一部分。
- 最小化风险–源代码控制，分支方法
- 减少浪费–持续集成
- 早期反馈–单元和集成测试
源代码管理是开发的先决条件，IT负责（有时仍然负责）。 值得一提的是，不仅仅是因为拥有存储库可以最大程度地降低风险。 与许多事情一样，该工具不是重要部分，而是您如何使用它。
输入分支。 决定如何以及何时分支是DevOps技能。 通常，决策不是作为分析的一部分来完成的，更像是临时的，是暂时的。 但是它有有趣的副作用。
例如，我们可以决定每个人都将在中继上工作（例如，而不是在个人分支上）。 该决定具有何时以及多少代码合并的效果。 如果有数百人在后备箱上工作，我们会增加风险，并且为了减轻这种风险，我们将进行其他工作（例如在合并之前设置初步测试）。 或拆分代码库，这样我们就不会踩任何人的代码，也不会每天参与多个合并。
那是什么？ 您问XP的“集体代码所有权”规则在哪里？ 我并不是说所有开发都不应该由每个人都在每个代码上完成。 我的观点是，分支的方式会对开发，IT，运营等产生影响。
这导致我不断进行整合。 思维定势，而不是工具。 我们如何持续集成源自早期（但仍在发展）的分支决策。 当我们着手进行CI时，我们将建立所需的反馈周期来完成它。 CI自动化降低了出错的风险，但同时也减少了集成的浪费。 将其与不同的测试结合起来，我们就有了一系列很棒的实践来正确开发可运行的软件。
我知道你在想什么 这不是真正的DevOps实践，而只是开发。
它确实符合我们之前看到的与IT合作的开发人员的定义。 我相信您会同意，这是我们团队需要的一项技能，谁拥有它并不重要。
下次，我们将继续进行测试阶段，继续研究DevOps的原理和实践。
翻译自: https://www.javacodegeeks.com/2016/10/agile-introduction-devops-working-software.html
devops和敏捷