Abap fejlesztés során legalább három rendszeren keresztül gyűrüznek a változtatások. Fejlesztői, teszt és production. Ez egy jó struktúra. De a módosítások átvitele közben akadhatnak problémák. Az egyik a fejelsztői és teszt közöti átvitel. Rendszeresen testen jönnek elő a hibák, azt nyüstöli a legtöbb ember. Ha gond van elsőként a test rendszerben keresik a hibát, hiszen az ami többé kevésbé stabil. Ám a fejlesztők nyomulnak és készítik a transportot. Sajnos lazán előfordulhat egy transport kellős közepén dolgozols és minden átmenet nélkül elkezd fordulni a rnedszer. (ugyan az az elv, mint Oracle PL/SQL) Nem tudom, hogy ez-e az oka, de ekkor gyakrabban behal a rendszer. Milyen jó lenne egy hourly/daily buildeket csinálni.
Valamelyik álltalam gyakran olvasott blogger (talán valami Eric (ha köll a link szólj)) írt pár gondolatot a Continous integration dologról, aminek egyik lápáse a gyakorlatilag folytonnos fordítás és unit test futtatás. De csak a verziókezelő rendszerből kivett friss dolgokon. De a CVS nem atomi műveletekkel dolgozik (mondjuk nagyon egyszerű heurisztikával oldották meg). Aki csapatban használja előbb-utóbb belütközik abba, hogy akkor veszi le a fájlokat, mikor a másik éppen commitálja. Magyarul mondva inkonzisztens rendszert kap. Csoda ha lefordul.
És ha már fodulunk. Nagy dolognak tűnik manapság a lefodíthatóság? Egyértelműen nem. Fasza ideink és build rendszereink vannak. Egyik kedves barátom egyetemi évei alatt dolgozott olyan projekten (nem fejlesztőként, hiszen ilyen pongyolaságot nem engedett volna), amit nem tudtak lefordítani! Fejlesztették (C++) és mindig ott figyelt valami félig lefordított object, ami alapján lehetett dolgozni. De amikor a nulláról akarták lefordítani..... Nem tudom megoldották-e azt azóta.
Száz szónak is egy a vége: fordítani kell! Állandóan és mindig a nulláról.
