For one of the leaders in Polish print finishing industry, migrated custom-made MIS/ERP system to new environment, enabling its further development and commercialization

Logical progression from the technical audit conducted in November 2019 was to address most serious problems it uncovered. Thus, in December 2019, work started on migration of custom-made MIS (“Management Information System”)/ERP (“Electronic Resource Procurement”) system to new environment, which would enable its further development and commercialization. After two-week long user acceptance testing phase, on February 28, 2020, the system was switched to its new production environment.

The MIS/ERP system was developed in-house by leaders in print finishing industry and utilized for 5+ years already in production in two branches of the company. It consists of web application, Android OS client applications deployed on tablets and automated label printers – both used on the production floor – as well as dedicated self-service B2B web applications for some of the larger clients company works with.

The word “migration” does not suffice, as this was a multistage process, consisting of:

I. Creating an easily replicable, stable environment which allows for scaling and further development
Utilizing infrastructure automation and scripting tools, installation and configuration of, inter alia Hipervisor, NFS server, Git version control system, Docker image registry, CI/CD orchestration, Build automation, and Kubernetes cluster.

  1. Windows Server 2019 configuration
    PowerShell scripts run directly on Windows Server 2019 to install and configure roles and services provided by Windows Server, such as:
    • Hyper-V hypervisor
    • NFS server
    • NFS shares
    • WinRM

  2. Golden images creation
    Building golden images for VMs to be deployed in staging and production environments, including Generation 2 Hyper-V VMs (Secure Boot, SCSI, etc.), and KVM VMs. Utilizing, inter alia: Packer, cloud-init, and Ubuntu server 18.04.4 LTS.

  3. Infrastructure provisioning
    Automated provisioning of infrastructure, i.e. network resources, disks and virtual machines, for both staging and production environments, with distinction between roles each VM is to serve (i.e. GitLab server, GitLab CI Runner, Kubernetes cluster nodes). Utilizing, inter alia: Terraform, Terraform KVM provider, Terraform Hyper-V provider.

  4. Infrastructure configuration
    Automated configuration of infrastructure, including network time services, disks (partitioning, formatting, mounting), hostnames, as well as services unique to each of the distinct types of VMs (i.e. GitLab server, GitLab CI Runner, Kubernetes cluster nodes), for both staging and production environments. Utilizing, inter alia: Ansible, incl. Kubespray.

  5. Integration of the on-premises provisioned and configured sub-systems
    Integration of the on-premises provisioned and configured sub-systems into one whole, i.e.:
    • Integration of GitLab CI Runner with GitLab server, and
    • Integration of Kubernetes cluster with GitLab server

  6. Data and configuration backups
    One-time (PKI, configuration, etc.) and automated/scheduled backups of data and configuration, including:
    • Automated/scheduled backups of Kubernetes’ ETCD and resources to dedicated NFS share
    • Automated/scheduled backups of GitLab configuration and data (incl. Git repositories) to dedicated NFS share
    • Automated/scheduled backups of database to dedicated NFS share

II. Lifting web application code to work in new environment
Starting with identifying technology stack and configuration used by each of the sub-systems / services utilized, then separating these into roles (database, PHP FPM, web server, etc.), then preparation and build automation of Docker containers where each of these services and main application code was to be deployed, then identifying and applying any code modifications needed so that application can run inside Docker container deployed in Kubernetes cluster, then creating Kubernetes descriptors for each of the services and main application. After successful test runs, technology stack used by application was then modernized - i.e. PHP language was upgraded from old 5.x version to latest 7.4.x version, database was swapped from old 5.x version of MySQL to latest 10.4 version of MariaDB, as well as any code modifications needed, related mostly to change of language version by two major releases (i.e. 5.x to 7.x), and paths for storing data generated (PDFs, QR codes, etc.) were changed to point to mounted NFS shares so these can be accessible from outside cluster by authorized persons as well as automated label printers.

For each of the dedicated B2B web applications, very similar path was taken. Those were then deployed utilizing, inter alia, Nginx Ingress Controller, with separate Ingresses for each of the B2B web apps in their dedicated Kubernetes namespaces.

Both main application, dedicated B2B web applications, and services these consume were then deployed in Kubernetes cluster, with shared services – such as database – occupying separate namespace to be utilized by both main application as well as dedicated B2B web applications.

III. Restoring Android OS client applications’ source code
Compiled APK versions of Android OS client applications were extracted from tablets used on production floor using ‘adb’ (Android Debug Bridge), then decompiled using ‘jadx’ (https://github.com/skylot/jadx), then modifications needed for the applications to compile and install were applied. The application IDs of such restored Android OS client applications were then changed and such compiled APKs where then installed on same tablets in parallel and successfully tested. Source code for all 14 Android OS client applications was successfully restored in this way. Utilized, inter alia: Android Debug Bridge, JADX, Gradle, and Android Gradle Plugin.

Six out of eleven most pressing issues identified in the technical audit conducted in November 2019 were thus solved, including:

  • Intermittent application crashes and need for manual reboots
  • Hardware issues, including frequent “self-restarting” of the server where application was deployed and likelihood of physical damage to disk
  • Security threats stemming from using versions of operating system, language and database, which have not been patched nor upgraded for 5+ years already
  • Lack of any other environment in which the MIS/ERP system could be run in order to upgrade main hardware and update operating system, language and database versions or to transition to in case of catastrophic hardware failures
  • Lack of source code for Android OS client applications
  • No version control system

The underlying objective of not having to throw out 5+ years of work and processes in exchange for commercial solution which, however enticing, would not be able to meet company’s evolving needs without extensive customizations and ongoing development, was thus met, in addition to materializing numerous other benefits, such as:

  • Ensuring business continuity for client for whom the MIS/ERP system holds a critical role in daily operations by managing the entire technological process of the company
  • Ensuring availability of the MIS/ERP system at all times for both users and devices deployed on the production floor
  • Significantly simplified integration with external applications and systems with minimal interference into the application code of the MIS/ERP system itself
  • Enabling secure and hassle-free upgrading of language versions, database, and any other sub-systems
  • Ability to quickly scale as well as replicate entire environment for use inside the company (e.g. additional dedicated B2B versions of the application, deploying separate instance/s in SaaS model for company’s clients, etc.) as well as for on-premise installations when reselling the entire solution to other companies from print finishing industry
  • Enabling safe, gradual further development of the MIS/ERP system with multiple fall-back mechanisms, including version control system, separate staging environment, Docker registry, automated backups, etc.

Technology stack:

  • Languages
    • PHP
    • Python
    • Java
    • JavaScript
    • Bash
    • SQL
    • HTML
    • CSS
  • Databases
    • MySQL
    • MariaDB
  • Web servers
    • Apache
    • Nginx
  • Virtualization
    • Hyper-V hypervisor / Hiperwizor Hyper-V
    • KVM hypervisor / Hiperwizor KVM
  • Infrastructure automation
    • Packer
    • cloud-init
    • Terraform
    • Ansible
    • PowerShell
    • WinRM
  • Containerization
    • Docker
    • Kubernetes
    • Helm
    • MetalLB load-balancer
  • Build automation
    • Gradle
  • Android development
    • JADX
    • Android Gradle Plugin
    • Android Debug Bridge (adb)
    • Android Studio IDE
  • Security
    • OpenSSL
    • GPG
    • SSH

  • NFS

  • Git

  • GitLab

  • OS
    • Ubuntu server 18.04.4 LTS
    • Windows Server 2019
    • Android OS 4.4 ‘KitKat’