On reducing release costs of embedded software

This study focuses on lowering release cost for an embedded software project by improving the continuous integration pipeline and by moving towards continuous delivery. The study is made as an assignment for a Finnish software company. The case project is embedded software project written with C/C++ programming languages. Additionally, the project consists of a desktop tool for managing the embedded systems, but no special focus is given to this tool. The goal of the study is to reduce both the total time of the deployment pipeline and the amount of active manual working in the pipeline. This is achieved by automating tedious steps of the release and by constructing an automated pipeline which produces all the needed files for the release. The work began by exploring the previous release process and by identifying the complicated or time-consuming parts of it. Based on the findings, three main focus areas were selected for development: work related to branching and file updates, work related to updating test systems configuration and work related to building the test binaries. After this, each of these three focus areas were improved one at a time by building tools to automate the steps with Python and Kotlin programming languages. Additionally, the continuous integration pipeline was further developed by taking Docker containerization technology into use, which provided better build environment isolation giving a possibility to better utilize binaries produced by the continuous integration server. As a result of the study, a proposal for the improved release process was created focusing on the automation of the tedious steps. With the new process total deployment time went down to about 4 hours from previous 7 hours and 40 minutes, and the active manual work went down to a bit less than 1 hour from previous 4.5 hours. Additionally, some of the steps might be repeated multiple times during a release. On the other side, it was found out that the process also had some steps which were not feasible to automate such as steps which currently require manual consideration from release engineer. Due to this, the resulting pipeline is not yet fully automatic. This would be a good candidate for a further study since overcoming this issue would make the pipeline fully automatic after the code freeze which would further increase the benefits.fi=Opinnäytetyö kokotekstinä PDF-muodossa.|en=Thesis fulltext in PDF format.|sv=Lärdomsprov tillgängligt som fulltext i PDF-format