Эффективный способ сохранить прошлые проекты в их рабочей среде разработки?


19

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

Например, у меня есть проекты на Python, которые я создал в Linux, и это зависит от программных пакетов, которые легко устанавливаются в Linux, но у меня больше нет виртуальной машины Linux, которую я использовал. А некоторые другие мои проекты зависят от других переменных, таких как конфигурация веб-сервера, переменные PATH, SDK, IDE, версия ОС, устройство и т. Д.

Есть ли у кого-нибудь эффективный способ решения этой проблемы? На данный момент я заботился только о резервном копировании исходного кода, но трудно восстановить работающую среду разработки и также сложно поддерживать рабочую среду разработки .


6
АНБ моя резервная копия
Steffe

Ответы:


17

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


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

Это было то, что я делал в прошлом ... отлично подходило для поддержки различных клиентских сред и т. Д. Если вы используете базовую виртуальную машину, то каждая последующая виртуальная машина может быть просто файлом diff, который сэкономит место на диске, если это вопрос ... но лично я считаю жесткие диски дешевыми. :-)
davewasthere

С улучшением поддержки LXC это безопасно использовать вместо виртуальных машин при работе со средами Linux. Это намного менее требовательно к ресурсам и намного быстрее. Банкомат лучший инструмент для управления ими является докер
karka91

11

Моя любимая методология - поддерживать скрипт, который устанавливает ВСЕ необходимые зависимости для проекта, загружает исходный код и подключает все. Некоторые сценарии имеют два режима - один для производства, который обычно является подмножеством другого режима: разработки.

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

Если для настройки среды требуется больше времени (длительные установки, загрузка больших файлов и т. П.), Я делаю описанную выше процедуру один раз в неделю.

Преимущество заключается в том, что его очень легко развернуть на новом компьютере и / или на производственном сервере, все это задокументировано в сценарии, и сценарий проверяется очень часто.


4

Концепция, которую вы описываете, - это управление конфигурацией. Это, как это звучит, способ идентифицировать, записывать, версию / отслеживать и сообщать о среде. Часто это задача, которая тесно связана с управлением версиями и сборкой, но она достаточно четкая, для которой часто требуется отдельная стратегия, даже если в ней используются одни и те же понятия и одни и те же механизмы обработки и хранения.

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

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

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

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

Каждая система (и варианты) требует немного времени для настройки, но имеет определенную ценность, если вы считаете, что задача перезагрузки и перенастройки является обычной задачей.


Пожалуйста, не могли бы вы рассказать о том, какую стратегию вы упоминаете в своем заявлении «но она достаточно четкая, что часто требует отдельной стратегии»? Я собирался использовать Vagrant и хранить конфигурацию виртуальной машины в репозитории моего исходного кода, и мне интересно, в какой момент это будет рассматриваться по-другому?
CL22

3

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

Используя Docker, это также может улучшить другие части вашего рабочего процесса:

  • Созданная среда может быть помещена в тот же CVS, что и ваш проект, что дает вам версионную среду (аккуратно!)
  • Докер может использоваться для обеспечения живой среды, уменьшая головные боли при запуске ваших проектов в производство.
  • Если другие начинают работать с вами, все, что им нужно, - это файл Docker для загрузки этой огромной настройки среды.

Таким образом, идеи об использовании виртуальной машины верны лишь отчасти, я знаю, что жесткие диски становятся все больше и больше, но это не причина использовать все пространство, которое у вас есть. Кроме того, когда среде виртуальной машины требуется больше внутреннего пространства на жестком диске, это может быть немного сложнее, и есть вероятность, что вам потребуется ее перестроить. Хотя размер файла может и не быть проблемой, скорость интернета все еще становится узким местом, когда вам нужно отправить более 5Go по обычному соединению DSL.


2

Большинство систем (языки, среды выполнения или операционные системы) имеют какой-то стандартизированный способ установки программного обеспечения и конфигураций, поэтому попробуйте их использовать. Такие как:

  • Maven или Gradle для Java
  • CPAN для Perl
  • об / мин для RedHat / Fedora
  • dpkg / apt-get для Linux
  • Пакеты MSI для Windows

Затем сделайте инструкции по установке, поясняющие, что именно нужно установить / какие шаги необходимы:

  • Предоставьте короткие инструкции о том, что вы предполагаете установить (базовая ОС, базовая среда выполнения, такая как Java / Perl / Python ...)
  • Напишите короткий скрипт, который выполняет необходимые установки (в идеале всего один вызов такого инструмента, как Maven)
  • Проверьте это на новой установке (например, на виртуальной машине)

Тогда вы сможете воссоздать окружение, и другие тоже должны это сделать (что может быть важно, если это не сольный проект).

Возможно, вам потребуется где-то хранить необходимые установочные пакеты, или вы можете просто включить инструкции по загрузке (если система не отслеживает их, такие как apt-get или Maven). Это зависит от того, насколько вы доверяете поставщикам пакетов - вероятно, нет необходимости хранить основные пакеты Debian, но с небольшим проектом свободного программного обеспечения это может быть хорошей идеей.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.