Rails 应用程序服务器的生命周期管理
我们正在开发一个具有 iPhone 客户端和 Rails 服务器的应用程序。我们已经发布了第一个版本，现在开始开发 1.1 版本。 我们想知道是否有任何工具（外部或由 Hostingrails 提供）来满足这两个基本要求： - Rails 应用程序的开发/生产版本 - 应用程序的同步实时版本（版本化 API），例如继续支持旧版本的客户端应用程序 iPhone。
我们现在考虑的第一种方法是为我们想要的 API 的每个版本复制应用程序，每个版本都由特定的 URL 引用，例如：myapp.com/v1 ，myapp.com/v2 ... 整个堆栈本身将被复制，以获得实时/生产版本和开发版本。一旦测试完成，开发版本将与生产版本切换。
您对这种做法有何看法？是否有任何工具可以管理应用程序的生命周期？ Rails 是否有内置功能可以促进这一点？
谢谢
We are developing an application that has an iPhone client, and a Rails server. We have released a first version, and are now starting to work on 1.1 version.
We were wondering if there are any tools (external or provided by hostingrails) to address those two basic requirements:
- development / production versions of a Rails application
- simultaneous live versions of the application (versioned APIs) for example to keep supporting older versions of the client application iPhone.
A first approach we are thinking of right now would be to duplicate the application for each version of the API we want to have, each of them being referenced by a specific URL for example: myapp.com/v1 , myapp.com/v2 ...
This entire stack would itself be duplicated in order to have a live/production version, and a development one. Once tested, the development version would be switched with the production version.
What do you think of this approach ? Are there any tools that allow to manage the lifecycle of the application ?
Does Rails has built-in features facilitating this ?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最简单的事情就是保持你的 API 向后兼容，从而避免维护两个版本的 API 的需要，如果你必须以破坏向后兼容性的方式发展它，那么弃用旧的 API 并给它一个真正的终止日期，这样你就不会无休止地支持它。
如果您绝对必须走这条路，请首先阅读 Fowler 关于该主题的博客文章 (http://martinfowler.com/bliki/TolerantReader.html)，然后查看 API 路由的命名空间。在 Rails 中，您可以使用命名空间路由和控制器来完成此操作，因此您的原始 api 可能位于
/application/endpoint，而新版本则位于/application/v2/endpoint（我假设您无法轻松更改旧客户端的端点）我不知道有任何工具明确声称可以解决您所说的想要解决的问题，但我认为这与开发人员努力工作而不需要它们，而不是认为它们在 Rails 中无法解决。
The simplest thing would just be to keep your API backward-compatible, thus obviating the need to maintain two versions of the API, and if you must evolve it in a way that breaks backwards compatibility, deprecate the old API and give it a real termination date so that you don't support it ad infinitum.
If you absolutely have to go down this road, read Fowler's blog post on the topic first (http://martinfowler.com/bliki/TolerantReader.html) and then look at namespacing your API routes. In Rails you could accomplish this using namespaced routes and controllers, so you might have your original api at
/application/endpointand your new version at/application/v2/endpoint(I'm assuming that you can't change your endpoints for old clients easily)I'm not aware of any tools that explicitly claim to solve the problems you're saying you want to solve, but I think that has more to do with developers working hard not to need them than the idea that they're not solvable in Rails.
您是否考虑过使用子域？：http://railscasts.com/episodes/221-子域-in-rails-3
Did you consider using Subdomains?: http://railscasts.com/episodes/221-subdomains-in-rails-3