我正在为 20 个 scrum 团队寻找解决方案，关于如何在不同环境中推送代码：
这里的关键点是，许多团队会尝试推动 SIT，并且部署可能需要时间，并且可能会导致潜在的瓶颈。此外，我们需要确保我们的代码与真正的集成点（QA 环境）一起工作。 同样对于 Scrum，我们应该在什么时候将用户故事称为“完成”，什么时候推到 SIT 或 QA？
我确定以前有人问过这个问题，但找不到确切的术语，请随时指出。
编辑：它是一个全新的产品，白纸黑字，目前还没有代码或管道。
【问题讨论】：
标签： deployment continuous-integration devops scrum
好的，您的确切问题是：您什么时候完成用户故事？在 Scrum 中，当它可能可交付时它就完成了，所以在你的设置中：Stage。
现在，我认为这对您和您的团队来说是不切实际的。那是因为您在流程中遇到了许多障碍，您必须解决这些障碍才能真正完成 CI/CD 并在冲刺中拥有潜在可发布的代码：
持续集成。我不是指您使用的服务器和平台/工具。我的意思是实际上在每次签到时集成每个人的代码。如果你有 20 支球队今天不这样做，他们明天就不会突然开始。一旦你尝试，你就会遇到各种实践、流程和架构挑战。您需要通过这些工作才能实现这一目标。我最好的建议是让公共领域的团队不断相互整合，然后开始打破这些团队之间的障碍。如果这太多了，也许只是让每个单独的团队每天多次相互整合作为开始。老实说，如果你没有把它记下来，其余的步骤就不是很相关了。
测试是在其他地方发生的事情。它发生在不同的阶段、不同的环境中，并且可能发生在不同的团队中。这是一个问题，有两个原因。如果在故事被称为完成之后进行测试，它会强化团队的工作是编写代码，而不是创建工作的、可用的功能的想法。其次，那些错误报告会回来，然后已经完成和集成的东西必须重新设计、重做和集成。如果以前集成很痛苦，这只是增加了一个乘数。
您是否有跨职能团队致力于价值增量？我在这里猜测有点牵强，但服务存根和困难的集成通常表明不同的团队正在处理不同的组件。这会为错位创造很多机会，从而加剧您的挑战。
好的，最后一个。你有整个团队维护环境。这是一个很大的危险信号。这意味着您的系统要么非常复杂，要么人们留下了很多松散的结局，或者两者兼而有之。如果您必须围绕同步其他团队来构建整个团队，那么您可能会在您的问题上使用创可贴。您的环境应该是可预测和稳定的。这意味着与您的环境相关的大多数任务都应该是可自动化的，然后其他团队可以完成那些不是这样的奇怪任务。
这可能不是您所希望的答案，但这些可能是您实现目标必须解决的挑战。
【讨论】：