Чи мають сенс інсталятори Windows для внутрішніх бізнес-додатків?

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

1. Чи вітаються монтажники в типовому корпоративному середовищі з наступним?
   • Процес управління зміною
   • Dev / QA / виробниче середовище
   • Призначені команди розгортання для різних областей (брандмауер, база даних, windows тощо).
2. Чи є "лакмусовий тест", який можна застосувати до програми, щоб побачити, чи це хороший кандидат для створення інсталятора? *
   • Чи достатньо прості установки, щоб кожен додаток мав його?
   • Чи встановники навіть правильний інструмент?
3. Чи доцільно розраховувати, що розробники дізнаються щось на зразок WiX для підтримки інсталяторів?
   • Ремонтопридатність взагалі викликає занепокоєння, тобто, чи створює інсталятор нішевий навик?

*

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

Оскільки програми не встановлені на машині окремих користувачів, чи має сенс створити інсталятор для розгортання нових версій цих додатків у спільному каталозі?

Редагувати--

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

Я знайшов пакет NuGet під назвою _PublishedApplications, який імітує поведінку _PublishedWepts для веб-проектів. Ідея полягає в тому, що ви встановлюєте пакет NuGet до своїх проектів, і він додає ціль, яка буде копіювати артефакти збірки в каталог _PublishedApplications на вихідному шляху. Ця поведінка активується за допомогою запуску MSBuild з командного рядка та вказівки outdirвластивості:

msbuild /p:Configuration=Release /p:outdir=C:\path\to\outdir MySolution.sln

Це дасть вам структуру каталогу, аналогічну наступній:

• C: \ шлях \ до \ outdir
  • _Опубліковані додатки \
    • Проект1 \
      • dlls, exes, etc.
    • Project2 \
      • ...

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

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

1. Ви можете виписати список для того, хто кого слідкує. Люди, будучи людьми, хтось зобов’язаний це накрутити, а потім зателефонують вам із проханням про допомогу, оскільки програма не працює належним чином.
2. Ви можете виписати список для комп'ютера, який слід слідкувати (сценарій встановлення). Це робить набагато меншою ймовірність, що помилка користувача призведе до розгортання розгортання.

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

Вайетт знімає шапку програміста і надягає свого директора з ІТ-капелюха

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

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

Програми Windows Installer широко використовуються для встановлення внутрішніх бізнес-додатків у середовищах, що використовують Windows. Ви також повинні запитати себе, чи протягом життя програми, швидше за все, його потрібно буде оновлювати, виправляти, відремонтувати чи чисто вилучити із систем користувача. У багатьох випадках відповідь "так" - у цьому випадку наявність належним чином написаного інсталятора може зменшити загальні витрати на підтримку програми з часом. Є й інші сервіси та функції, призначені для роботи з Windows Installer, такі як Менеджер перезапуску та WMI, а також функції інвентаризації продуктів та патчів. Якщо ваша програма може скористатися цим, то це ще одна причина включення інсталятора.

Попередні витрати на розробку корисного інсталятора для вашої програми можуть окупитися в довгостроковій перспективі, а витрати на розробку можна зменшити, вибравши відповідний інструмент для встановлення Windows Installer, такий як WiX або InstallShield або інший.

Як і у всіх технічних рішеннях, це залежить.

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

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

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

У вашому оточенні цей матеріал, ймовірно, диктується або розвитком, або ІТ, і рідко змінюється. Тому я рекомендую використовувати сценарії оболонки для копіювання файлів у відповідне місце. Сценарії повинні міститись у вашому продукті як частина пакета, який випускається. Він також повинен контролюватися версією разом із вашим додатком.

Там, де я працюю, весь наш веб-додаток встановлюється за допомогою майстра InstallShield, який задає купу питань, більшість з яких - це файлові системи, інформація про з'єднання db та інші налаштування, які лише закінчуються у конфігураційних файлах. Це важко автоматизувати. Оскільки установка веб-додатків по своїй суті просто створила пару баз даних і копіює файли, я пишу нового інсталятора за допомогою Ant або Powershell, який просто запускає файли .sql та копіює файли.

Тоді кожен може зрозуміти, як це працює, та підтримувати його ефективніше.