Musi istnieć lepszy sposób niż tylko „publikowanie” w Visual Studio, a następnie konieczność ręcznego przesyłania FTP zmienionych plików?
Brzytwa Ockhama jest zazwyczaj preferowanym podejściem: im prościej, tym lepiej. FTP jest łatwy i nie wymaga żadnych komplikacji. Niektóre osoby używają XCOPY, Filezilla lub WSFTP, inne mogą korzystać z narzędzia MS Web Deployment Tool (którego jeszcze nie znam), ale ogólnie rzecz biorąc, istnieje lepszy sposób wdrażania aplikacji internetowych ASP.NET (i innych aplikacje ogólnie). IMO, jeśli wdrażanie jest brane pod uwagę od samego początku rozwoju, wdrożenie można zintegrować z aplikacją internetową, co zapewnia względnie bezbolesne i płynne wdrożenie w przyszłości.
Jako programista .NET, który pracował w kilku firmach tworzących aplikacje internetowe ASP.NET o różnych rozmiarach, złożoności i liczbie użytkowników (od kilkuset użytkowników do dziesiątek tysięcy), „wdrożenie” IMO jest często najbardziej „płynnym” tematem. Niektóre organizacje idą za daleko pod względem biurokracji, podczas gdy inne nie rozwiązują żadnych problemów z wdrożeniem. Z mojego doświadczenia wynika, że problemy z wdrażaniem należą do co najmniej jednej z 3 kategorii pod względem trudności / awarii:
Wdrażanie jest dogłębnie ignorowane / zapomniane na etapie projektowania:
większość aplikacji internetowych zwykle zawiera serwer WWW i bazę danych. Oprócz kodu aplikacji, być może niektórych procedur przechowywanych i tabel bazy danych, wdrożenie nie wymaga wiele przemyślenia. ASP.NET jest więcej niż w stanie pomóc we wdrożeniu, ale najczęściej programiści są rozproszeni, jeśli chodzi o uruchomienie rzeczywistej aplikacji i wykonanie jej zadania, pozostawiając sposób wdrażania jako osobny problem.
Wdrożenie jest skomplikowane w wielu systemach i ludziach:
Złożoność to dziwka. Od MSMQ, procedur przechowywanych T-SQL i wyzwalaczy, Reporting Services, przesyłania komunikatów SOAP / XML, uwierzytelniania AD, SSAS / SSIS itp. Itd. Liczba stosowanych technologii zwiększa liczbę zaangażowanych osób. Co najgorsze, wszystkie te różne składniki są zazwyczaj zarządzane przez różne podmioty w organizacji. O ile wszyscy nie są ze sobą zsynchronizowani, wdrożenia mogą szybko wzrosnąć, co prowadzi do wielu punktów awarii.
Lenistwo, apatia lub brak komunikacji i / lub zarządzania:
Od małej dokumentacji do braku dokumentacji po brak skoordynowanej komunikacji i protokołu, łatwo jest popsuć stosunkowo prosty proces. Wdrożenie powinno być prostą procedurą z licznymi kontrolami przez cały czas dokumentującymi co zostało zrobione, ale często tak nie jest. Większość ludzi chce, żeby ta cholerna strona działała. Z mojego doświadczenia wynika , że ludzie (nie-programiści) tak naprawdę nie dbają, dopóki coś nie stanie się naprawdę fubarowe. Odpowiedzialność rzadko spoczywa na jednej osobie, która faktycznie wykonuje wdrożenie, ponieważ nikt tak naprawdę nie chce być przyczyną niepowodzenia, więc odpowiedzialność jest zwykle rozproszona.
Jest tak wiele wyjątkowych plików, że wolałbym maksymalnie zautomatyzować ten proces, aby zapobiec przypadkowemu przesłaniu. Jak więc robi to Twój zespół?
Nie znam żadnych dostawców, którzy mogliby zautomatyzować wdrażanie, chociaż nie byłbym zaskoczony, gdyby było kilku. Prawdopodobnie możesz napisać rozwiązanie za pomocą VBScript / WMI lub wykonać skrypt wsadowy, ale w rzeczywistości musisz dostosować rozwiązanie do bardziej złożonych witryn ASP.NET. Proste witryny składające się ze stron, połączeń z bazą danych i nic więcej, nie musisz robić prawie tyle, więc skaluj wysiłki związane z wdrażaniem zgodnie ze złożonością samej aplikacji.
Do tej pory w mojej obecnej pracy nadal wdrażanie odbywa się za pośrednictwem FTP i przenoszenia wielu plików. Jest brzydki, łatwy do zepsucia i nie ma poczucia dokładnej historii. To prawda, że możesz przeczesywać dzienniki FTP, nikt tak naprawdę nie zawraca sobie tym głowy. Nasze aplikacje są dość proste, bez potrzeby korzystania z FTP. Sposób, w jaki mój zespół wdraża nasze aplikacje internetowe, jest dla ciebie bardzo mało przydatny. Zamiast tego wolałbym skorzystać z okazji, by zaproponować lepsze praktyki.
- Nie zakładaj niczego. Konta użytkowników, uprawnienia R / W / X, listy ACL, zapory ogniowe, czas (kiedy należy wdrożyć i ile czasu trzeba to zrobić) oraz, jeśli to możliwe, przetestować wdrożenie we wszystkich środowiskach przed ostateczną „datą uruchomienia”.
- Zanim faktycznie zacznie się programowanie, uwzględnij wdrożenie w programowaniu. Jeśli to prosta strona, niech tak będzie. Jeśli jest wiele ruchomych części, weź to wszystko pod uwagę i faktycznie zbuduj plan, do którego wszystkie komponenty (kod, baza danych, raporty, kolejki itp.) Są w tym samym planie.
- Koordynuj z innymi parytetami i komunikuj się skutecznie i wydajnie.
- Dokumentuj jak najwięcej istotnych informacji, jeśli to możliwe.
- Środowisko: jeden serwer internetowy a farma internetowa; 32-bit vs. 64-bit; znajdź sposób monitorowania dzienników / błędów / rotacji itp.
- Znajdź (lub skompiluj) narzędzia, które mogą pomóc we wdrożeniu.
- Jeśli to możliwe dla programowalnego wdrożenia, wybierz paradygmat i trzymaj się go. Na przykład, jeśli chcesz użyć serwera bazy danych jako podstawowego sposobu przeprowadzania stanu aplikacji, wdrażania, dostępu itp., Upiecz ją w aplikacji i trzymaj się jej. Jeśli wolisz czytać pliki XML (jak web.config) za wszelką cenę, po prostu trzymaj się spójnego paradygmatu wdrażania aplikacji. Inny przykład: niektóre organizacje pozostawiają plik web.config jako plik statyczny w każdym środowisku, którego nie należy wdrażać w innych środowiskach. Program web.config innego użytkownika w taki sposób, że można go wdrożyć w różnych środowiskach bez błędów.
Zdaję sobie sprawę, że ten post może być przesadą w stosunku do pierwotnie zadanego pytania. Niestety wdrożenie nie jest proste, ponieważ aplikacje mogą mieć różną złożoność. Założę się, że większość organizacji wdrażających złożone aplikacje ASP.NET z czasem opracowało pewne strategie, które działają (przynajmniej) niezawodnie.