Report from GI-Dagstuhl Seminar 16394: Software Performance Engineering in the DevOps World

This report documents the program and the outcomes of GI-Dagstuhl Seminar 16394 "Software Performance Engineering in the DevOps World". The seminar addressed the problem of performance-aware DevOps. Both, DevOps and performance engineering have been growing trends over the past one to two years, in no small part due to the rise in importance of identifying performance anomalies in the operations (Ops) of cloud and big data systems and feeding these back to the development (Dev). However, so far, the research community has treated software engineering, performance engineering, and cloud computing mostly as individual research areas. We aimed to identify cross-community collaboration, and to set the path for long-lasting collaborations towards performance-aware DevOps. The main goal of the seminar was to bring together young researchers (PhD students in a later stage of their PhD, as well as PostDocs or Junior Professors) in the areas of (i) software engineering, (ii) performance engineering, and (iii) cloud computing and big data to present their current research projects, to exchange experience and expertise, to discuss research challenges, and to develop ideas for future collaborations

Automation of the Continuous Integration (CI) - Continuous Delivery/Deployment (CD) Software Development

Continuous Integration (CI) is a practice in software development where developers periodically merge code changes in a central shared repository, after which automatic versions and tests are executed. CI entails an automation component (the target of this project) and a cultural one, as developers have to learn to integrate code periodically. The main goal of CI is to reduce the time to feedback over the software integration process, allowing to locate and fix bugs more easily and quickly, thus enhancing it quality while reducing the time to validate and publish new soIn traditional software development, where teams of developers worked on the same project in isolation, often led to problems integrating the resulting code. Due to this isolation, the project was not deliverable until the integration of all its parts, which was tedious and generated errors. The Continuous Integration (CI ) emerged as a practice to solve the problems of traditional methodology, with the aim of improving the quality of the code. This thesis sets out what is it and how Continuous Integration is achieved, the principles that makes it as effective as possible and the processes that follow as a consequence, to thus introduce the context of its objective: the creation of a system that automates the start-up and set-up of an environment to be able to apply the methodology of continuous integration

Continuous delivery

Treballs Finals de Grau d'Enginyeria Informàtica, Facultat de Matemàtiques, Universitat de Barcelona, Any: 2018, Director: Josep Vañó Chic[en] The project consists in researching, analyzing and implementing a deployment pipeline from scratch. During the implementation, a web-application called Funny Stories is created to demonstrate the way this kind of system works. To develop this system, a series of technologies were used. For the implementation of the application the tools used were Java 8 with the framework Spring Boot for the server side; HTML, jQuery, Bootstrap and CSS for the client side, and MySQL for managing the database. The web-site allows users to visualize stories posted by other people which are sorted by categories. They are also able to use a voting system to give their feedback for each post. The web-site is public and these features can be accessed by anyone. When integrating new features into an application and the process is manual, a lot of unforeseen error can happen which can end up delaying the delivery of the software by hours or days. This result in the developer not being able to show his work and delaying the release process which can affect the end users since they cannot use the product. A lot of pressure is put on the responsible for the integration and can end up in a lot of frustration. These problems are very common inside organizations and have inevitable outcome in the development process. These are indications that something is not right because the delivery should be fast and repeatable. This project looks at the delivery from another perspective and will present a series of practices which will improve the code integration. This will allow the developers to release their work several times a day while reducing the risks of the process. The release management of this application is done by using an automated deployment pipeline. This implies that whenever there is a change to the system, the deployment pipeline automatically rebuilds the entire application, tests it for errors and deploys it to the production environment

Automated Testing For Software Process Automation

Robotic Process Automation is a way of automatizing business processes within short timespans. At the case company the initial automation step is implemented by business experts, rather than software developers. Using developers with limited software engineering experience allows for high speed but raises concerns of automation quality. One way to reduce these concerns is extensive testing, which takes up much time for integration developers. The aim of this thesis is to increase the quality of the development process, while minimizing impact on development time through test automation. The research is carried out as a part of the Robotic Process Automation project at the case company. The artifact produced by this thesis is a process for automatically testing software automation products. Automated testing of software automation solutions was found to be technically feasible, but difficult. Robotic process automation provides several novel challenges for test automation, but certain uses such as regression and integration testing are still possible. Benefits of the chosen approach are traceability for quality, developer confidence and potentially increased development speed. In addition, test automation facilitates the adoption of agile software development methods, such as continuous integration and deployment. The usage of continuous integration in relation to Robotic Process Automation was demonstrated via a newly developed workflow.Ohjelmistoautomaatio on nopea tapa automatisoida liiketoimintaprosessien rutiineja. Tapausyrityksessä automaation luovat ohjelmistonkehittäjien sijasta liiketoiminnan asiantuntijat. Käyttämällä alkukehittäjiä, joilla on vähäisesti kokemusta ohjelmistokehityksestä, saadaan nopeita ratkaisuja, mutta samalla yrityksellä on huolia laadusta. Laatua voidaan mitata testaamalla automaatioratkaisuja laajasti, mutta tähän menee huomattavasti aikaa. Tämän tutkielman tarkoituksena on testiautomaatiota käyttämällä nostaa kehitysprosessin laatua ilman että työmäärä kasvaa merkittävästi. Tutkimus suoritettiin osana tapausyrityksen ohjelmistorobotiikkaprojektia. Tutkielmassa luotiin prosessi, jossa automaattisesti testataan ohjelmistoautomaatioprosesseja. Testaus todettiin tutkimuksessa mahdolliseksi mutta käytännössä haasteelliseksi. Testauksessa ilmeni useita ongelmia, mutta muutamat ratkaisut kuten regressio- ja integraatiotestaus todettiin kuitenkin hyödyllisiksi. Lähestymistavan hyödyiksi todettiin laadun jäljitettävyyden, kehittäjien itseluottamuksen ja kehitysnopeuden kasvu. Lisäksi testiautomaatio mahdollistaa nykyaikaisten ketterien menetelmien kuten jatkuvan integraation käytön. Jatkuvan integraation käyttömahdollisuus demonstroitiin uudistetulla työtavalla

Continuous Delivery: Aplicação na Glintt

Nowadays, Continuous Integration and Continuous Delivery are practices that the organizations that develop software implement to facilitate and improve their daily work. These continuous practices allow organizations to perform more reliable and constant releases of new features and products. In this dissertation, it will be documented the application of continuous practices in a real case, at Glintt Healthcare Solutions organization. A case study of methods, approaches and technologies will be made to understand the better way to implement those practices and take the most possible advantages of that process. It is expected that this project decreases or completely solves the problems that originated it, contributing to improve the quality of the products and increase the costumers’ trust in the organization.Atualmente, os conceitos de Continuous Integration e Continuous Delivery estão relacionados com práticas que qualquer organização que desenvolve software implementa de modo a melhorar o seu trabalho diário. Estas práticas permitem às organizações entregar novos produtos e funcionalidades mais confiáveis e com maior frequência. Nesta dissertação é documentada a aplicação dessas práticas num caso real, na organização Glintt Healthcare Solutions. Irá ser realizado um caso de estudo de métodos, abordagens e tecnologias relacionadas com essas práticas, tendo como objetivo perceber a melhor maneira de implementá-las e tirar o melhor proveito da aplicação desses processos. É esperado que a realização deste projeto consiga diminuir ou colmatar os problemas verificados na organização e que lhe deram origem. Assim, espera-se que o projeto contribua para melhorar a qualidade dos produtos da organização e para melhorar a confiança dos clientes na mesma

Adapting a Stress Testing Framework to a Multi-module Security-oriented Spring Application

Programmeeritakse mitmekomponendilist süsteemi. Kolm põhikomponenti on järgmised: põhiserver (Spring rakendus), mobiilirakendused (iOS, Android), klienditeeninduse veebiportaalid. Kõige tähtsam süsteemi töös on põhiserver, kuna see on enamuse veebiportaalide ning mobiilirakenduste päringute sihtpunkt. See on mitmemooduliline projekt, kus kõik moodulid suhtlevad omavahel. Potentsiaalselt hakkab süsteemi kasutama sadu tuhandeid inimesi – kümneid tuhandeid paralleelseid sessioone. Seetõttu tuleb läbi viia süsteemi ulatuslik koormustestimine. Kahjuks on nii, et koormustestimise raamistikud oma originaalseisus ei sobi antud süsteemi testimiseks. Seega, koormustestimise raamistiku tuleb seadistada ning laiendada selleks, et see toetaks antud süsteemi spetsiifilisi protokolle ja võimaldaks testida kõiki komponente üheskoos. Hetkel on saadaval palju koormustestimise raamistikke. Mõned nendest on: Locust, Apache JMeter, Gatling Project. Need raamistikud erinevad üksteisest programmeerimiskeele, eriomaduste ning põhiloogika järgi. Kuna tegu on kommertsprojektiga, peab valitud koormustestimise raamistik vastama kliendi funktsionaalsete ja mittefunktsionaalsete nõuetele. Kuna koormustestimist viiakse läbi ainult põhiserveril, peab seadistama ja laiendama valitud raamistikku, et simuleerida teisi süsteemi komponente ja serveri protokolle. See töö annab kiire ülevaate varem mainitud koormustestimise raamistikest eriomaduste järgi, valib raamistiku, mida kohandatakse antud projekti raames koormustestimise läbi viimiseks ning kirjeldab kohandamise protsessi. Samuti toob see töö välja mõned koormustestimise raamistike piirangud ning kirjeldab meetodeid nende ületamiseks. Viimaks, süsteemi testitakse valitud raamistiku abil ning esitatakse ja valideeritakse tulemusi.A multi-component system is being build. Three main components are: backend server (Spring application), mobile applications (iOS, Android), customer service web portals. Our main concern is the backend server, because it is the destination of the majority of requests from customer service web portals and mobile applications. It is a multi-module project where all modules communicate to each other. The system is going to be used potentially by hundreds thousands of users with tens thousands of simultaneous usages. Therefore, extensive stress-testing must be conducted. Unfortunately, stress-testing frameworks in the original state are not suitable for the given system. Thus a stress-testing framework must be configured and extended to the point it supports the system’s specific protocols and can test all the system’s components together. There are numerous of stress-testing frameworks available. Some examples are: Locust, Apache JMeter, Gatling Project. These frameworks differ in terms of coding language, features and core logic. As it is a commercial project, the chosen stress-testing framework must also comply with client’s functional and non-functional requirements. Due to stress-testing being conducted only on the backend server component, the selected stress-testing framework must be configured/extended to simulate other components and the required server protocols. The thesis provides a brief comparison of the available stress-testing frameworks based on their features and written code language and define the one which is going to be adapted to conduct the stress-testing within the project and how the adaptation is done. The thesis also points out some of stress-testing frameworks’ limitations with techniques to overcome them. Finally, the system is tested using the selected testing framework and the results are presented and validated