ARCHITECTURE OF THE PROASENSE DEVELOPMENT ENVIRONMENT

Transcription

1 ARCHITECTURE OF THE PROASENSE DEVELOPMENT ENVIRONMENT Deliverable nº: D6.1 EC-GA Number: Project full title: The Proactive Sensing Enterprise

2 Work Package: Type of document: WP6 Deliverable Date: 28/10/2014 Grant Agreement No Partners: Responsible: SINTEF, FZI, ICCS, JSI, UNINOVA, NISSATECH, HSS, MHWIRTH NISSA Title: D6.1. Architecture of the ProaSense development environment Version: 1 Page: 0 / 29 Deliverable D6.1 Architecture of the ProaSense development environment DUE DELIVERY DATE: 31/10/2014 ACTUAL DELIVERY DATE:

3 ProaSense setup Page 1

4 Document History Vers. Issue Date Content and changes Author ToC Aleksandar Stojadinovic Deliverable ready for internal review /10/2014 Addressed reviewers comments. Final formatting and layout. Aleksandar Stojadinovic Aleksandar Stojadinovic Document Authors Partners Nissatech Contributors Aleksandar Stojadinovic, Aleksandar Stojanovic, Dusan Kostic, Boban Stajic Dissemination level: Document Approvers Partners SINTEF FZI Approvers Brian Elvesæter Dominik Riemer ProaSense setup Page 2

5 ProaSense setup Page 3

6 Executive Summary Deliverable 6.1 reports about the activities undertaken to fulfil the requirements from task 6.1, setting up the supporting website for integration and validation activities, investigating technologies for continuous integration activities and setting up a physical infrastructure. The first part of the deliverable refers to the need for supporting services and websites for later development, programming, integration and reporting tasks. The current commercial and open source offer of tools is analysed and conclusions have been drawn about which system to choose. It has been strived to cover most of the supporting requirements by least as effort and introducing as few different websites as possible. The system chosen, GitLab, is covering the crucial features such as code repository, issue tracking and wiki. Installation procedures, permissions and usage are covered in this part. The second part of the deliverable addresses the testing policies and tools. Testing is divided into three types, unit testing, integration testing and end-user testing. The most challenging is integration testing and most attention is dedicated to that. The third part of the deliverable addresses the issues of integration in large systems developed by different teams. We have defined the roles of continuous integration and which tools to use for this purpose. ProaSense Setup Page 4

7 TABLE OF CONTENTS 1. Introduction PURPOSE AND SCOPE STRUCTURE OF THE DELIVERABLE Code and issue management INTRODUCTION GITLAB INSTALLATION AND SETUP PERMISSION LEVELS AND ROLES ACCOUNTS CODE REPOSITORY GIT BRANCHING MODEL REPOSITORY SSH ACCESS ISSUE TRACKING ISSUE CATEGORIES ISSUE RESPONSIBLES WIKI WIKI PERMISSIONS Testing UNIT TESTING TESTING TOOLS INTEGRATION TESTING TESTING TOOLS END-USER TESTING Integration CONTINUOUS INTEGRATION AUTOMATED TESTING PHYSICAL SERVER VIRTUAL MACHINES AND PROXMOX Conclusion ProaSense Setup Page 5

8 List of figures Figure 1 - GitLab landing screen Figure 2 - GitLab project roles Figure 3 - GitLab group roles Figure 4 - Partners user accounts Figure 5 - GitLab protocol selector Figure 6 - Control panel SSH section Figure 7 - GitLab issues panel Figure 8 - Example of creating an issue Figure 9 - Jenkins management screenshot Figure 10 - Integration plan ProaSense Setup Page 6

9 List of tables Table 1 - Git and SVN feature comparison Table 2 - Creating a GitLab user Table 3 - Installing GitLab Table 4 - GitLab configuration addition Table 5 - GitLab startup Table 6 - SSH key generation command Table 7 - Issue label explanation ProaSense Setup Page 7

10 Acronyms Acronym VCS SVN CVS CI VCS CE WP SUT DOC JVM XP Explanation Version Control System Subversion Concurrent Versions System Continuous integration Version Control System Community Edition Work Package System under test Dependant on component (in context with SUT) Java Virtual Machine Extreme programming ProaSense Setup Page 8

11 1. Introduction 1.1 PURPOSE AND SCOPE In this deliverable we present the work performed in the first of five tasks of work package 6 of the ProaSense project. The main objectives of the work package are integration plans and integration execution, deployment activities, UI development as well as testing strategies, frameworks and activities supporting the software engineering process. Task 6.1 ProaSense setup is one of the first steps of the software development process. This document describes the research and deployment of a support website for code repositories, wiki, and issue tracking to be used internally by the partners. We have analysed multiple solutions and combinations and decided on a system called GitLab 1 version 6.92., which is described in Chapter 2. Issue tracking categories are also defined in this task. Testing frameworks and strategies are also researched and services are set up as part of this task, as well as continuous integration infrastructure. This is done to minimise the chance of errors in usually manual tasks and diminish the risks of failure in repetitive jobs. After analysing the currently available systems we have chosen SonarQube 2 for code quality assurance and Jenkins 3 as a continuous integration server. Infrastructure deployed for these supporting components will be used for integration in later phases of the project where component integration is scheduled, and a description of the infrastructure is shown in Chapter 4. The chosen technologies used for executing the task should be proven and used successfully in other projects, products or organisations. 1.2 STRUCTURE OF THE DELIVERABLE The deliverable is structured as follows: Chapter 2 first discusses the need and requirements for code management tools and issue trackers in a distributed development team. It provides an analysis of the current tools available for development support services and websites. Permissions and roles in the supporting systems and other policies, such as code branching are also covered by the analysis ProaSense Setup Page 9

12 Section 3 presents the need for testing and the foundation of testing in software development. Also, different levels or testing are described and they are positioned within the work packages. Section 4 discusses the need of continuous integration and other automation solutions that software developer could use to minimize the chance of error. This includes automatic deployment and automated testing procedures. The infrastructure that will be used to deploy some or all components of the project is also described. 2. Code and issue management 2.1 INTRODUCTION Code control and issue tracking is important for any project. The solutions applied to ProaSense are described in this chapter. Software controlling a repository and code sharing is called a version control system (VCS). The usual choice of VCS falls between centralized and more modern distributed systems. Typical representatives of each group are CVS, Apache Subversion (SVN) from the first, and GIT from the second. Although centralized systems are still more popular, largely due to legacy reasons, distributed systems have multiple advantages that make them a better choice for newer projects. The distributed nature gives the developers more flexibility in their own code management process (not all code is or should be pushed to the central, shared repository) and the practice generally keeps the main codebase cleaner. Also branching is preferable in an environment where multiple development teams work on multiple features. Keeping code changes in branches and controlling the merges minimizes chances of integration errors. Since the programmer has the choice to use local branches, he may also choose at which point he/she should push the code to the central repository. A connection to a central server is not needed for the programmer to use all of the features of the VCS (i.e. local branches). The disadvantage of such systems is a slightly more complicated workflow and they are more complicated to use. Table 1 - Git and SVN feature comparison Feature Git SVN Performance Generally faster than SVN Generally less Checkout method Clone entire repository and crate a Checkout a part of a repository mirror Space consumption Smaller repositories Larger repositories Locality Distributed Centralized ProaSense Setup Page 10

13 History Each branch carries its history Branches carry only changes Clients & UI s Younger, less mature (but usable) More of them, more mature Branching Regular way of work On rare occasions, introduces overhead After an analysis of the most important features of both systems (shown in Table 1) we have chosen GIT as a version control system. Nevertheless, this is only an engine, without a specific UI and user friendly options for creating users, managing branches, looking up accesses to the code base and differentiating the previous and current versions on the central repository. For this purpose a shell application is necessary, for example a system like GitHub 4. The shell should be deployed on a selfhosted server, so cloud solutions like BitBucket 5 cannot be used. GitHub has private settings for its projects but it is costly and a self-deployed version is very expensive. Three free solutions are available: GitLab 6, Gitorious 7 and Gogs 8. Gogs is still in beta phase and not considered stable enough for production use, especially not in a long running project. Gitorious is a stable project, however, lacks on features. It is missing an issue tracking system and does not support continuous integration (CI) tools (see Section 4.1). Also the development of GitLab is more active than Gitorious, which means possible bugs or faults with the software can be actively resolved. While researching GitLab it is noticed that it has issue tracking, wiki and CI integration, which is already needed for our project. Also, the recent financial injections and huge companies using it ensure its development will be stable in the future so GitLab Community Edition has been chosen. 2.2 GITLAB GitLab Community Edition (CE) is open source software providing the possibility to collaborate on code, e.g., create projects and repositories, manage access and do code reviews. GitLab CE is an onpremises software that you can install and use on your server ProaSense Setup Page 11

14 Features: Completely free and open source (MIT license 9 ) Unlimited users, collaborators and repositories Keeps code secure on private server Manage repositories, users and access permissions Perform code reviews with merge requests Extended permission system with 5 access levels and branch protection Line comments and discussions in merge requests and diffs Each project has a wiki backed up by a separate Git repository INSTALLATION AND SETUP In this chapter we will describe the process of installing the GitLab VCS. A virtual machine has been prepared with: 2 x 2GHz Intel Xeon CPUs 2GB of RAM 20GB Hard drive CentOS Linux After installing the operating system and setting up the network interfaces, a user is created for the GitLab (Table 2). useradd Gitlab su Gitlab passwd <password> Table 2 - Creating a GitLab user Next, GitLab can be installed. A number of official installation scripts are ready for several popular operating systems, currently Ubuntu, CentOs and Debian. A script for CentOs is used, shown in Table 3. Table 3 - Installing GitLab curl -O _omnibus-1.el6.x86_64.rpm sudo yum install openssh-server sudo yum install postfix sudo service postfix start sudo chkconfig postfix on sudo rpm -i Gitlab-7.3.2_omnibus-1.el6.x86_64.rpm ProaSense Setup Page 12

15 GitLab Configuration is located in the file /etc/gitlab/gitlab.rb. A proper hostname and account should be configured for the system to work properly. The configuration added to the file is shown in Table 4. Table 4 - GitLab configuration addition Gitlab_rails['gitlab_host'] = "Gitlab.nissatech.com" Gitlab_rails['gitlab_port'] = 80 Gitlab_rails['smtp_enable'] = true Gitlab_rails['smtp_address'] = <classified> Gitlab_rails['smtp_port'] = 465 Gitlab_rails['smtp_user_name'] = "noreply@nissatech.com" Gitlab_rails['smtp_password'] = <classified> Gitlab_rails['smtp_domain'] = "nissatech.com" Gitlab_rails['smtp_authentication'] = "login" Gitlab_rails['smtp_enable_starttls_auto'] = false Gitlab_rails['gitlab_ _from'] = "noreply@nissatech.com" Gitlab_rails['gitlab_support_ '] = "info@nissatech.com" After that the system can be started with the commands from Table 5. sudo Gitlab-ctl reconfigure sudo lokkit -s http -s ssh Table 5 - GitLab startup On first login, a screen like the one in Figure 1 can be seen. GitLab is available at ProaSense Setup Page 13

16 Figure 1 - GitLab landing screen PERMISSION LEVELS AND ROLES Projects on GitLab are divided into groups. Groups have independent settings in terms of permissions and projects in these groups have the same root namespace, as well as the inherited permissions. However, permissions can be overridden per project. User permissions are set up by assigning a user with a role. A user can have only those permissions that a role carries and the role settings cannot be overridden in any way. That means we cannot assign a user with a role Developer and then add just a few permissions from the Master role. Permissions each of the roles has on GitLab are shown in Figure 2, on the project level, and Figure 3 for the group level. ProaSense Setup Page 14

17 Figure 2 - GitLab project roles Figure 3 - GitLab group roles GitLab projects are created for each software project. For each Java or Python project, for example, a GitLab project is set up with its name. The URI for pushing/pulling/cloning the code is automatically generated. ProaSense Setup Page 15

18 All of the projects are put in one group, ProaSense FP7. Other groups can be created by the administrators on partner request or if the original ProaSense FP7 group gets too large for managing. Reviewers and the project officer will have the Reporter role since they will have no benefit of the remaining privileges from Figure 2 - GitLab project roles ACCOUNTS Partners have their accounts created by contacting any of the GitLab administrators. An account is created and a link for verification and password setup is sent via . Partners provided a list of accounts and desired roles themselves. Figure 4 - Partners user accounts ProaSense Setup Page 16

19 2.3 CODE REPOSITORY GIT The most important feature provided by GitLab is the shell over the central Git repository. Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency BRANCHING MODEL The development model is greatly inspired by existing models used in practice. The central repo holds two main branches with an infinite lifetime: master and develop (or just dev) The master branch is a standard way of calling the main branch which always reflects the current production-ready state of the code, as soon as it is production-ready or the latest state of development when there is no production ready code. Parallel to the master branch, another branch is called develop, sometimes later than the master branch. We consider the remote develop branch to be the branch where the source code always reflects a state with the latest delivered development changes for the next release. It is also called the integration branch. Usually automatic build systems make builds from this location. When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. Therefore, each time when changes are merged back into master, this is a new production release by definition. Next to the main branches master and develop, different development models use supporting branches to aid parallel development between teams preparing for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited lifetime, since they will be removed eventually REPOSITORY SSH ACCESS Git can support multiple protocols for code access, for security reasons the GitLab is setup only to use SSH access. That means setting up the right SSH keys for client machines for access. Only the GitLab side of the setup can be explained since the developers must set up their own IDE or Git client for functioning with a Git SSH connection, and there is a huge number of IDEs and clients. ProaSense Setup Page 17

20 Figure 5 - GitLab protocol selector It is important for the protocol selector to be on the SSH option and use the generated URI to access the code, like in Figure 5. Clients can generate their SSH key pair most easily in any Linux or Unix-based operative system using a command from Table 6. Windows users may use a tool like PuttyGen 11 for the same purpose. Table 6 - SSH key generation command ssh-keygen -t rsa -C "aleksandar.stojadinovic@nissatech.com" Upon generating the SSH keys developers should add the public key to their GitLab control panel. The key can be added in the control panel under the SSH Keys section, after clicking on the Add SSH Key button. Figure 6 - Control panel SSH section 2.4 ISSUE TRACKING An issue tracking system (or support ticket, request management or incident ticket system) is a computer software system in charge of managing and maintaining lists of issues in order to monitor their fixing or resolution. A support ticket should include vital information for the account involved and the issue encountered. The issue tracking system is a valuable source of knowledge about the most common points of failure, recurring issues and experience. Using an issue tracking system is one of the foundations of organising software projects with multiple teams and developers ProaSense Setup Page 18

21 Issue trackers can be very advanced (and very expensive as a matter of fact) and complete companies have been formed only to build and maintain them. For the ProaSense project we do not need advanced systems since there is not too many developers and the client (or reviewing) group is limited in size, so the integrated GitLab issue tracking utilities are good enough to serve the purpose ISSUE CATEGORIES The GitLab system does not differentiate between different issue types and categories (is it a request like a new visualisation graph is needed or a bug) but it utilises a labelling system so each issue can be closely described matching its purpose and criticality. The issue screen for one project (the event replay utility from D1.3 Data formats and protocols, to be precise) is shown in Figure 7. By clicking on the New Issue button the user will be presented with a screen shown in Figure 8. Some of the labels are automatically generated and a subset of them will be used for tagging new issues. The purpose of each is described in Table 7 - Issue label explanation. Table 7 - Issue label explanation Label Bug Feature Enhancement Suggestion Critical Confirmed Support Meaning The reporter has discovered a bug (or something she/he believes to be a faulty behaviour). The reporter is requesting a new feature The reporter wishes an existing feature enhanced A suggestion for the development team A complementing label to any other, the issue must be resolved as soon as possible A complementing label to any other, used by a developer to mark the issue as confirmed/reproduced The reporter has not found any adverse behaviour but needs technical support ProaSense Setup Page 19

22 Figure 7 - GitLab issues panel Figure 8 - Example of creating an issue The issue consists of a title, a textual description, assignment and labels. The title should be a very short but precise explanation of the issue ProaSense Setup Page 20

23 The description should hold a detailed explanation of what is wrong with the component or what is requested and (if it is a bug) a mandatory explanation how it is possible to reproduce the bug ISSUE RESPONSIBLES Each issue can be assigned to a developer. Unrelated to whom it is assigned to, it will be visible in the issues panel for the project and in the group. If it is not known who is the responsible for that exact functionality, the bug should be assigned to the component responsible. In case the responsible is not stated then it should be assigned to the WP responsible. If that is also unknown, assign the issue to Boban Stajic (boban.stajic@nissatech.com) or Aleksandar Stojadinovic (aleksandar.stojadinovic@nissatech.com). When the issue is assigned or reassigned the developer shall get an notification of it. Nevertheless, it is highly recommended for each development team to put an issue responsible in the README.md file in the root of the project or in the project description, so it can be easily visible on the project page. 2.5 WIKI The GitLab system also incorporates a wiki module for documentation, descriptions or any other type of document. A wiki is a rich web application which allows people to create content in a collaborative manner with other participants. In a typical wiki, content is created by writing using a simplified markup language or a rich-text editor. Gitlab wiki uses an extension of the Markdown 12 syntax, called the Gitlab flavoured 13 Markdown. The reference to it can be found in the Help 14 section of Gitlab. It does not contain a rich-text editor, so the markup must be manually entered. Partners are expected to describe their components on the wiki in a way that could help other partners using or integrating them. The description should use standardized ways of software development, i.e., UML diagrams, block and flow diagrams etc ProaSense Setup Page 21

24 2.5.1 WIKI PERMISSIONS Recalling on Figure 2 we can see that only roles of Developer, Master and Owner can manage wiki articles. With this in mind, technical partners should designate members of their teams with developer roles to create wiki content. All members of a project can read the wiki articles. ProaSense Setup Page 22

25 3. Testing Before proceeding we must define a term call System Under Test (SUT). This is an often used term in literature and used when describing tests, testing procedures and generally in any topic related to testing in software engineering. With SUT we describe a part of the system that is being tested in a procedure. Depending on the Testing type, SUT may refer to a single class or to a whole application. Also the term DOC, or Depended On Component can be found. DOC marks any entity that is required by an SUT to function. Most of the time a DOC is of the same granularity as the SUT, e.g. if the SUT is a class, then it uses other classes, if it is a module, then it collaborates with other modules. As with granularity, test can cover a method of a class, or multiple methods, or the complete functionality of one class. Those types of tests fall under the category of unit tests and the SUT is usually a class. In this phase, object mocking is more regular and the SUT is monitored as a independent entity in isolation from other components. As tests grow and incorporate more classes and intercommunication between them we are getting into the zone of integration tests. Integration tests are more comprehensive and often test a part of system, or complete functionality, the correctness of the output based on the inputs and corner-cases and they are rather looking for features that are not working, where unit tests are rather confirming something is working. Integration tests may vary in integration scope between integrating two classes to integrating complete systems. End-user testing is a separate testing type, and will mostly be covered in WP UNIT TESTING Unit testing is a fundamental part of software development and the first step in finding unobvious bugs. Writing easily testable code leads to good, decoupled architecture design since architecture with low decoupling usually proves itself as a bad design. Unit tests are mostly important for the programmer in charge of the developing component and its development team. Automatic build tools and continuous integration servers may use unit tests to choose whether a build should be executed or not, because recent changes may have affected correctness of the software by some side effect. Unit testing procedures will be carried out by technical partners on their own components in the scope of WP2-WP5. ProaSense Setup Page 23

26 3.1.1 TESTING TOOLS Unit testing puts lower level systems to testing. That is the reason a plethora of testing tools is available for different programming languages, frameworks and with different features. Based on an inquiry to the technical partners a list of proposed unit testing tools is gathered: Java/JVM 15 : TestNG 16, JUnit 17, ScalaTest 18, Clojure 19 integrated unit tests Node.js: node-unit 20 C++: xunit++ 21, googletest 22 Mocking tools: Mockito 23 All tools are free to use in commercial environments INTEGRATION TESTING Integration testing is the most challenging part of the testing process in the ProaSense project. Integration tests in ProaSense should test integration between different components. This is underlined by the fact that integration testing cannot be defined end-to-end because each project lives a separate life and has its own integration issues. To recall, integration testing is a testing process which tests complete module functionalities, communication between modules, and aims to find faults in the system functioning. In ProaSense integration testing will be applied on multiple components and communication between them and the correctness of the result. Since the middleware used will be a broker or a similar pub/sub component which most of the components will be using, communication can be easily monitored on certain topics or queues. This allows us to monitor the communication correctness itself. Using the same mechanism we can also look upon the data that is being transferred and check the payload. A challenging part of this testing procedure is the asynchronous nature of the components and the testing will have to await the messages in the right sequence. Web services would have to be tested in a black box manner or in combination with a database (or databases) the service is interacting with to prove its proper functioning ProaSense Setup Page 24

27 However, parallel development may cause issues with components not being available at the same and the DOC s of the SUT s are not ready. This can be solved in two ways, the big bang testing model or the incremental testing model. In the big bang testing model the system is being tested only when all of the components are finished and everything is almost production ready. This has its own issues because this does not aid reusability and in case of peculiar errors it is hard to find the root cause. On the other hand, incremental analysis proposes a model where components are tested as soon as they are ready and available. If component X is finished but depends on a component Y which is not, the component Y will be replaced with a stub with the same interface and a simulated behaviour known in advanced, so component X can be tested without the risk of Y being faulty. An alternative to the incremental approach is the bottom-up approach, but it is not always possible to implement it. In this approach the first components to be tested are the lowest level ones which do not depend upon any component. If lower level components can only be tested when integrated in another component, than a simulating component called a driver is created which has the interface of the final component it mimics, but its only purpose is to invoke its dependencies and therefore test them with predefined sets of data TESTING TOOLS Strange as it may seem, there are no popular tools explicitly declared as end-to-end integration testing tools. Reason for this may be the overall divergence of big systems implemented with multiple integration techniques so it is hard to create a tool which fits all needs. JUnit has been used much earlier; however it is an old tool which is less regularly updated than TestNG. The most popular unit testing tools are also being used for creating integration tests. Since ProaSense is mainly being developed in technologies based on the JVM, TestNG has promoted itself as a tool capable for integration testing, as well as unit tests. 3.2 END-USER TESTING End-user testing, or user acceptance testing, consists of verifying that a software solution satisfies the user. It is not considered system testing in term that it does not look for bugs or stability directly, but rather is there to ensure that the solution will work for the user, i.e., test that the user accepts the solution in the state and condition presented to the user. This is often equivalent to beta testing, a phase where no more innovations are added. The project is only tuned in that manner that it complies with the requirements of the user, while the product has coarsely been developed in ProaSense Setup Page 25

28 accordance with them in previous phases. Users of the system perform tests in line with what would occur in real life scenarios. This testing should be undertaken by a domain expert from the use-case partners, i.e. MHWirth and Hella Saturnus. The requirements to which the ProaSense system will be compared to are developed in work package 7, along with the evaluation technique. The UAT acts as a final verification of the required business functionality and proper functioning of the system, emulating real-world usage conditions on behalf of the consuming clients (Hella and MHWirth). If the software works as required and without issues during normal use, one can reasonably extrapolate the same level of stability in production. User tests, usually performed by clients or by end-users, do not normally focus on identifying simple problems such as spelling errors and cosmetic problems, nor showstopper defects, such as software crashes; testers and developers previously identify and fix these issues during earlier unit testing, integration testing, and system testing phases. As well as developing the requirements, the end-user testing will also occur in WP7 in two iterations and will be done by end-user partners. ProaSense Setup Page 26

29 4. Integration 4.1 CONTINUOUS INTEGRATION Continuous integration (CI) is a software engineering practice of merging all developer working copies with a shared mainline several times a day or on certain hooks. It was adopted as part of extreme programming (XP), which did advocate multiple integrations a day, perhaps as many as tens a day. The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. Initially this was conceived of as running all unit tests in the developer's local environment and verifying they all passed before committing to the mainline. This helps avoid one developer's work in progress breaking another developer's copy and reducing the chance of repetitive tasks. If necessary, partially complete features can be disabled before committing using feature toggles. Modern applications of the concept introduced build servers, which automatically run the tests or scripts periodically or on commit hooks. Today, many organisations have adopted CI without adopting the extreme programming paradigm. Organisations using CI typically use a build server to implement continuous processes of applying quality control in general small pieces of effort, applied frequently. In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes. This continuous application of quality control aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development. This is very similar to the original idea of integrating more frequently to make integration easier, only applied to QA processes. For the ProaSense project we have selected Jenkins 24 continuous integration server, whose management screen is shown in Figure 9. Some of the partners already use it in their everyday work so there will be no overhead with introducing it into the project. It supports a wide range of 24 ProaSense Setup Page 27

30 languages, IDE s or platforms 25 and, based on the survey filled out by the partners, it is versatile enough to support the partner s needs. Figure 9 - Jenkins management screenshot AUTOMATED TESTING Along with Jenkins CI server we have chosen to install a tool called SonarQube which is a QA management, web-based application. It is useful as a supplement to using Jenkins CI with its advanced dashboard which can track different metrics of code quality or test results. Also it can apply different analytics or code coverage tools to give a high-level overview of the code. 4.2 PHYSICAL SERVER Two machines each with four Intel Xeon i5 octa-core processors, 160GB of RAM and 3TB of storage space have been dedicated for the development purposes of ProaSense. These resources are being utilized by creating para-virtualized machines with hypervisor software called Proxmox ProaSense Setup Page 28

31 4.3 VIRTUAL MACHINES AND PROXMOX The machines mentioned in section 4.2 are utilized via virtual machines. The virtual machines are level 1 virtualized (para-virtualized, bare-bone virtualized) which means that they use the operative system kernel of the host hypervisor (Proxmox has a Linux kernel) and provide services to applications from that kernel, not their own. That leaves a much smaller memory, disk and CPU footprint and overhead per virtual machine. Partners do not need to have any contact with the virtualization layer as Nissatech is responsible for creating the virtual machines on partner demand by the specification partners provide ProaSense Setup Page 29

32 5. Conclusion This document described investigating, analysis and deployment of tools and solutions that a project like ProaSense needs for proper development. Those solutions include, as mentioned, are integration and validation supporting websites, code and issue repositories, modern continuous integration tools and physical infrastructure. We believe that the selection of tools described in this document fulfils all the requirements for future project development. Most of the components in ProaSense will be developed in two cycles, shown in Figure 10, allowing incremental upgrades and advancement within the project. Integration will also follow up on that principle, introducing more optimal solutions in the second phase, based on the lessons learned from the first phase. The supporting systems mentioned mostly in the first part of this deliverable will completely support both cycles of the integration plan. Figure 10 - Integration plan ProaSense Setup Page 30