我正在为正在进行开发的许多解耦服务设置自动部署环境。虽然我对自动部署/配置管理方面感到满意,但我正在寻找有关如何最好地构建部署环境以使开发人员更容易一些的策略。需要考虑的一些事项:
我对持续部署的最大担心是我们拥有一个庞大的团队,而我不希望在开发人员在本地针对这些远程服务器的情况下不断重启服务。另一方面,将部署推迟到此开发环境会使集成测试变得更加困难。
您能否推荐过去在这种情况下使用过的策略?
答案 0 :(得分:0)
持续集成并不一定意味着持续部署。您可以在一天之内“连续”编译/单元测试/ etc代码,而无需部署它并且仅在晚上部署。无论如何,这通常是一个好主意 - 在晚上或按需部署 - 因为人们可能在白天进行集成测试,并且不希望代码库从它们下面更改。
考虑一下,开发人员可以在本地测试多少软件?如果很多,他们不应该不断地需要环境。如果不是很多,最好设置模拟/存根,以便在本地服务器上测试更多。然后,只有真正的集成测试才需要部署的环境,并且不需要在一天中不断更新。
答案 1 :(得分:0)
我建议设置CI服务器(Hudson?)并使用它来控制所有部署到QA和生产服务器。这会强制您自动化部署的所有方面,并确保开发人员不会对系统进行临时重启。
我还建议您考虑将构建输出发布到Nexus,Artifactory或Archiva等存储库管理器。这样,部署脚本可以检索以前版本的任何版本。使用存储库管理器可以使您的QA团队在部署到生产环境之前对其进行认证。
最后,考虑一种新兴的部署自动化工具。 chef,puppet,ControlTier等工具可用于进一步控制基础架构配置的版本控制。
答案 2 :(得分:0)
我同意Mark的建议,即使用Hudson进行构建自动化。我们似乎成功的持续部署项目使用Nolio ASAP(http://www.noliosoft.com)在构建完成后自动部署应用程序。如上所述,厨师,木偶等适用于中间件安装和配置,但是当您需要不断发布新的应用程序版本时,以应用程序为中心的平台(如Nolio ASAP)更适合。
您应该拥有最佳的IT操作人员来创建和批准应用程序发布流程,然后为开发人员提供一个界面,以便在批准的环境中运行这些流程。