Управление жизненным циклом сервера приложений Rails

Question

Мы разрабатываем приложение, которое имеет клиент iPhone и сервер Rails.Мы выпустили первую версию и сейчас начинаем работать над версией 1.1.Нам было интересно, есть ли какие-либо инструменты (внешние или предоставляемые hostingrails) для удовлетворения этих двух основных требований: - версии для разработки / производства приложения Rails - одновременные живые версии приложения (API с поддержкой версий), например, для поддержки старых версийклиентское приложение iPhone.

Первый подход, о котором мы сейчас думаем, состоит в том, чтобы дублировать приложение для каждой версии API, которую мы хотим иметь, на каждую из которых ссылается конкретный URL, например: myapp.com / v1 , myapp.com / v2. .. Весь этот стек сам будет продублирован, чтобы иметь живую / рабочую версию и версию для разработки.После тестирования версия разработки будет заменена на рабочую версию.

Что вы думаете об этом подходе?Существуют ли инструменты, позволяющие управлять жизненным циклом приложения?Имеет ли Rails встроенные функции, облегчающие это?

Спасибо

Answer 1

Простейшей вещью будет просто поддерживать ваш API обратно совместимым, что устраняет необходимость поддерживать две версии API, и если вам нужно развить его таким образом, чтобы нарушить обратную совместимость, отказаться от старого API и дать емуреальная дата прекращения, чтобы вы не поддерживали ее до бесконечности.

Если вам абсолютно необходимо пойти по этому пути, сначала прочитайте пост Фаулера в блоге по этой теме (http://martinfowler.com/bliki/TolerantReader.html), а затем посмотрите на пространство имен вашего APIМаршруты. В Rails вы могли бы сделать это с помощью маршрутов и контроллеров в пространстве имен, поэтому у вас может быть свой исходный API на /application/endpoint и ваша новая версия на /application/v2/endpoint (я предполагаю, что вы не можете легко изменить конечные точки для старых клиентов)

1007 * Я не в курсе каких-либо инструментов, которые явно претендуют на решение проблем, вы хотите сказать, что вы хотите решить, но я думаю, что имеет больше общего с разработчиками, работающими трудно не нуждаться в них, чем идеячто они не разрешимы в Rails.

Answer 2

Рассматривали ли вы использование поддоменов ?: http://railscasts.com/episodes/221-subdomains-in-rails-3