Upgrade

[Feanor]

Witam,

Na początek informuje że z XL-em mam kontakt od niedawna, stąd też pytania nooba .

Aktualnie jest 6.6 z modułami Sprzedaż, Księgowość, Zamówienia oraz Optimy w oddziałach z synchronizacją.

Firma wdrażająca XL-a sugeruje przejście na 7.1. Jak wygląda w praktyce proces aktualizacji. Wszystko ma być najpierw zainstalowane na środowisku testowym, czy mogą być zainstalowane 2 różne wersje na tej samej bazie, a może musi być oddzielny serwer? Czego się spodziewać już po? Oraz prośba o ogólne uwagi/przestrogi od ludzi, którzy to już przerabiali.

Z góry dzięki i pozdrawiam
feanor

[Przemek]

Chyba masz 6.0 HR 6, ale może się mylę

W upgrade realizowanych terminowo z wersji na wersje zazwyczaj nie robimy środowiska testowego tylko
- kopia bazy
- testy integralności bazy
- migracja bazy do nowej wersji (HRy)
- instalacja XL-a
- konwersja bazy (duże wersje)
- testy (ustalone wcześniej z klientem) kluczowych funkcjonalności

i jeżeli po drodze nie ma problemów to działamy produkcyjnie, drobne problemy które nie wyszły w testach usuwamy na bieżąco. Jeżeli na którymś etapie pojawi się problem którego od ręki nie rozwiązujemy to wracamy do starej wersji i robimy migracje w następnym oknie serwisowym.
Testy ustalone z klientem to podstawa migracji, jest to coś co gwarantuje bezpieczeństwo obu stron (klienta bo wie że wszystko kluczowe działa prawidłowo), nie ma co na nich oszczędzać, lepiej zrobić więcej niż mniej. Koniecznie wcześniej dokładnie ustalić co i jak będzie testowane, przy testach obecne obie strony.

P.S. Jak już migrować to na 8.0 a nie znowu z tyłu...
P.S2 Skoro pracujesz z O! off-line to uwzględnij numeracje MMP (my ten błąd wykryliśmy i dopiero potem zaktualizowano dokument migracji wersji)

[glaz]

IMHO W każdym upgrade (terminowym/nieterminowym)

• 0. Rób kopię bazy po każdym etapie konwersji !
  1. Zapoznaj się z nową wersją:
  • -zalecana konwersja testowa kopii bazy produkcyjnej
    - zalecane zapoznanie się z lista nowych funkcjonalności (nowy kod wprowadza nowe błędy)
    - zalecane zapoznanie się z listą poprawionych błędów (poprawki wprowadzają nowe błędy, rozwiązanie błędów niekoniecznie robi naprawę tak jak sobie to wyobrażamy)
  2. Testy integralności nie zawsze wyłapią błędy odpowiedzialne za problemy z konwersją. IMO generują bardzo dużo ostrzeżeń nie mających zbyt wiele z faktycznymi problemami. W instalacjach korzystających z baz konwertowanych z wersji 3.2 i starszych są wręcz bezwartościowe z powodu dużej ilości błędów (braku spójności danych) nie naprawianych lub omijanych przez kolejne konwersje.
  3. Po konwersji testowej zalecam posadzenie na nowej wersji CDN XL na testowej, skonwertowanej bazie danych, osób organicznie zainteresowanych prawidłową pracą systemu (księgowość, kierownicy działów, pracownicy działów) i pisemne potwierdzenie prawidłowej pracy tej wersji systemu z wyliczonymi funkcjami sprawdzonymi przez delikwenta
  4. Bazę testową, jeśli na to środki pozwalają posadziłbym na odrębnym sprzęcie: odpadają problemy z przeciążeniem serwera produkcyjnego w czasie testów. Wersje trial Windows Server i SQL Server dają około 180 dni na pracę - powinno wystarczyć. Miła cechą Windows Server w wersji trial są licencje terminalowe, umożliwiające na nieinwazyjne testy, niezależne od obecnej instalacji. Cena samego sprzętu nie musi powalać: Athlon X2 lub Phenom z 4 Gb RAM i 4 dyskami w raid powinien dać dość dobre środowisko testowe nawet dla baz 20 Gb przy założeniu, że pracuje na niej intensywnie do 5 osób. Rzecz jasna testy wydajnościowe pod maksymalnym obciążeniem powinieneś przeprowadzić na serwerze produkcyjnym, ale to już inna bajka.
  5. Jeśli migrować to na wersję, która sprawia najmniej problemów. Na pewno nie na pełną z oznaczeniem FR. Final Relase IMHO to wersje dla królików doświadczalnych: niby poprawiają stare błędy, ale wprowadzają jeszcze więcej nowych rzeczy dających najczęściej po czterech literach. Stabilizacja następuje po HR2 (tylko zmiany wynikające z poprawianych błędów). Ja osobiście siedzę na 7.1 HR3 i ew. czekam na 7.1 HR4, jeśli wyjdzie. Na 8.0 HRX przejdę jak pojawi się 8.1 FR .

[timo]

jeżeli po drodze nie ma problemów to działamy produkcyjnie ..... Jeżeli na którymś etapie pojawi się problem którego od ręki nie rozwiązujemy to wracamy do starej wersji

gdzie jest taka opcja w CDN-XL pozwalająca wrócić z bazą z wersji wyższej na niższą np z 8 na 7.1 ?

Ja osobiście robie sobie środowisko testowe dla nowej wersji aby sprawdzić czy warto ją instalować i czy są jakieś ewidentne błędy, potrzebuje na to kilkadziesiąt godzin i trudno żeby w tym czasie inni nie pracowali.
Środowisko testowe robie tak
- kopia bazy
- odtworzenie pod inną nazwą (np cdnxl8)
- jeśli jeszcze nie były instalowane wszystkie HR-y uruchamiam skrypty dla bazy od brakujących HR-ów (baza xdnxl8)
- na moim komputerze zmieniam nazwę katalogu CDN-a z aktualną wersją
- instaluje nową wersie
- podłanczam nową bazę
- konwersja bazy na nową wersje

jeśli potrzebuje uruchomić daną wersję cdn-a wchodzę do jej katalogu i uruchamiam rejestr.bat

Koncepcja z serwerem terminali jest jak najbardziej godna polecenia. Ja mam raczej średnią instalacje więc wykorzystuje stary komputer z XP prof i pulpit zdalny dla urzytkowników wytypowanych do testowania. Praca na dwóch bazach CDN-a nie wpływa u mnie znacząco na wydajność serwera SQL.

Coraz mniej chętnych do testowania nowych wersji uważanych przez COMARCH za produkcyjne, jak tak dalej pójdzie to trzeba będzie czekać do HR3 lub HR4 z instalacją

[Przemek]

jeżeli po drodze nie ma problemów to działamy produkcyjnie ..... Jeżeli na którymś etapie pojawi się problem którego od ręki nie rozwiązujemy to wracamy do starej wersji

gdzie jest taka opcja w CDN-XL pozwalająca wrócić z bazą z wersji wyższej na niższą np z 8 na 7.1 ?

W punkcie pierwszym jest "kopia bazy"

Ja osobiście robie sobie środowisko testowe dla nowej wersji aby sprawdzić czy warto ją instalować i czy są jakieś ewidentne błędy, potrzebuje na to kilkadziesiąt godzin i trudno żeby w tym czasie inni nie pracowali.

Kilkadziesiąt godzin.... byśmy nie nadążyli z migrowaniem klientów i naprawdę mało kto by zapłacił za kilkadziesiąt godzin prac przy każdej migracji...

[timo]

Kopia bazy? Ok tylko że wtedy wszystkie dokumenty wprowadzone w ciągu np tygodnia zaczym wyszedł problem trzeba wprowadzić od nowa. Już widzę minę szefa jak mu to powiem. Umówmy się że jest to ostateczność.

W godzinę czy dwie to mogę sprawdzić czy wszystkie aplikacje się uruchamiają i czy da się wprowadzić jakieś przykładowe dokument,
ale czy działają wszystkie filtry, wykresy , wydruki, schematy księgowe, księgowania okresowe itd to może być już problem zależy ile tego jest i jak są rozbudowane.

Najlepiej jak program testują użytkownicy w końcu to oni najlepiej wiedzą co najczęściej robią i jak to powinno działać, wystarczy że kilka osób przeznaczy np. dwie godziny na sprawdzeni funkcjonowania poszczególnych modułów i zazwyczaj co grubsze problemy wychodzą. Wiele z nich udaję się rozwiązać. Potem ponownie przetestować. Jak się w sumie zbierze czas tych kilku osób oraz administratora to wychodzi kilkadziesiąt godzin. Oczywiście ja za to nie płacę Partnerowi bo to ja i inni pracownicy odwalamy robotę nie on.

W przypadku małej instalacji można zrobić aktualizację bez specjalnych testów ale przy większych nie byłbym tak odważny.

[Przemek]

Nie rozumiemy się.
Jak zaczniemy pracę produkcyjną to już nie ma powrotu.
Po to są wcześniej ustalone testy akceptacyjne żeby wszystko istotne sprawdzić. Drobne problemy poprawiają się później i zawsze coś wyskoczy. Raz próbowałem testy metodą "siądź i sprawdź czy wszystko Ci działa" i tak nie sprawdził wszystkiego istotnego....

[glaz]

Drobne problemy poprawiają się później i zawsze coś wyskoczy.

Duże zapewne też, jeśli nie sprawdzi się tego w środowisku testowym.

Raz próbowałem testy metodą "siądź i sprawdź czy wszystko Ci działa" i tak nie sprawdził wszystkiego istotnego....

Jeśli się wcześniej nie przygotuje dokumentu migracyjnego. To tak naprawdę w przypadku stałego klienta to jednorazowa duża inwestycja (posiadówka z użytkownikiem), potem lista funkcjonalności do sprawdzenia jest sukcesywnie uzupełniana przy każdej kolejnej konwersji. W końcu jak często zmieniają się gruntownie procedury i sposób działania księgowości, działu produkcyjnego, czy sprzedaży ?

Kwestia tego czy klient zapłaci czy nie za solidniejszy proces konwersji. Jego wybór. W końcu sobie uświadomi, że i tak zapłaci za szybką konwersję w ratach za kolejne "drobne poprawki". A mina pań z księgowości gdy nie działa na 20 dnia miesiąca zestawienie dla VAT i pod. dochodowego: bezcenne

[Kyniu]

Kwestia tego czy klient zapłaci czy nie za solidniejszy proces konwersji. Jego wybór.

Przeraża mnie takie podejście. Niedopuszczalne jest przedstawianie klientowi alternatywy w wyniku wyboru której mógłby sobie zafundować kuku bo klient nie jest specjalistą i nie wie, nie musi, nie powinien, etc. doktoryzować się z migracji systemu informatycznego który wybrał. Partner który bierze na siebie brzemię migracji i otrzymuje za to wynagrodzenie - nie ważne jak duże - ma to zrobić w sposób najlepszy z możliwych, zgodnie z kanonami sztuki, a nie na zasadzie "zrobimy tak za ile klient zapłacił". Nie zrobisz za cenę jaką akceptuje klient bo za niska - to odpuść. Ale nie rób klientowi krzywdy.

Kyniu

[glaz]

Przeraża mnie takie podejście.

Mnie też.

Niedopuszczalne jest przedstawianie klientowi alternatywy w wyniku wyboru której mógłby sobie zafundować kuku

Może jakiś list dziękczynny do producenta ? Mnie już przestali tam słuchać Nawet spotkań referencyjnych jakoś nie chcą ostatnio u mnie już robić z nowymi potencjalnymi klientami. Szczerość w opisywaniu "zalet" CDN XL jak widać nie popłaca

... "zrobimy tak za ile klient zapłacił" ...

To wprawdzie nie do mnie skierowane stwierdzenie (przynajmniej tak odbieram 90% tego postu, pomimo cytatu mojego loginu i wyrwanego z kontekstu cytatu), ale zapytam z ciekawości: jaką zasadę stosujesz w swoim biznesie jeśli nie powyższą? Praca zgodnie z regułami bez oglądania się na koszty (czas) to szczytne hasło ale IMO bez specjalnego, pięciocyfrowego funduszu na R&R dla CDN XL nieosiągalne.