Ефективний спосіб збереження минулих проектів з їх робочим середовищем розвитку?


19

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

Наприклад, у мене є проекти python, які я створив у Linux, і це залежить від програмних пакетів, які легко встановлюються в Linux, але в мене більше немає VM Linux, який я використовував. А деякі інші мої проекти залежать від інших змінних, таких як конфігурація веб-сервера, змінні PATH, sdk, IDE, версія ОС, пристрій тощо.

Хтось має ефективний спосіб вирішення цього питання? На сьогоднішній день я займаюся лише тим, щоб зберігати резервну копію вихідного коду, але важко відновити робоче середовище розвитку, а також важко зберегти середовище робочої розробки .


6
NSA - це моя резервна копія
Steffe

Відповіді:


17

Те, що я робив у минулому, це або перетворити машину фізичного розвитку у VM, або, якщо це вже VM, зберегти її для подальшого використання. Це не так ефективно, як хотілося б для використання місця на диску, але простір коштує дешево. Крім того, цей процес є набагато дешевшим за часом, ніж намагатися перенастроїти середовище в майбутньому, якщо виникне потреба.


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

Це те, що я робив у минулому ... було чудово для підтримки різних клієнтських середовищ тощо. Якщо ви використовуєте базовий VM, то кожен наступний VM може просто бути різним файлом, що дозволить заощадити на диску на дисках, якщо це питання ... Але я особисто вважаю, що жорсткі диски дешеві. :-)
davewasthere

З покращенням підтримки LXC безпечно використовувати це замість VM для роботи з Linux. Це набагато менш вимогливо до ресурсів і швидше. Банкомат, найкращий інструмент управління ними - докер
karka91

11

Моя поточна улюблена методологія - підтримувати сценарій, який встановлює ВСІ необхідні залежності для проекту, завантажує джерело та підключає все. Деякі сценарії мають два режими - один для виробництва, який, як правило, є значною частиною іншого режиму: розробка.

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

Якщо для налаштування потрібне довше середовище (тривалі встановлення, великі файли для завантаження, щось подібне), я виконую описану вище процедуру раз на тиждень.

Перевага полягає в тому, що дуже просто розгорнути на нову машину та / або виробничий сервер, це все задокументовано в сценарії, а сценарій перевіряється дуже часто.


4

Концепція, яку ви описуєте, - це управління конфігурацією. Це, як це звучить, спосіб ідентифікувати, записувати, версію / трек та звітувати про середовище. Часто це завдання, яке сильно пов'язане з управлінням версіями та управлінням збіркою, але досить чітке, що часто вимагає окремої стратегії, навіть якщо вона використовує одні і ті ж концепції та ті ж механізми обробки та зберігання.

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

Як я вже говорив, часто це завдання, яке збігається з контролем версій джерела, і часто дані управління конфігурацією розташовані поруч із джерелом як в документації, так і в сховищі джерела. Це не повинно бути, але часто це стосується зручності.

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

Vagrant сприймає це в дещо іншому напрямку та забезпечує спосіб швидкого розгортання визначень віртуальної машини, таким чином, що в VM можна автоматично налаштувати своє віртуальне програмне забезпечення та апаратне забезпечення, і це може бути зручним способом відтворення певного представлення обладнання середовище, яке використовує користувач вашого програмного забезпечення.

Кожна система (і її варіанти) потребує трохи налаштування, але має деяке чітке значення, якщо ви вважаєте, що завдання перезавантаження та перенастроювання є загальним завданням.


Скажіть, будь ласка, про ту стратегію, яку ви згадуєте у своїй заяві, "але достатньо виразною, що часто вимагає окремої стратегії"? Я збирався використовувати Vagrant і зберігати конфігурацію VM у сховищі мого вихідного коду, і мені цікаво, в який момент потрібно було б по-різному ставитися?
CL22

3

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

Використовуючи докер, це також може покращити інші частини вашого робочого процесу:

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

Тож ідеї щодо використання VM лише частково праві, я знаю, що жорсткі диски стають все більшими та більшими, але це не привід використовувати весь простір, який у вас є. Крім того, коли середовище VM потребує більше місця на жорсткому диску, це може бути дещо складним, і, швидше за все, вам знадобиться його відновити. Хоча розмір файлу може не викликати проблем, швидкість Інтернету все ще стає вузьким місцем, коли вам потрібно надіслати понад 5Go на звичайному DSL-з'єднанні.


2

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

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

Потім складіть інструкції з встановлення, що пояснюють, що саме потрібно встановити / які кроки необхідні:

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

Тоді ви повинні мати можливість відтворити довкілля, і інші також повинні мати можливість це робити (що може бути важливо, якщо це не сольний проект).

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

Рішення VM також буде працювати, і, ймовірно, буде менше роботи в короткостроковому періоді (просто тримати VM). Однак я вважаю, що це рішення пропонує більшу гнучкість, наприклад, при зміні середовища.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.