Cloud computing and Infrastructure-as-Code (IaC), supported by technologies such as Docker, have shaped how many software systems are built and deployed. Previous research has identified typical issues for some types of IaC specification but not why they come to be, or they have delved into collaboration aspects but not into technical ones. This work aims to characterize the activities around two particular kinds of IaC specification-Dockerfiles and docker-compose.yml files. We seek to know how they can be better supported and therefore study also what approaches and tools practitioners employ. We used an online questionnaire to gather data. The first part of the study reached 68 graduate students from a study program on informatics engineering, and the second one 120 professional software developers. The results show that most of the activities of the process of developing a Dockerfile are perceived as time-consuming, especially when the respondents are beginners with this technology. We also found that solving issues using trialand-error approaches is very common and that many developers do not use ancillary tools to support the development of Dockerfiles and docker-compose.yml files.

Infrastructure-as-Code tools, such as Docker and Docker Compose, play a crucial role in the development and orchestration of cloudnative and at-scale software. However, as IaC relies mostly on the development of text-only specifications, these are prone to misconfigurations and hard to debug. Several works suggest the use of models as a way to abstract their complexity, and some point to the use of visual metaphors. Yet, few empirical studies exist in this domain. We propose a visual programming notation and environment for specifying Docker Compose configurations and proceed to empirically validate its merits when compared with the standard text-only specification. The goal of this work is to produce evidence of the impact that visual approaches may have on the development of IaC. We observe that the use of our solution reduced the development time and error proneness, primarily for configurations definition activities. We also observed a preference for the approach in terms of ease of use, a positive sentiment of its usefulness and intention to use. CCS CONCEPTS• Software and its engineering → Visual languages; Orchestration languages; Model-driven software engineering.

No abstract

No abstract