Среда разработки Ruby (OS X против Ubuntu)

Question

Я разработчик, который использует RoR-CoffeeScript-Sass-Passenger-Apache. Мы используем EC2 для нашего развертывания, и у нас есть Macbook Air для разработки. В то время как сообщество rails очень подходит для Mac, из-за разницы в стеке развертываний в dev и prod я использую virtualbox + ubuntu, в то время как мои коллеги работают на OS X.

Наличие в OS X Native добавляет больше проблем, поскольку у нас больше зависимостей в стеке (Solr, Beanstalk, Mongodb и другие, что хорошо работает в Ubuntu)

Я ищу предложения о том, как разработчики Rails, использующие Mac и Amazon EC2, могут настроить свою среду разработки и разработки.

Также хотелось бы получить отзыв об использовании vagrant для распространения сред разработки для этого варианта использования.

Answer 1

Обычная практика - копировать ваш стек как «промежуточную» среду. С EC2 вы можете просто создавать AMI ваших существующих машин и дублировать их, включая их только для тестовых развертываний, и запускать свои тесты, чтобы убедиться, что все работает правильно, прежде чем развертывать их в рабочей среде. Или часто вы можете оставить его включенным навсегда, чтобы разработчики могли быстро развертывать обновления или исправления для тестирования по мере необходимости.

Выполнение этого гарантирует, что у вас будет точная копия вашей производственной системы для тестирования перед развертыванием, тем самым устраняя любые (катастрофические) проблемы, связанные с развертыванием, запускающимся в производство.

Answer 2

Наша команда уже три года занимается разработкой для Mac и развертыванием в Ubuntu на EC2, и у нее очень мало проблем. Несколько вещей помогли сделать этот процесс гладким:

1. Мы можем запустить весь стек приложений ** на Mac. Между macports, homebrew и сборкой из исходных текстов, когда это необходимо, нам удалось получить все технологии, которые мы используем в prod, работая на наших устройствах разработки. Способ, которым части конфигурируются и сочетаются друг с другом, различается локально (например, в prod мы автоматически обнаруживаем наш экземпляр memcached, тогда как локально он жестко запрограммирован), но каждую интеграцию можно проверить на Mac перед тем, как перейти к prod.

2. Наша система непрерывной сборки находится в той же настройке, что и наши коробки с продуктами. Это означает, что если вы включите какой-то код, который зависит от какой-то части магии, он обнаружится быстро.

3. Мы запускаем стэк (некоторые люди называют это промежуточным или целым) стеком, который настроен идентично производственному. Это иногда приводит к некоторым накладным расходам на разработку, но имеет столько преимуществ, что оно того стоит. Весь код проходит через этот стек, а затем передается в prod.

Эта установка работала достаточно хорошо, так что со временем мы позволили разойтись другим частям установки. Раньше мы выполняли пассажирские перевозки локально (как в prod), но теперь используем Pow. Мы регулярно экспериментируем с новыми версиями ruby ​​в течение некоторого времени, прежде чем обновлять остальную часть стека.

Мне приходилось разрабатывать с использованием виртуализированной среды для других проектов (OSX + CentOS в VirtualBox), и я определенно счел это более болезненным, чем у всех нативных. Для одного это было похоже на управление двумя машинами вместо одной. Все также чувствовал sloooooowww.

Если есть часть стека, которая является болезненной для работы на Mac, я определенно предпочел бы принять удар либо: а) тратить время на то, чтобы он работал локально, либо б) абстрагировать этот кусок, чем платить налог на работу с виртуальной средой.

** Я включаю в это обсуждение только приложение Rails и прямые зависимости. Например, мы используем puppet для настройки нашего парка EC2, но не запускаем его на наших устройствах разработки.