koncepcja danych na systemie developerskim

[talex]

Mam pytanie, możecie podzielić się informacją jakie znacie stosowane
koncepcje odnośnie danych na systemie developerskim, tzn. czy są to co jakiś
czas kopiowane dane z sytemu produkcyjnego, czy też dane, które na własne
potrzeby musi wprowadzić sam użytkownik systemu developerskiego, w moim
przypadku generalnie chodzi o odpowiedź co lepsze: czy ułatwienie życia
programistom i im podobnym - przeniesienie danych z produkcji czy kwestia
bezpieczeństwa i oszczędności miejsca na dysku (nie kopiowanie danych z
produkcji) ?

[wicom]

Wydaje mi sie, ze opcja "tworzenia danych" nie ma sensu, tylko na zywym
organizmie mozna na prawde przetestowac rozwiazanie. Mimo ze jest to
czasochlonne i zabiera miejsce, nie widze innej alternatywy.
Z systemem E to bym sie zastanowil.

Pozdrawiam

[shepty]

Witam,

u nas są w sumie cztery systemy: deweloperski, konfiguracyjny, testowy no i
produkcja. Wszystkie systemu (oprócz produkcji) są odświeżane co trzy miesiące
(no chyba, że jest jakiś większy projekt) poprzez skopiowanie produkcji. Na
konfiguracyjnym nie ma żadnych danych, deweloperski i testowy są idealną kopią
produkcji.

Myślę że jest to wygodne rozwiązanie - nie trzeba się martwić o dane. Są
identyczne jak na produkcji co jest ułatwieniem przy testach.

pozdrawiam

[talex]

Dzięki za odpowiedź,
tylko problem w tym, że u nas są 3 systemy (developerski, testowy, produkcja).
testowy jest dokładną kopią produkcji, natomiast developerski podzielony jest
na: mandant konfiguracyjny (bez danych) i inne, na których dokonuje się
właściwych prac developerskich. I największy problem jest w dostępie do danych
firmowych zarówno dla osób z firmy - administratorzy modułowi itp... jak i z
zewnątrz (konsultanci), na developerskim przydzielany jest profil SAP_ALL i
dostęp do danych jest nieograniczony - w przypadku skopiowania produkcji na
developerski, osoby te otrzymują dostęp do wszystkich danych firmy i jak w
takim przypadku wytłumaczyć się np. firmie audytorskiej ? ;)

[mozdzins]

Hmm trzeba skasować krytyczne dane z tabel (prosty program w Abapie
wykasowujacy np. tabele HR-owe) poproscie "swojego" abapowca niech coś takiego
napisze :)

[shepty]

I największy problem jest w dostępie do danych
> firmowych zarówno dla osób z firmy - administratorzy modułowi itp... jak i z
> zewnątrz (konsultanci), na developerskim przydzielany jest profil SAP_ALL i
> dostęp do danych jest nieograniczony - w przypadku skopiowania produkcji na
> developerski, osoby te otrzymują dostęp do wszystkich danych firmy i jak w
> takim przypadku wytłumaczyć się np. firmie audytorskiej ? ;)

no, to jest kwestia zarządzania uprawnieniami.
w moim przypadku na mandantach deweloperskich odświeżane jest wszytsko oprócz
danych dot. użytkowników i uprawnień. U nas nikt nie ma sap_all - a, jesli już
to na moment dla konkretnej operacji i zawsze za zgodą "najwyższego" od IT.
Ja mam np. swojego SD_all -a i profil do konfiguracji. Czasami się potykam o
brak uprawnień ale rzadko. Generalnie u nas się nie szafuje SAP-All-em

[em_es]

U nas jest 3 systemy, developerski, testowy i produkcyjny. Developerski to
kopia produkcji bez danych, testowy to kopia z danymi, odświeżane
nieregularnie, jak potrzebujemy, ew. po dużych zmianach. Z początku były jakieś
plany z częściowym kasowaniem danych, ale zarzuciliśmy pomysł.

[kbor]

A ja zadam najprostsze pytanie?
Jezeli mamy "dopiero" system developerski to jak skopiowac dane z
produkcyjnego???
Mozna co najwyzej sciagnac dane z obecnego systemu, spreparowac je w txt lub
xls i zassac LSMW do SAP.

Jednak nie ma to jak samemu "tworzone" dane i zabawa z nimi, wtedy wiadomo ze
wszystko zostalo sprawdzone.

Mysle ze to zaden klopot utworzyc kilka indeksow materialowych, kilku
dostawcow, odbiorcow, ITP...

Chyba ze to projekt rolloutowy to wtedy inna sprawa :)

[em_es]

> Jednak nie ma to jak samemu "tworzone" dane i zabawa z nimi, wtedy wiadomo ze
> wszystko zostalo sprawdzone.
>
> Mysle ze to zaden klopot utworzyc kilka indeksow materialowych, kilku
> dostawcow, odbiorcow, ITP...
Kłopot żaden, ale pisanie/testowanie czegokolwiek na takich danych to
nieporozumienie. Kilka indeksów/składników majątku/dostawców ma się nijak do
tysięcy danych rzeczywistych. Przetestujesz konfigurację, ale nic poza tym.
Oczywiście jak jesteś w trakcie wdrożenia, to nie ma wyjścia, trzeba dane
produkować ręcznie, potem przenosić ze starych systemów (w końcu to też trzeba
testować). Ale po starcie to tylko kopia produkcji.
U nas był przypadek rozszerzenia pisanego w czasie wdrożenia, które po starcie
okazało się bezużyteczne, na danych rzeczywistych program chodził prawie dobę -
poprawnie działał, ale wymagał wielkiej optymalizacji czasu, czego na kilku
danych nie było widać zupełnie.

[nand]

Całkiem niezły :) pejzaż systemowy to:

1. Produktywny
2. Zapewnienia jakości (utworzony jako kopia produktywnego razem z danymi,
dostęp tylko dla teamu QA)
3. Rozwojowo-testowy (Dzięki transportowaniu wszystkich zmian spójny z
produktywnym i zapewnienia jakości. Własny zbiór danych testowych, bez
ujawniania danych produktywnych)
4. Piaskownica – może być kopią konfiguracji produktywnego

Pozwala uniknąć następujących wad:
- kopia produktywnego na rozwojowy kasuje historie zmian obiektów
- ograniczanie uprawnień na rozwojowym jest trudne – kłóci się z ideą rozwoju
nowych obszarów, posiadanie dostępu do narzędzi rozwojowych technicznie
umożliwia pełny dostęp do systemu
- duża złożoność/koszt tworzenia danych (po skasowaniu) lub zmiany danych po
każdej kopii z produkcji

Pozdrawiam,