Our client’s platform is an information system that allows administrative bodies, banks, not governmental pension funds and other stakeholders to exchange government-related data online.
Most of the time the governmental services are fully/partly unavailable or buggy because of the difficulties in the software version delivery and release, as many contractors are involved in the development process. While a Performance Lab team was testing the e-government information system and the service structure, they were requested to additionally optimize the release deployment process for e-communication between administrative bodies.
There is no better place for a QA solution than Performance Lab.Drop us a line to find out what our team can do for you.
The delivery and release difficulties, caused by several factors, create a significant amount of problems:
While the process involves many contractors, each of whom is responsible for a subsystem development, there is no instrument to put together the modules. As a result, the costs rise and releases get delayed.
The source code for distributive build and deployment instructions are delivered separately, on different devices. Consequently, the combined subsystem release is not seldom built with errors, which renders its deploy impossible.
Since there is no standard for the acceptance criteria and neither source code nor the system documentation are systematized, there are more difficulties as well in the system operation, as in forwarding the subsystems for rework. Obviously, there is a dependency on the contractors: many questions about the release build and installation could be only solved by contacting a contractor support services.
Therefore the customer set the following goals for our project team:
To reach the set goals the Performance Lab team decided to deploy an instrument for version control and new subsystem release build and preliminary testing. The instrument had to allow evaluating the sent release quality and quantity criteria, as well as ensure that the project specification is up-to-date.
The testing instrument deployment was more difficult because of the following factors:
In order to implement the automatic build and preliminary testing we applied the base DevOps Continuous Integration (CI) method. The method implies using several build systems and several CI systems that are connected to the source code project repositories. The system cooperation is organized by an automated system that ensures source code and builds managing and hosting. A quality and quantity source code evaluation is performed after each change by profile-configured static code analysis instruments. After that the preliminary testing and dynamic code analysis are executed; they ensure the detailed release quality evaluation. All data sent by contractors on different devices first goes through an automated acceptance process and then undergoes a source code and release build check-up.
As the process has been fully automated, the release delivery and build costs and duration have been reduced. Before we had to wait for a source code, distributive and specification delivery by the post, then install the distributive manually using an instruction (not always complete and up-to-date). After the instrument deploy the release costs and duration have been significantly reduced.
Subsystem development became a systematized, standardized, manageable and controlled process for the customer.
Contractor workflow unification The customer can employ a new contractor when needed, giving them the access rights to maintain a repository with the complete change history, build scripts and installation instructions.