部署协调工具？
我的公司维护着一个 SaaS 平台，我们即将发布一个相当重要的版本。 部署夜间活动需要一个大型跨职能团队，涵盖多个开发和团队。 质量保证小组、运营、专业服务和客户支持。
我们总是使用一个简单的任务列表和一个聊天室来协调发布窗口期间要完成的所有工作，但随着我们的发布变得更大、更复杂，管理如此多的任务和任务的调度和相互依赖性变得很困难。人们。 通常情况下，事情花费的时间比计划的要长，这会影响不同团队稍后进行的其他下游活动。 这可能会在部署过程中导致很多混乱，我们真的很想改进我们的实践。
有人知道支持此类协调活动的实时协作工具吗？ 也许人们对其他策略有更好的体验？
My company maintains a SaaS platform and we're approaching a pretty major release. Deploy night activities involve a large cross-functional team spanning several Development & QA groups, Operations, Professional Services, and Customer Support.
We've always used a simple task-list and a chatroom to coordinate all the work to be done during our release window, but as our releases become larger and more complex it has become difficult to manage the scheduling and interdependencies of so many tasks and people. Often times things take longer than planned, and this effects other downstream activities which are to occur later by different groups. This can lead to much confusion during the deploy, and we'd really like to improve our practices.
Is anyone aware of a real time collaborative tool which supports such coordination activities? Perhaps people have had better experiences with other strategies altogether?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们也有一个复杂的部署，我认为我们可能还需要在找到工具之前简化流程。 这就像最近的一篇生活黑客帖子，内容是在购买更多的整理工具（例如小塑料悬挂文件夹等）之前整理您所拥有的东西。 减少/重新思考/重新设计先前的实施应该意味着一个更干净、更简单的过程，可以通过像 rpm 这样的简单部署工具来实现。
我认为第一步是我们从基本目标开始重新思考这个过程，并努力推动每一项要求，并提出这样的问题：这会给我们带来什么？
如果在清晰度、降低风险或基本功能方面没有任何回报，那么就不需要再进行该过程了。
至少，这就是我解决问题的方法，并取得了一些成功。
We too have a complex deployment and I think we also may be in need of simplifying the process prior to finding a tool. It's like a recent lifehacker post about organizing what you have prior to buying more organization tools like little plastic hanging folders and the like. Reduce/Rethink/Redesign prior implementation should mean a cleaner easier process that could make due with simple deployment tools like rpm.
I think step one is for us to rethink the process from the base goals onward and to push hard on each requirement with the question: what-does-that-buy-us?
If there's no payoff for a step in clarity, risk reduction or basic functionality, then it doesn't need to be in the process any more.
At least, that's how I've been approaching problems here with some success.
我过去的经历：
- 每年很少有较大的版本 - 协调工作量太大，开发完成到发布之间的天数太长，并且完全破坏了您的上市时间。
然后我们每年尝试更多的小版本——更好的方法。 更多的事情需要管理； 但是，每个版本的大小都有很好的定义。 这也消除了需要单独的流程来发布错误修复和功能。
这些工具是如何派上用场的：清晰地维护需要发布的功能/错误修复，这些映射到需要构建的组件，构建的组件定义了需要在版本中推送哪些包。< /p>
My experience in the past:
- few larger releases per year -- too much effort to coordinate, too many days between dev complete to release, and completely ruin your time to market.
then we tried more small releases per year -- much better approach. more things to manage; but, size of each release is nicely defined. this also, eliminates the need for having a separate process to release bug fixes Vs features.
here is how the tools came in handy: clarity maintains the features/bug fixes that need to be released, these map to components that need to build, components that are built defines what packages need to be pushed in the release.