Czy instalatory Windows dla wewnętrznych aplikacji biznesowych mają sens?

Staram się zbudować ogólne zrozumienie tego, co jest wspólne w tej sytuacji, aby móc zdecydować, czy sensowne jest kontynuowanie tego.

1. Czy instalatorzy są mile widziani w typowym środowisku korporacyjnym z następującymi elementami?
   • Zmień proces kontroli
   • Środowiska deweloperskie / QA / produkcyjne
   • Wyznaczone zespoły wdrożeniowe dla różnych obszarów (zapora ogniowa, baza danych, okna itp.).
2. Czy istnieje „test lakmusowy”, który można zastosować do aplikacji, aby sprawdzić, czy jest ona dobrym kandydatem do stworzenia instalatora? *
   • Czy instalatory są na tyle proste, że każda aplikacja powinna je mieć?
   • Czy instalatorzy są nawet właściwym narzędziem?
3. Czy uzasadnione jest oczekiwanie, że programiści nauczą się czegoś takiego jak WiX do obsługi instalatorów?
   • Utrzymanie w ogóle jest problemem, tzn. Czy tworzenie instalatora to niszowa umiejętność?

*

Na przykład mam zestaw aplikacji winform, które znajdują się we współdzielonym katalogu na serwerze produkcyjnym. Określone grupy mogą uruchamiać aplikacje z tego katalogu, ale tylko administratorzy systemu mogą modyfikować pliki wykonywalne. Obecny proces wdrażania wymaga, aby administrator skopiował / wkleił pliki wykonywalne i biblioteki do katalogu współdzielonego.

Ponieważ aplikacje nie są instalowane na komputerze poszczególnych użytkowników, czy sensowne jest utworzenie instalatora do wdrażania nowych wersji tych aplikacji we wspólnym katalogu?

Edytować--

Czułem, że odpowiedzi tutaj udzieliły solidnych porad, dlatego chciałem podzielić się tym, co wymyśliłem dla mojego obecnego projektu, w którym musiałem zbudować dużą liczbę aplikacji i wdrożyć je w poszczególnych folderach.

Znalazłem pakiet NuGet o nazwie _PublishedApplications, który naśladuje zachowanie _PublishedWebsites dla projektów internetowych. Chodzi o to, aby zainstalować pakiet NuGet w swoich projektach i dodaje cel, który skopiuje artefakty kompilacji do katalogu _PublishedApplications na ścieżce wyjściowej. To zachowanie jest aktywowane poprzez uruchomienie MSBuild z wiersza poleceń i określenie outdirwłaściwości:

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

To da ci strukturę katalogów podobną do następującej:

• C: \ ścieżka \ do \ outdir
  • _Publikowane Aplikacje \
    • Projekt 1\
      • dlls, exes, etc.
    • Projekt2 \
      • ...

Stamtąd tworzenie zamka błyskawicznego, który można wyodrębnić w różnych środowiskach, jest dość bezbolesne.

Instalator zawsze ma sens, jeśli wdrożenie wymaga czegoś bardziej skomplikowanego niż skopiowanie odpowiednich plików do jakiegoś folderu i uruchomienie EXE. Jeśli konieczne są dodatkowe kroki, aby prawidłowo skonfigurować produkt, można to zrobić na dwa sposoby.

1. Możesz napisać listę do obserwowania. Ludzie są ludźmi, ktoś musi to zepsuć, a następnie zadzwonić do ciebie z prośbą o pomoc, ponieważ twój program nie działa poprawnie.
2. Możesz napisać listę do śledzenia przez komputer (skrypt instalacyjny). To sprawia, że ​​znacznie mniej prawdopodobne jest, że błąd użytkownika zepsuje wdrożenie.

Z drugiej strony, jeśli nie masz żadnych zadań instalacyjnych, które należy wykonać, po prostu daj im plik zip. To prostsze niż uruchamianie instalatora.

Wyatt zdejmuje kapelusz programisty i zakłada kapelusz dyrektora IT

Jeśli jest to wewnętrzna linia aplikacji biznesowych, wystarczy celować tylko w jedno środowisko - powiedział biznes. Zadzwoniłbym do szefa działu IT i zapytałbym go, jak chcieliby zarządzać wdrożeniem. Działy IT zajmują się tym od dłuższego czasu, więc mogą mieć silną preferencję dla opcji opartych na xcopy lub MSI lub czegoś innego, na przykład twojej obecnej opcji.

Dodam, że dział byłby co najmniej wdzięczny za ten gest i prawdopodobnie mógłby stać się cennym sojusznikiem, ponieważ są szanse, że wiedzą więcej o istniejącej linii aplikacji biznesowych i problemach, niż ci się wydaje.

Aplikacje Instalatora Windows są szeroko stosowane do instalowania wewnętrznych aplikacji biznesowych w środowiskach korzystających z systemu Windows. Powinieneś również zadać sobie pytanie, czy przez cały okres użytkowania aplikacji prawdopodobnie będzie trzeba ją zaktualizować, załatać, naprawić lub usunąć z systemów użytkownika. W wielu przypadkach odpowiedź brzmi „tak” - w takim przypadku posiadanie poprawnie napisanego instalatora może z czasem obniżyć całkowity koszt utrzymania aplikacji. Istnieją inne usługi i funkcje zaprojektowane do współpracy z Instalatorem Windows, takie jak Restart Manager i WMI oraz funkcje inwentaryzacji produktów i łatek. Jeśli Twoja aplikacja może z nich skorzystać, to kolejny powód włączenia instalatora.

Koszty początkowe związane z opracowaniem przydatnego instalatora dla aplikacji mogą się opłacić w dłuższej perspektywie, a koszty opracowania można zmniejszyć, wybierając odpowiednie narzędzie do tworzenia Instalatora Windows, takie jak WiX lub InstallShield lub inne.

Tak jak w przypadku wszystkich decyzji inżynieryjnych, to zależy.

Prawdopodobnie najważniejszym czynnikiem jest zrozumienie, kim jest konsument procesu instalacji i jakie umiejętności posiada zespół programistów.

Ponieważ jest to wewnętrzny, zakładam, że został wdrożony przez wewnętrzny dział IT. Prawdopodobnie nie są obcymi dowódcami pocisków.

Graficzne kreatory instalacji są przydatne w przypadku oprogramowania dystrybuowanego bezpośrednio do klientów zewnętrznych, ponieważ proste założenia dotyczące konfiguracji nie są już aktualne, takie jak lokalizacje serwerów plików, zasady zabezpieczeń itp. Dlatego też należy poprowadzić każdego użytkownika przez odpowiednie ustawienia ustawień.

W twoim środowisku te rzeczy są prawdopodobnie podyktowane przez programistów lub informatyków i rzadko się zmieniają. Dlatego polecam używanie skryptów powłoki do kopiowania plików w odpowiednie miejsce. Skrypty powinny znajdować się w produkcie jako część wydanego pakietu. Powinna również być kontrolowana wersja wraz z aplikacją.

Tam, gdzie pracuję, cała nasza aplikacja internetowa jest instalowana za pomocą kreatora InstallShield, który zadaje mnóstwo pytań, z których większość to lokalizacje systemu plików, informacje o połączeniu db i inne ustawienia, które kończą się w plikach konfiguracyjnych. Trudno zautomatyzować. Ponieważ instalacja aplikacji sieci Web w jej rdzeniu właśnie utworzyła kilka baz danych i kopiuje pliki, piszę nowy instalator za pomocą Ant lub Powershell, który po prostu uruchamia pliki .sql i kopiuje pliki.

Wtedy każdy może zrozumieć, jak to działa i utrzymywać go bardziej efektywnie.