In the conceptualization phase, the doctoral candidate together with the other authors planned the research objectives. As a corresponding author, the doctoral candidate submitted the manuscript for publication and managed the communication with the publisher.
Continuous Integration
Version Control in Continuous Integration
Version control systems in use today can be divided into centralized and distributed version control systems (CVCS and DVCS, respectively) (Muşlu et al., 2014). Although a central repository plays a role in the decentralized version control system paradigm, as opposed to the centralized version control system,
Automated Build and Testing
Continuous integration becomes less useful to developers the longer it takes to build (Hilton et al., 2017). Known approaches to test optimization include selection and prioritization of test cases (Elbaum et al., 2014).
Continuous Delivery and Deployment
The Deployment Pipeline
Testing as part of the deployment pipeline consists of performing automated and manual tests that are divided into test suites that test the validity of the built software version at different levels with an emphasis on automated tests (Humble et al., 2006). The following section covers some of the release models that can be used in conjunction with continuous deployment.
Releases
Release strategies where the changes are implemented and released to a proportion of users while the changes are withheld from others derive from the principle of canary release (Humble and Farley, 2010; Parnin et al., 2017). Any full releases to all users will follow the intermediate release phases if everything appears to be working and the quality metrics from the production environment look acceptable.
DevOps
Monitoring involves collecting and analyzing server and application health statistics with fit-for-purpose tools (Ebert et al., 2016). An overview of the five publications in the thesis is provided in Section 3.3, where research settings and results are summarized study by study.
Research Design
Case Selection
To broaden the range of companies and strengthen views for specific types of industries, more companies were recruited for the studies outside the research program. A multiple-case design with embedded units of analysis is used in a majority of the thesis studies. Software development companies in the studies form the actual study context for the cases.
Many of the companies involved in the studies operate in environments where many projects are running at the same time. Individual team members are also the embedded units of analysis, as qualitative data are collected about their personal opinions and attitudes toward software development and their understanding of the software process.
Data Collection
The interview typically included two researchers and one to two members of the software development team. A small number of personal level 1 questions about hypothetical situations and individual perceptions of software development were included in the interview protocol. Notes taken during the interview regarding the details of the development process were returned to the interviewees for verification after the interview.
Questions in the second set of interviews were mostly open questions, but several closed questions were also asked during the course of the interview. Information about the survey was sent by e-mail to all active projects in the company.
Data Analysis
Thematic synthesis is similar to thematic analysis, but the method emphasizes the importance of theme development in the analysis of data (Cruzes and Dybå, 2011). The survey included an open feedback section that was used to collect feedback on the use of the maturity model survey in the company. Thematic analysis of the open-ended feedback provided a sense of how respondents perceived maturity models in the context of their business, beyond the quantitative results.
Regarding the thematic analysis carried out in the study reported in Publication IV, the approach was similar to that of the first two studies. The themes of the questions in the semi-structured interview provided the framework for the thematic analysis, but the coded responses gave shape to the content of the analysis.
Summary of Publications
Metrics for Characterizing Deployment and Release
A release cycle consists of all the activities that occur between two releases and the release cycle time is essentially the time period between releases, measured in minutes, hours, days, weeks, months or years. A release cycle time of one month means that a new software version of a given system is released every month. This leads to several metrics that are useful in characterizing deployment capacity and release frequency: cycle time to potentially deployable software (de-.
In practice, there appears to be a large difference in the cycle time to potentially deployable software and the actual cycle time to production deployment (i.e. release cycle time). In some cases the difference is noticeable as for example in cases C5 and C10 where the release cycle time is a year or more, but the cycle time to potentially deployable software is a month or less.
Choosing the Right Release Frequency
Reasons for increased or decreased release frequency are explored further in the next section. One of the most important factors to consider is the field of application as discussed in the previous section. Continuous deployment is still an option to consider, and processes can be improved to simplify releases, which is less likely in the case of stricter domain restrictions or regulations.
Four different target categories of release frequency were identified when industry respondents were asked to list their current release practices and indicate where they wanted to be: fully automated continuous deployment, continuous deployment capability, on-demand deployment, and deployment calendar (Publication I). On-demand deployment is the most sporadic release frequency goal mentioned in the interviews.
Meeting Process Demands of High Frequency Releases
Activities in a Software Engineering Process
Each release is a milestone in software development, but in most cases maintaining software, monitoring software systems, and collecting implicit and explicit feedback from people and systems requires continuity in the development process even after releases. The key to making releases often lies in automation and tools, but making quick decisions in the development process requires flexibility throughout the process. Backlog management elements and sprints are part of the terminology and practice commonly used in the Scrum software development process (Schwaber, 1997).
Software quality is not only assessed by testing the correct functioning of individual functions in the program. Performance testing is an important aspect in the web domain where software systems may be subjected to different levels of users.
Determining Maturity of Software Engineering Pro-
Requirements Elicitation Backlog Management Bug Tracking Version Control Build Continuous Integration Artifact Repository Provisioning and Environments Deployment Unit Testing User Interface Testing Acceptance Testing Quality and Performance Code Review Communication and Feedback C1 CO notmentionedused used used used used used used notionednotused used used used used used used C2 CO notmention used used used used used used used used used used used not used used used used used used used used used used used used used used not used used not used used used used used not used used used not used used used used used used used used used used used used used used not used used used used notmentionedNotmentionedueded used used not used used used noted c6 es notmentionednotetionedueded used used used notmentionednotetionedirrelevant nottentioned irrelevant notmentioned notmentioned notmentioned used irrelevant C7 IA Used C9 MG Nottentioneded Nottentioned used Nottentioned Nottentioned NottentionionedNotementioneded used used nottentioned nottentioned used Notioned used C10 Mg Notontereded used used used used used used used used Notontered Noting Notated Notontered Notoned used used used used used used used used used used used used used used used used used used used used used used used used used used used used used not used used irrelevant irrelevant mentioned used used used C13 TC notmentionednotmented ionused used used used used notmentionedused notmentioned used notmentioned used notmentioned used used c16 ws nottentionedunesed used used nottentioned used nottentioned mened used used used used not used used used C17 ws nottentionedunesed used used used used Nottmentioneded used used used used used used used used C18 WS used used used used used used used used used used used used used not used used.
A Process for Continuous Software Engineering
Construction phases in the deployment pipeline should not only be automated, but also optimized for efficiency. Furthermore, carefully coordinated construction processes can save hours of construction time (Publication II). Nevertheless, any testing activity that requires significant human intervention, such as exploratory testing, slows down the deployment pipeline (Publication I). Automated acceptance testing is an area that should not be overlooked when considering the deployment pipeline.
Information should flow effortlessly between people and all activities at different stages of the deployment pipeline. Developers value timely feedback from systems such as continuous integration servers for code health monitoring and automated tests (Publication I).
Organizing Work in Continuous Software Engineering
Leadership and Showing the Way
After the section on validity threats, the results of the thesis are compared with previous work carried out in the area. This section elaborates on the threats to internal validity, construct validity, external validity, and reliability of the conclusions made in the thesis studies. Still, several conclusions made in the dissertation studies must be considered in terms of internal validity threats.
Reactions of the researchers in the experimental situation are also not irrelevant to the outcome. There are some plausible threats to the reliability of the inferences made in the dissertation studies. An analysis of industry release practices shows that release frequency has many aspects.
Process optimization can be large or small as shown in the thesis cases.
