我只想讨论我们的部署策略并找出其中的差异。这个过程就像这样
- >特定版本的开发完成
- >所有开发人员都将其文件提交到主干
- >使用TOAD比较数据库模式并迁移更改
- >在SVN上创建一个新分支
- >使用SVN导出(删除.svn文件夹等)
- >缩小JS,CSS
- >上传到登台服务器
- >执行测试周期
- >修复分支上的错误并验证它们
- >重新缩小JS,CSS [如果需要]
- >上传到生产服务器
- >当我说上传时,它意味着通过SSH上传文件 / var / www / html文件夹
- >首先上传js,css,images
- >然后上传php文件
- >在上传过程中排除用户上传的图片等目录
- >执行测试周期
- >修复错误并再次上传(可能需要重新缩小 - 几个文件)
- >验证错误
- >验证完成
- >将分支提交到svn
- >将更改合并回主干
- > commit trunk [在此部署周期中,没有人将任何文件提交到主干]
这个过程非常复杂,需要大量关注。
关于我们如何改进它的任何建议?
答案 0 :(得分:2)
我使用了以下部署路径。它消除了将文件重新上载到不同目录的许多需求。初始设置之后,您需要做的最复杂的工作是在每个测试位置进行“svn update”命令。
此设置假定您使用配置文件指向资产,图像和css等目录。
所有项目都有一个配置文件,允许用户设置开发数据库,共享图像等路径.config.dist.php很适合作为命名模式。然后每个签出将config.dist.php复制到config.php。这允许在没有SVN冲突的情况下进行许多配置。
每个配置文件通常都有一些代码,例如
<?php
#hopefully, your project can leave these first two constants set to '', because relative paths work for everything
define('localPath', '/home/www/projectName');
define('baseURL', 'http://example.com/~projectName');
#if you want to write everything over a shared filesystem for instance, uploads.
define('localAssetsDirectory', '/sharedFileSystem/localPath');
#if you want to include a shared assets directory
define('assetsURL', 'assets/images');
#OR if you want to host assets in one location.
define('assetsURL', 'http://assets.example.com/images/'
?>
生产和开发服务器上的所有测试版本只能由受限制的ips访问,并且只能放在.htaccess文件后面。 Apache配置为不提供.svn目录。
答案 1 :(得分:0)
如果您正在使用单元测试(例如Selenium),您可以使用构建工具编写所有这些脚本
如果没有,我会编写以下步骤:
和
由于您已经进行了分支和合并,因此您应该保持您的主干始终是具有最新功能的稳定版本。 最后,标记你的发布