Process Playframework：升级过程--最佳实践

我非常感谢任何人分享您为一个无痛、万无一失的游戏框架升级而制定的最佳实践、模式、反模式、备份、回滚过程

我认为用最新版本替换bin/play目录可能会导致问题

编辑：

我在寻找更具体的版本管理策略，比如

a） 您是否只有/bin/play目录具有最新的播放版本或

---

b） 您是否保留了像/bin/play-1.1/bin/play-1.2这样的版本，并将$PATH更改为指向最新版本（缺点：您必须重建模块、依赖项&libs；优点：可以更好地控制回滚）

我更喜欢使用git从源代码安装play：

git clone git://github.com/playframework/play.git
cd play

# checkout specific version
git checkout 1.2.1

cd framework
ant
cd ..
ln -s $PWD/play ~/bin

所以我有一个完整的安装，包括所有源代码。后来，当play更新到版本1.2.2时，我执行了以下操作：

cd <play_home>
git pull
git checkout 1.2.2
cd framework
ant

---

从源代码构建运行play的优点是，您可以始终轻松地回滚到以前的版本，甚至可以测试当前开发中的功能。但这并不能解决同时激活多个版本的play的问题。

我同意Andre的观点。然而，如果您要求为一个实时项目提供最佳实践，我会采取不同的做法

您可以在本地计算机上安装多个版本。你唯一需要改变的是路径中哪一个是可见的。例如，您可以使用1.1、1.2、2.0，根据需要，只需修改

/home/youruser/.bashrc

文件即可

为什么从

git

或

hg

简单更新play将不起作用/这是一个好主意，因为如果出现问题，您必须还原、回滚模块，或者知道什么不起作用

最好是简单地交换播放版本，重建，广泛地测试，一旦你确定一切都很好，那么你就可以在一个实时站点中进行相同的更改

---

如果事情没有得到解决，或者你的计划毫无希望地丢失了，你所要做的就是将更改恢复到项目中，并切换播放版本。您将回到起点。

您尝试过升级吗？它可能很好用。但请确保您有备份。我已将应用程序从1.0.3.2升级到1.1，然后再升级到1.2，没有任何问题。模块越多，它就越复杂，但基本代码我没有任何问题。我在Windows 7上运行我的开发，并将每个版本的Play安装在c:\Play\Play-1.1 c:\Play\Play-1.2\等中。然后，我有一个命令行快捷方式，在启动时运行批处理文件，该快捷方式将路径设置为相关版本。我不使用太多的模块或依赖项，所以这对我来说也不是什么问题。谢谢Andre。这太棒了。在我结束这个问题之前，寻找更多的最佳实践（围绕数据库和其他外围领域）

play clean && play run