我正处于重组我们的颠覆过程和部署的计划阶段,以尽量减少代码丢失和生产部署问题。我们当前的系统只是简单地包括在随机服务器上创建一个子域名以在推送直播之前进行测试,这让我抓狂。
我想听听关于我当前计划的一些建议或意见,并获得有关如何使这个系统更好的反馈或想法。
细节:
- 小型开发团队。
- 开发和登台存在于同一台机器上。
- 生产版本存在于其他服务器上。
- 大约有 30 个项目与 Web 相关(网站、Web 应用程序、Web 服务)。
- 大约 30 个项目是桌面应用程序、DLL、组件、bat 文件等。
- 开发子域名只能通过 VPN 访问。
- Web 的暂存子域可公开访问。exe staging 只能通过 VPN 访问。
- 每个项目都将有一个 dev 和 staging 子域和存储库。开发版是登台主干的一个分支。
- 主要开发存储库:dev.domain.com(例如使用的通用名称)。
- 主要临时存储库:staging.domain.com(例如使用的通用名称)。
部署:
项目的开发版本是临时主干的分支。暂存保存特定项目的存储库。然后将文件手动复制到生产位置或执行部署脚本。
示例:开发人员使用从 projectname.projecttype.dev.domain.com (site1.web.dev.domain.com) 获取的本地副本。对本地版本进行更改并合并到项目开发分支进行测试。完成所有测试后,分支将合并到项目主干中。如果项目主干通过所有测试,则项目将被实时推送。
Subversion 存储库结构: *注意:文件结构将匹配域名结构。*
开发分支:始终在此服务器上向本地开发环境签出。
dev.domain.com
web.dev.domain.com
site1.web.dev.domain.com
site2.web.dev.domain.com
exe.dev.domain.com
app1.exe.dev.domain.com
app2.exe.dev.domain.com
暂存主干:开发人员从未接触过。只有将分支合并到特定项目的主干中才能更新文件。在推送现场之前测试安装。应假定具有生产能力,但客户无法访问。
staging.domain.com
web.staging.domain.com
site1.web.staging.domain.com
site2.web.staging.domain.com
exe.staging.domain.com
app1.exe.staging.domain.com
app2.exe.staging.domain.com
这看起来怎么样?我是否缺少或将失去任何功能?他们是我应该使用的更好的系统吗?