During the last week of March, the consortium has gathered together in the second General Assembly. The goals of this meeting were:

• Understand better the use cases: the current and future deployment topology, infrastructural elements needed now and, in the future, and the IaC tools now used, if any, to manage their infrastructure
• Discuss on different technical aspects related to the DevOps Modelling language (DOML), Infrastructural code generator, the security verification tools, the canary environment, the deployment orchestrator, the monitoring, self-learning and self-healing mechanisms.

• Understand the PIACERE workflow and sub-workflows, that is, how PIACERE would be used from a DevOps teams point of view.

The first day, the use cases were presented:

• Prodevelop proposes two applications: Posidonia PCS is the main use case, while Posidonia Terminal is the secondary use case. Both applications use AWS as the underlying cloud service provider (CSP). While Posdonia Terminal has many infrastructural elements, Posidonia PCS wants to demonstrate the deployment on multiple configurations. Both applications should benefit from self-healing mechanisms.
• Ericsson proposes a public safety use case deployed on 5G. It uses not only a CSP, in this case, Azure, but also an android application and a drone application server. Now a manual deployment on Azure cloud is performed, but the goal is to support AWS, VMWare and Openstack in automated way.
• SI-MPA presented a use case in which the ministry receives the application, coded by a contractor, and they have to perform some tests and are also responsible for the operation. In this case, the target is to prove the extensions of the DOML (DOML-E), the deployment and into a unique target environment.

The next session revolved around the DOML and the Infrastructure code Generator (ICG). Main conclusions reached are:

• There is the need of a multi-level and multi-view approach

1. An Application view.

2. An Infrastructure abstract model, without referring to a specific implementation. It should be the one on top which the one where the developer maps the application level components

3. An Infrastructure-specific model, where the developer maps the abstract elements with platform specific models.

• DOML should cover provisioning, configuration, deployment, and orchestration. These four steps should be used as a way to have different views of the model. As seen in the use cases, all four views are necessary.