Есть ли причины не принимать программное обеспечение, поставляемое в качестве виртуальной машины?

Это вопрос логистики, а не технический вопрос.

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

Таким образом, подрядчики завершили работу над программным обеспечением и спросили, могут ли они доставить его нам на виртуальной машине. Виртуальная машина - это компьютер под управлением Windows 8, содержащий предварительно сконфигурированную среду IDW CodeWarrior с исходным кодом в виде проекта CodeWarrior. Идея состоит в том, что это позволит нам вносить изменения в код в виртуальной машине, которая уже настроена для дальнейшего развития этого проекта.

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

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

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

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

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

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

Хм, но я не считаю, что разработка завершена, пока не будет продемонстрирован проект по созданию стандартных машин разработчика и развертыванию на обычных серверах / клиентах.

В нескольких моих проектах мне приходилось изо всех сил стараться, чтобы программное обеспечение доставлялось таким образом. Это отличный формат.

Убедись, что ты:

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

Дополнительные преимущества:

1. Если вы архивируете релизы в формате VM (сохраните .vhd или что-то в этом роде), гораздо проще их запустить и запустить через несколько лет, даже если исходная команда была фрагментирована или ушла.
2. Гораздо проще запускать разные версии бок о бок.
3. С некоторой интеграцией VMWare (это может быть возможно и с HyperV), вы можете интегрировать их в сборку CI автоматически.
4. Это экономит время разработчика (в начале), потому что настройка среды практически отсутствует.

Я бы сказал, пойти на это.

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

Я был в такой же ситуации, как и раньше. Наша среда разработки - Windows / Cygwin, и в течение недели у нас был визит продавца, чтобы связать некоторый код интерфейса с нами. Они в основном используют Linux, поэтому мы настроили себя на виртуальные машины Linux на неделю, когда они были здесь. Когда они были здесь, это сработало довольно хорошо, и у нас было немного проблем с портированием в Cygwin после их ухода.

Мне кажется, что ты недооцениваешь свои собственные способности. Настроить IDE не так сложно, даже без рабочего примера для сравнения. Я был бы более обеспокоен нарушением лицензионных соглашений Windows и CodeWarrior. Если у вас есть соответствующая лицензия, вы можете получить поддержку от Freescale для любых проблем с настройкой.

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

Инструмент, с которым я экспериментирую, чтобы помочь стандартизировать / автоматизировать настройку новой машины Windows, - это Chocolatey .

Chocolatey NuGet - это менеджер пакетов компьютеров, похожий на apt-get, но созданный с учетом Windows.

Вы можете создать свои собственные пакеты Chocolatey довольно легко, а затем создать сценарий PowerShell, который установит и настроит практически все.

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

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

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

С точки зрения того, что что-то готово, я думаю, что VM вполне приемлема.

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

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

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

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

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

Я бы их тоже

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

2. Скрипт для установки зависимостей. Поскольку вы работаете в Windows, не должно быть слишком сложно создать скрипт Chocolatey для автоматизации настройки среды разработки. Любые ваши зависимости, которые еще не являются шоколадными пакетами, вы можете создать. Например, вы можете установить тяжелые коммерческие инструменты, такие как Visual Studio и SQL Server через Chocolatey. Эти пакеты устанавливают пробные версии, которые являются полнофункциональными и могут быть разблокированы путем ввода лицензионного ключа. Поэтому возможно, что то же самое можно сделать с CodeWarrior и любыми другими зависимостями, которые у вас есть для вашей среды разработки.

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

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

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

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