[Jahcob]

#sap #abap
Klient chce dokumentacje do każdej zmiany przenoszonych z deva na test

[owocbananowca]

@Jahcob: Ok? Nasz chce otrzymać wniosek z osobami odpowiedzialnymi, tworzącymi, testującymi, numerami transportu, opisem co każdy transport zmienia/poprawia (merytorycznie i krótko) no i ofc daty + zgłoszenie jakiego dotyczy.

[owocbananowca]

A u innego w--------ć mamy transporty od razu na prod bo oni na teście sprawdzać nie będą xD
Dzbany xD

[CrazyBaran]

Transport?

[Jahcob]

@owocbananowca: ja rozumiem pisać dokumentacje do całego rozwiązania, a nie do każdego transportu. Przecież pisanie dokumentu zmian do zmiany np. z lvfield = BUDAT + 1 na lvfield = BUDAT. jest turbo kretyńskie.
Szczególnie że na devie nie ma żadnych danych do testów.

[Jahcob]

@CrazyBaran: przeniesienie zmian kodu z jednego systemu na drugi

[Qrystus]

@Jahcob: @owocbananowca:
Jedni za bardzo się zaczytali w szkoleniach BC*, drudzy w ogóle nie rozumieją idei transportów. Tu i tu skrajność.

O ile tylko za taką dokumentację Klient płaci to czemu nie?

@Jahcob,
Jak ma w takim przypadku rozwiązaną politykę transportów awaryjnych?

[Jahcob]

@Qrystus: tutaj w ogole jest problem, bo jest cyrk np. z substytucjami/walidacjami; jest duży projekt który rusza też sub/val, a w miedzy czasie kilka mini zmian w samych np. validacjach i juz sie cyrki dzieją, wersje się sypią... nikt nic nie wie, co i gdzie powinno byc. Nie ma w ogole zarządzania TRami, zmianami. Teraz sie obudzili jak dostali wyniki audytu. I cudują.
Niby płacą, ale to nie ma po

[owocbananowca]

Przecież pisanie dokumentu zmian do zmiany np. z lvfield = BUDAT + 1 na lvfield = BUDAT. jest turbo kretyńskie.

@Jahcob: Ok, masz rację xD
U naszego klienta chociaż są dane testowe już na dev więc jest spoko i takich transportów po prostu nie ma. A jak już są to na tyle rzadko że to nie problem.

[Jahcob]

@owocbananowca: co jest najlepsze.... już się od rana o to kłócę w mailach i jak grochem o sciane.