Чи є причини, щоб не прийняти програмне забезпечення, що постачається, як віртуальну машину?

Це питання логістики, а не технічне питання.

Моя компанія передала в роботу деякі вбудовані програми. Зокрема, ми заплатили підряднику за розробку вбудованої системи, оскільки ми не маємо адекватних внутрішніх знань, щоб це зробити самостійно (у нас є лише розробники настільних додатків).

Отже, підрядники закінчили програмне забезпечення, і вони попросили, чи можуть вони доставити його нам у віртуальній машині. VM - це машина Windows 8, що містить попередньо налаштований CodeWarrior IDE з вихідним кодом як проект CodeWarrior. Ідея полягає в тому, що це дозволить нам вносити зміни коду в VM, який вже налаштований для подальшої розробки цього проекту.

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

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

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

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

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

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

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

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

Переконайтесь, що ви:

1. Отримайте вихідний код кожного випуску, який ви отримаєте від підрядника, і об'єднайте його у власну систему управління джерелами
2. Отримайте документацію про налаштування середовища VM та зможете відтворити її власне. Додайте документацію до джерела управління також

Додаткові переваги:

1. Якщо ви архівуєте випуски у форматі VM (збережіть .vhd або щось подібне), набагато простіше їх вставити і запустити кілька років вниз, навіть якщо оригінальна команда роздроблена або відсутня.
2. Набагато простіше запускати різні версії поряд.
3. З деякою інтеграцією VMWare (можливо, це можливо і з HyperV), ви можете інтегрувати їх у збірку CI автоматично.
4. Це економить час розробника (на початку), оскільки налаштування навколишнього середовища мало-мало.

Я б сказав, піди на це.

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

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

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

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

Інструмент Я експериментував з , щоб допомогти стандартизувати / автоматизувати створення нової машини Windows , є шоколадним .

Chocolatey NuGet - це менеджер машинних пакетів, дещо схожий на підхоплення, але побудований на увазі Windows.

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

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

Я би подумав, що договір на розробку передбачає результати та зобов'язання підрядника перед вами.

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

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

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

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

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

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

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

Я б їх також:

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

2. Сценарій для встановлення залежностей. Оскільки ви перебуваєте в ОС Windows, створити сценарій Chocolatey для автоматизації налаштування середовища розробки не повинно бути надто складно. Ви можете створити будь-які залежності, які ще не є шоколадними пакетами. Наприклад, ви можете встановити важкі комерційні інструменти, такі як Visual Studio і SQL Server через Chocolatey. Ці пакети встановлюють пробні версії, які є повнофункціональними, і їх можна розблокувати, ввівши ліцензійний ключ. Тож можливо, те ж саме можна зробити і з CodeWarrior, і будь-якими іншими залежностями, які ви маєте для свого середовища розробників.

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

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

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

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