问题描述
我一直在把我的脚趾放到网络开发技术的乐趣（ya，我应该得到更多），我有点震惊，因为缺乏明确的支持生产分期（即开发，测试，性能和生产环境）。实际上支持不是这个词;内容管理系统似乎积极地努力，以允许干净的分期。
目前我正在使用Drupal。我已经很难找到如何社区解决这个问题。我看过的大多数帖子建议重现在生产系统开发中完成的步骤（阅读这实际上缩短我的生活一点点）。我还听说将生产数据推送回开发人员，以便他们可以添加增量功能。这不可能是走的路，如果客户不希望你把他们的数据拉回你的开发环境怎么办？
最后我的问题： p>
您如何管理CMS的现实世界生产分期问题？
从推进到生产的背景，感觉像送人到月球，所以我可能需要放松一点。但是我仍然感兴趣的答案涉及源代码控制，允许生产回滚和测试。
我回答了一个。
还有一个。
我在哪里工作，我们正在做一个相当大Drupal部署。我们大致有以下设置。
所有开发人员都有一个本地沙箱（Drupal + DB）。提交代码到所有其他开发人员（我们大约有15个人）之间共享的分支。这包括由更新功能执行的配置更改。
当开发人员执行svn时，他们也运行update.php在本地执行任何配置更改。
我们有一个冲刺测试系统，运行简单测试，可以用于用户测试。
在sprint结束时（我们使用scrum），我们将分支合并到trunk中，并对此进行测试。
然后我们将其标记为发布版本并将其部署到现场（使用Capistrano），最后立即运行update.php以应用配置更改。
如果您想要更多详细信息，请从主干部署到留下评论。
I've been dipping my toe into web development technologies for fun (ya, i should get out more), and am a little shocked at the lack of clear support for production staging (i.e. development, testing, performance, and production environments). Actually support isn't the word; Content Management Systems seem to actively work against efforts to allow for clean staging.
Currently I am using Drupal. I have had a very hard time finding how the community solves this problem. Most of the posts I've seen recommend reproducing the steps done in development on the production system (reading this actually shortened my life a small bit). I also hear of pushing production data back to the developers so they can add incremental features. This can't be the way to go, what if the client doesn't want you pulling their data back to your development environment?
So finally my question:
How are you managing real world production staging issues for a CMS?
I come from a background where pushing to production feels like sending people to the moon, so I may need to relax a little bit. However I am still interested answers that involve source control, allow for production rollback, and testing.
I have answered a question on DB deployment strategies.
There is also a question on code deployment.
Where I work we are working on a fairly large Drupal deployment. We have roughly the following setup.
All developers have a local sandbox (Drupal + DB). The commit code to a branch that is shared among all of the other developers (there are around 15 of us). This includes configuration changes which are performed by update functions.
When developers do a svn up, they also run update.php to perform any configuration changes locally.
We have a sprint testing system which runs simpletest and can be used for user testing.
At the end of a sprint (we use scrum), we merge the branch into trunk, and run tests on this.
We then tag this as a release and deploy it to live (using Capistrano), finally run update.php on live to apply configuration changes to live.
Any emergency fixes get deployed from trunk to live as a dot release 7.1 etc.
If you want any more detail then please leave a comment.
这篇关于人们如何处理内容管理系统生产分期？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！