背景
专业服务部门为产品客户提供附加服务。
很多这些项目都很小(4-10 小时),需要快速周转。此外,这些都是重要的项目,因为它们是客户赖以开展业务的增强功能。
一些挑战是:
- 由于客户经常改变主意或提出微小的额外要求,因此需要进行大量返工或功能更改。除了很明显这是一个管理问题(管理范围蔓延等)之外,事实仍然是,在项目“上线”后经常需要实施一些小的调整。
- 有时,无论出于何种原因,某些事情都会发生故障,并且需要及时处理问题。同样,这些是客户依赖的生产过程。
目前,我们的发布管理非常临时:
- 工程师从头到尾管理项目,包括范围界定、客户关系、代码开发、生产部署和项目支持(针对任何后续问题)。
- 我们有开发服务器,也有生产服务器。服务器现场存在于服务器场中。他们从来没有备份过,他们没有冗余,因为他们不在科罗拉多——他们从运营中获得了二等服务。
- 他们的工程师拥有对 dev 和 prod 服务器的完全 root(linux)/admin(windows) 访问权限。他们在开发服务器上开发,当项目准备好时,部署到 prod(基本上,只需将文件复制起来)。当问题出现时,他们只是直接在服务器上工作。
- 我们使用 svn 进行源代码控制,但它基本上只是签出到 dev、处理项目、根据需要签入,然后通过将文件复制到服务器来部署到 prod。
问题:
问题基本上是上面的第2个问题。我们的产品服务器(在 colo 中)受到的操作并不像对待服务器一样尊重。我们需要服务器成为运营的一等公民。然而,他们的建议是将它们放在结肠中,这使它们无法触及。如果我们这样做,我们将需要通过操作来部署项目。基本上,这将是产品工程师在发布我们的软件产品更新时所经历的同样艰巨和痛苦的过程。
这将剥夺我们在响应这些小项目和出现需要立即关注的问题时的所有敏捷性。
问题
我们应该如何解决这个问题?我们是否应该将服务器放在 colo 中并只使用正式的发布流程?这种情况应该如何处理?
欢迎任何帮助使这个问题变得更好!