AppQuality (Unguess since January 2022) is the solution that helps companies create user-centric products and services by involving its community (the Crowd) of real people in all phases of the process, from design to development up to testing. The service offered has the objective of bringing products and services to the market with a memorable user experience for real users.
Accompany the Customer along the path of adopting a Cloud Native approach.
The Cloud Native Journey is a transformation that affects the entire software production cycle. The company and the team that decide to embark on the journey know (or soon discover) that significant changes are on the way: this is certainly the biggest challenge and to start it in the best way a thorough knowledge of the environment and of existing processes. For this reason, our journey begins with a barrage of questions asked to the development team, which we ask to describe the architecture and the functioning of its components, data flows and development tools.
The first need that emerged was to uniform the development environment so that it could be used by team members working on heterogeneous platforms, both as operating systems and as IDEs. This was the focus of the first phase of the Cloud Native Journey, aimed at completing the containerization of the main application and making the container-based implementation compatible with the platforms used by the development team. At the end of this phase the container-based environment is available to be used for development and debugging activities on different OS (Linux, Windows, MacOS) with different editors/IDEs (VSCode, PhpStorm).
After the first phase, the goal moved to the creation of a Proof of Concept of a real application deployment based on container orchestration. This process was anticipated by the introduction to the concepts and practices of declarative configurations, shown at work both in terms of infrastructure and application architecture.
The challenge is to validate the feasibility, advantages and possible limitations of this type of solution in the field. A further challenging element is constituted by the specific characteristics of the AppQuality application, based on a CMS, a generally “monolithic” type of application that requires particular attention for cloud-native transformation.
During this phase, several needs related to the specific characteristics of the platform emerged, which provided the opportunity to explore innovative solutions to address the distributed log management, the persistence on file systems,authentication and user authorization,networking with services inside and outside a cluster.
Finally, in the last phase, the elements seen in the previous segments were included in the source code development and management processes, enriched by the best practices ofContinuous Integration and Continuous Delivery, to increase the quality and reliability of the software releases, which for AppQuality occurs at a rapid pace, at the end of each sprint. In this phase, the already familiar tasks of Continuous Integration (automation of tests and QA controls) were added to the interactions with the components of a native cloud architecture, for example the container registry, and the different options of delivery for pipeline artifacts, with different levels of automation possible.
As mentioned above, the Cloud Native Journey starts with gaining insight into the processes and tools used by the development team. The result of this investigation, which also continues during the journey, when the presence of implicit knowledge not originally shared emerges, then serves to model the stages of the journey, to establish the concrete objectives of each phase and how to achieve them in practice. This is because the Cloud Native Journey is not simply a set of knowledge transferred in a “frontal” way, but a set of finished (in the sense of “done”) digital objects, mainly in the form of code on which the team has already started working during the trip and will be able to do so again in the future.
After the initial assessment phase, the interaction method that was more functional than not interrupting and not impacting the timing of the other development activities in progress was discussed with the team.
At the beginning of each phase, the objectives and deliverables of the phase were shared, in a moment of co-planning which confirmed or further explored the results of the initial assessment and clarified the practical needs of the team with respect to the Cloud Native transformation.
For this case the results are not quantitative if measured at release, but coincide with what has been concretely left to the internal development team in terms of concrete deliverables.
Phase 1 (containerization)
CTO, AppQuality
