Настройка нескольких сред разработки

Question

Я сольный разработчик, работающий над типичным веб-проектом (Django + PostgresSQL), использующим Eclipse в качестве моей IDE и Subversion для управления исходным кодом. До сих пор я работал над одной машиной для разработки, которую я настроил сам. Недавно меня попросили сделать какую-то работу на сайте клиента, а также было несколько случаев, когда было бы полезно иметь доступ к сайту дома. Я думаю о том, как лучше всего это настроить. К сожалению, по разным причинам ноутбук не является жизнеспособным решением, поэтому я думаю о следующих решениях:

1. Установка всех необходимых инструментов разработки на каждой машине (PostgresSQL, Eclipse, Django, Python + библиотеки и т. Д.) И синхронизация кода с использованием SVN.
2. Настройка какого-либо доступа к VNC на моей машине для разработки и удаленный доступ к нему для выполнения работы.
3. Создание виртуальной машины и копирование образа между всеми машинами с помощью пера.

Преимущество # 1 - быстрая локальная разработка, но тогда мне нужно настроить все инструменты на каждой машине, разобраться с их конфигурациями и поддерживать все в синхронизации. Кроме того, чтобы поделиться кодом между машинами, я должен проверить его в SVN, даже если он не «готов». Решение № 2 решает эту проблему, но за счет более медленного пользовательского интерфейса. Наконец, # 3 кажется хорошим решением, но я не уверен, смогу ли я действительно разместить виртуальный образ на перьевом диске, и я не уверен в производительности.

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

Answer 1

Я бы сказал, что вариант № 1 все еще лучший. Я бы предположил, что у вас дома только один компьютер, и вы можете работать без него, поэтому, надеюсь, установка будет единовременной.

Вы правы, хотя время установки довольно утомительно, однако на самом деле оно компенсирует медленный пользовательский интерфейс использования чего-то вроде VNC для удаленной работы. Ваша проблема с фиксацией кода, который может не работать, является допустимой, однако, если вас это беспокоит, просто закомментируйте испорченный код и убедитесь, что ваша последняя версия компилируется.

Работа через репозиторий является наиболее эффективным методом, особенно если вы работаете над довольно крупным проектом. Жаль, что у вас нет ноутбука, а настройка всех инструментов на ноутбуке делает кодирование / работу из любого места (при наличии подключения к Интернету) особенно удобным.

В любом случае, я предпочитаю вариант 1, надеюсь, он поможет.

Answer 2

Кроме того, чтобы поделиться кодом между машинами, я должен проверить его в SVN, даже если он не «готов».

Git очень решает эту проблему явно. Что касается разработки в автономном режиме, вы должны попробовать Git. Это делает управление автономными репозиториями действительно простым. А из-за своей распределенной архитектуры предлагает несколько удобств при перемещении между средами. Он был разработан для частой проверки рабочего процесса. Я думаю, вы найдете, что он предлагает то, чего нет в SVN.

Например, вы можете хранить разные репозитории для разных сред и легко объединять изменения между ними. Таким образом, вы можете иметь репозитории, связанные с вашими образами виртуальных машин. И они могут резко расходиться, но все же легко объединиться.

Слияние - это то, что делает Git такой мечтой для использования.

Смотрите эти две презентации для хорошего обзора.

Линус Торвальдс о Git (подробнее о философии дизайна Git)

http://www.youtube.com/watch?v=4XpnKHJAok8

Презентация Рэндалла Шварца (более практический обзор)

http://www.youtube.com/watch?v=8dhZ9BXQgc4

Answer 3

Использовать контроль версий. Если вы беспокоитесь о проверке «неполного» кода, используйте ветки (ветка для разработки) или теги (тег «завершенный» код). У фиксации «в процессе» работы есть свои преимущества (хорошая отмена, помогает писать хорошие журналы изменений и т. Д.). Кроме того, документирование процесса «настройки», чтобы его было проще воспроизвести, также хорошо.

Answer 4

Запуск виртуальной машины с флешки (даже быстрой, а большинство нет!) Отнимает много времени.

Вы можете скопировать его локально или использовать жесткий диск USB или даже решение, например Live Mesh, для его синхронизации.

Answer 5

Если машины имеют порты e-sata , возможно, это . Почему бы не сделать комбинацию из одного и трех, создать базовую виртуальную машину, развернуть ее на всех ваших машинах одновременно и поддерживать синхронизацию кода с помощью SVN или другого инструмента синхронизации? Если вы не хотите постоянно проверять и отключать систему контроля версий, что-то вроде drop box позволит вам синхронизировать рабочие каталоги до тех пор, пока вы не возражаете против возможности просмотра третьей стороной. Ваш код, хотя они, вероятно, не будут беспокоить. Другой вариант - создать «рабочую» ветку, в которую вы всегда входите и выходите, и перемещаете код в транк только тогда, когда он достаточно стабилен и несколько закончен.