Systém riadenia výroby pre výrobcu tesnení

Keďže Megabelt je Kežmarská firma, nebol problém stretnúť sa osobne a prediskutovať ich potreby. Spoločne sme došli k tomu, že ERP systém na mieru, bude najlepším riešením. Začali sme prípravou špecifikácie ako spôsob komunikácie o projekte s klientom spoločným jazykom (nakoľko o výrobe tesnení sme samozrejme nič netušili).

Keďže išlo o interný systém, dizajn na mieru nebol dôležitý, ak použité riešenie bolo dostatočne používateľsky prívetivé. Práve preto sme vybrali Material UI, ktoré nám umožňuje rýchlu dodávku použitím existujúcich komponentov a taktiež koncoví používatelia sú obvykle zvyknutí na aplikácie s Material UI čo uľahčí ich zaúčanie.

Väčšina z definovaných použití pozostávala z CRUD (vytvoriť, prečítať, upraviť a zmazať) operácií s databázou, preto sme sa rozhodli vyskúšať frontend framework react-admin, ktorý sa zameriava na B2B aplikácie a je postavený na knižnici React.js, Material UI, Redux a React-router. Neskôr sme zistili, že hoci bol skvelý na základné CRUD obrazovky, ale komplikácie nastali pri ostatných špecifických funkciách a obrazovkách. Touto skúsenosťou sme prišli na to, že by bolo lepšie si z react-adminu len vziať inšpiráciu, než ho použiť ako uholný kameň celej aplikácie.

Na backende sme taktiež vyskúšali novú technológiu a nahradili tradičný Express knižnicou Koa.js, ktorá je síce nová, ale vytvorená tými istými ľuďmi ako najpopulárnejší Express. To nám dovolilo zjednodušiť náš kód vďaka korektnému kaskádovaniu asynchrónnych middleware a použitie menej oblbov v kóde. Ako databázu sme si vybrali Postgres spolu s knižnicou na vytváranie požiadaviek knex. Nad knexom sme použili ORM knižnicu Objection.js, ktorá je veľmi flexibilná a dala by sa opísať ako rozšírenie knexu o relačné funkcie. V kontraste s inými ORM sa nesnaší byť chytrá, ale dovoľuje nám držať veci jednoduché, keď je to možné, a ustúpi do úzadia a dovolí nám pracovať s nižšími API keď si to situácia vyžaduje.

Pre autorizáciu sme zvolili autorizáciu založenú na používateľských roliach, nakoľko zákazník potreboval nastavovať oprávnenia pre jednolitvé role aj po nasadení aplikácie do produkcie. Spoločne so zákazníkom sme vyšpecifikovali jednotlivé oprávnenia a vytvorili rozhranie pre ich priraďovanie rolám, ktoré budú ďalej prideľované používateľom.

Pre hladký priebeh výroby sme implementovali automatické emailové upozornenia, ktoré vždy dajú ďalšiemu človeku vo výrobnom procese vedieť, že predchádzajúca fáza je dokončená. Taktiež sme pridali kanban tabuľu, aby sme manažérom dali perfektný prehľad o prebiehajúcich zákazkách a stavoch v ktorých sa nachádzajú. Napokon sme parametrizovali kalkulácie a vytvorili rozhranie tieto premenné nastavovať podľa potreby.

Kľúčovou funkciou pre našeho zákazníka bola možnosť exportovať a importovať záznamy z/do databázy. Implementovali sme ju formou CSV exportov a importov, aby sme mu umožnili robiť hromadné zmeny v celej databáze, pričom zákazníkovi ostala možnosť vytvárať kalkulácie v Exceli a experimentovať s rôznymi hodnotami, aby vedel priniesť čo najlepšiu službu pre svojich odberateľov. Ukázalo sa to ako jedna z najväčších výziev nakoľko Excel používa v uložených súboroch formátované hodnoty namiesto normalizovaných. Napríklad kým čísla v angličtine sú typicky písané ako 1,234.56, v slovenčine je to 1 234,56. Súčasne musel systém vedieť spoľahlivo pracovať so skutočne veľkými importami celého skladu.

Systém sme vyvíjali len pre jedno zo zákazníkovych oddelení - tesnenia vyrábané na sústruhu avšak s plánom v budúcnosti ho rozšíriť. Preto sme zahrnuli automatické testy, zvyšujúc tak našu istotu v spoľahlivosť a stabilitu systému, keď ho budeme v budúcnosti rozširovať bez obáv o existujúce oddelenia. Vybrali sme si integračné testy, keďže nám podľa nášho názoru poskytujú najlepší pomer cena:výkon.

Po celý čas sme používali "continuous integration" s pomocou GitLab CI:CD v ktorom sme spúšťali automatickú kontrolu štábnej kultúry ESLint a integračné testy pomocou spúšťača testov Mocha. Každá "merge request" prešla automatickými testami a linterom na zachytenie možných chýb ešte pred tým, ako bola postúpená podrobnej kontrole kódu (code review). Na náš server sme nasadili testovacie prostredie a umožnili zákazníkovi vyskúšať nové funkcie počas toho, ako sme ich pridávali. Zmeny sme automaticky nasadzovali (continuous delivery) ako na testovacie, tak na produkčné prostredie, jednoducho vďaka vstavanému Docker registru v GitLab-e. Každý commit do master vetvy spustil vytváranie nového Docker obrazu, ktorý bol potom nasadený na testovacie prostredie. Podobným spôsobom, bol každý označený commit nasadený na produkčné prostredie.