Our industrial paper for SPLC2022

paper/.gitignore

@@ -0,0 +1,10 @@
+/texmfs
+/*.aux
+/*.log
+/*.out
+/*.bbl
+/*.blg
+/*.fdb_latexmk
+/*.fls
+/*.synctex.gz
+/paper.pdf

paper/challenge.tex

@@ -0,0 +1,76 @@
+\section{Challenge}
+
+Our migration method is supposed to be a generic solution for a migration from a
+polyrepo project landscape to a monorepo SPL, but our circumstances might have
+some influence on the ideas that we share in this paper. This section will
+explain the challenges we had, both coming from the products' nature and its
+industry and also from our corporate processes and strategies.
+
+The projects that we migrated are in the area of electric cars for premium
+automobile manufacturers. The software is written in (Embedded) C and Matlab and
+modelled with AUTomotive Open System ARchitecture (AUTOSAR) with C code
+generators. These projects must fulfill Automotive Software Process Improvement
+and Capability Determination (ASPICE), ISO26262 and other processes, standards
+and regulations of the automotive industry during their development phases to
+stay competitive and meet legal requirements. A company will less likely get a
+new inquiry when the standards and norms are not fulfilled. The standards are
+relevant for the entire SPL development and do not only apply for the delivered
+software product, but also for supporting processes and tools like the build
+system. Additionally, the build system must be able to handle third party source
+code deliveries without modifications. One example for this are AUTOSAR
+deliveries. The dependency to a delivered AUTOSAR package is not only a
+challenge for the toolchain, but also a chance. Due to AUTOSAR's layered
+architecture and its interface and component design, it already provides modular
+abstraction for separation of concerns, that can help in building SPL core
+assets and to maximize functional reuse.
+
+All migrated projects of our SPL base on the same product, a complex sensor
+cluster. For historic reasons every (customer) project was managed as a separate
+Dimensions repository. Dimensions is a Source Code Management (SCM) system
+similar to Revision Control System (RCS) used at the Marquardt GmbH for source
+code administration and project documentation. Each individual source code
+repository is a self-contained ready to build project, including all required
+tools and libraries to build the product binaries, like compilers, MSYS and GNU
+Make. The C code was validated with Jenkins nightly builds. Those Jenkins
+scripts were located in separate repositories, not part of the project's
+repository itself. Unit tests were not running with every change of the source
+code as part of CI/CD, but were running on demand.
+
+Whenever a new customer project was kicked-off, it also triggered the start of a
+new software project. This software project then started as a clone of another
+already existing project (`clone-and-own'). This approach had several benefits:
+the setup time was short and because a mature project was taken as basis, the
+project's software was stable already and debugging and adapting was possible.
+There was less work for generic parts and only hardware and customer specific
+modifications were required. However, this approach also caused a lot of
+disadvantages. By simply cloning an existing project there was not only a copy
+of functionality available in the new project, but also a copy of all its flaws.
+Because of a large number of copies a possible refactoring of reused code had to
+be merged back and this meant a high effort. If refactoring is never done, this
+approach can result in software erosion, as it did in our projects. The software
+erosion noticeably led to higher maintenance efforts at the end phase of the
+development and brought up errors late during the product lifecycle. For all the
+teams working in these projects, with the problems mentioned above, the idea of
+migrating to another platform including a new tool chain, not only sounded like
+a mammoth task but unrealistic too, having in mind the tightly planned release
+schedules.
+
+With our migration to SPL we try to tackle as many as possible of the mentioned
+challenges. The migration is only partially done and still ongoing, but we did
+not detect major issues so far. At the same time, we managed to:
+\begin{itemize}
+  \item migrate `clone-and-own' sources to our SPL,
+  \item add variant handling capability to the build system,
+  \item replace the outdated SCM system by Git and Bitbucket,
+  \item introduce a CI/CD system,
+  \item introduce a unit test framework as integral part of the development,
+  \item automate the setup of the build environment and reduce the repository size drastically,
+  \item stay compliant with all rules and norms,
+  \item train the team and
+  \item still keep release plans.
+\end{itemize}
+
+We will not write about all solution aspects in this paper. The focus will be
+on the source code migration process and less on the tools, processes and
+performed trainings. Our build system implementation is freely available on
+Github.com~\cite{GithubSPL}.

paper/conclusion.tex

@@ -0,0 +1,54 @@
+\section{Conclusion and Future Work}
+
+This work provides an iterative and incremental migration strategy towards SPL
+for the software of a real-world product family of an automotive supplier. We
+proposed three steps to perform the migration of a project's software repository
+to an SPL variant: (1) \textit{Complexity Reduction}, (2)
+\textit{Modularization} and (3) \textit{Versioned Dependency Management}. It was
+shown that our proposal can be applied to the repositories of a product family's
+software at any time of the development phase due to the fact that any of the
+three steps can be applied incrementally and each transformed variant can
+iteratively continue with the next migration step independent of the others.
+With our proposal we:
+
+\begin{itemize}
+  \item established a stable SPL with variants buildable at any time,
+  \item reduced workload of developers by reducing the number of repositories,
+  \item increased collaboration beyond project borders and
+  \item integrated all software sources of a product family into one git
+        repository.
+\end{itemize}
+
+We implemented a build system with modern CMake fully supporting the concept of
+SPL variants.
+
+At the submission date's point of time we managed to proof about 50\% of our
+concept. The build system prototype required two persons full-time for six
+weeks, the implementation for migration step one and two required two persons
+full-time for three more months. Over a time frame of two months we
+incrementally added ten variants, while each import to the SPL was really fast
+due to the automated importing mechanism. We already started with
+\textit{Modularization} of software components, but only converted a few
+components and begun with removing duplicates. Recently we focussed more on
+automation than on the SPL migration, as we saw more advantages there in the
+long run. The automation for CI/CD is helpful for the migration as well.
+Nevertheless, the build system requires some more features to be able to handle
+our migration step three and we plan to implement them in the coming months, in
+parallel to the \textit{Modularization} step of the software components.
+
+Additionally to the build system implementation and the actual migration of the
+embedded source code, it is required for us to qualify tools which have an
+impact on the created binaries or the processes to build them. This tool
+qualification is requested by the ISO 26262 standard for safety reasons. We must
+take care that CMake, Ninja and KConfig are properly qualified. On the other
+hand, proprietary software might come with safety evaluations already. This
+should be kept in mind, when deciding for your tool landscape.
+
+Besides all the discussed technical challenges, there were also social obstacles
+on the way to SPL. Fear was probably the strongest emotion we faced. At the
+beginning we were certain that all required build system features were
+implemented and we always had a backup plan to go back to the original
+repositories. There was no real threat and still no one had enough confidence to
+start the migration. Afterwards we do not see a reason for hesitation, but
+sometimes it simply needs someone brave in the team or someone pushing you. Our
+conclusion is: Just do it! And if you break it, make sure you can fix it fast!

paper/images/step2-modularization-flow.drawio

@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2022-06-10T14:12:46.079Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/19.0.3 Chrome/102.0.5005.63 Electron/19.0.3 Safari/537.36" version="19.0.3" etag="4Wro6nL2rmszLiauxm7u" type="device"><diagram id="C5RBs43oDa-KdzZeNtuy" name="Page-1">7VxZc9o6FP41zLQPZLyC80homt5u0zb3Nu1TR9jCqJEtV5ZZ+usr2RLY2BgTNnObzISgY1lIR+f7ziKTjjkM5ncURJMPxIO4Y2jevGO+6hiGYZv8VQgWUmD0MoFPkZeJ9JXgHv2GUqhJaYI8GBc6MkIwQ1FR6JIwhC4ryAClZFbsNia4+KkR8GFJcO8CXJY+II9NMqlj9FfyNxD5E/XJeu86uxIA1VmuJJ4Aj8xyIvO2Yw4pISx7F8yHEAvdKb08/LN4wO8fe3dvP8e/wH837/79+LWbDfZ6l1uWS6AwZE8e+iuZv/Ws5F33mzebzP0PP35c064uFxuzhVIY9Lj+ZJNQNiE+CQG+XUlvKElCD4phNd5a9XlPSMSFOhf+hIwtpDGAhBEumrAAy6twjtg3cfuVLVvfc1dezeXIaWOhGiGji9xNovk9f211W9oq3PcJUhRABqkUNlSoVHxMEurCGi1KA2GA+pDVadvOOgoV56xT7tcdJHyOdME7UIgBQ9OiCQOJBH/Zb7Xb/I3c8B02X057CnCiVgcoAlwlhjYo2cVsghi8j0CqiRnniuKegjjK4DtGc2EbO+p4CimD81qlKEayrOwWSUh9uYxZDt1SNMkBW8kOrsUlPTxDaA8IKdewFUL9VkFIWW8VhG5aCyGz1zII6SVVPUNoZwgZTSHktApCRg2Ehq2FkOW0C0I9sz0Q0q4cpx5FvLEOhqcia0xC9hoECAvBG4inkCEXyAty4roh20OCifhAD45BgtkR3JjdEISGcWgQprcOKAWLXIeIoJDFuZE/CUEumFozY2XHrzf0N43a/vxNNoOVIS+XsoeTtUsU4ZIgIiFM19YDgWCBcBRH6YZqZdEaMmJGyeMyHTSKNs3TvEj0C+a+SIivxpjM3Amg7CrgJoO6HnGTILWWmyoyOl7YqxU0r19XMI5TZpze0RjHemacNjBO/7IYx9IugXH6z4zDs4S2MY5x4YzTMuZwLos57HomaAlzOM/MwZOjljGH02sPc9QXGPakiKfGNAemFsUYW6nF0Y9CLVu5wLLXTC2bqbxrzdp2o4X6cnDImaDaSvRO3rvYtVay2ubCJq/2fMM2eyCepBadkkfKLMqGOoappT9ntIa+dWhr2K8yVS5NDSeExFB8GP/F0AeumM6S4cWF0OOvAZmKXkhIOC3wl4lo+zDkIYErrgQRhoKa+TpIyAUeotBlhC6uSvazIiJ9A5HnzOlYnG5Y1wUEmXqZ03X7lCUvs0XhYNOqcRGuxja8HhqI54v49gNiOai652tg5f3HGEUx3I6SUp24iLFjgUjXi4HRuavGzt95/N+uPMxqevZpma1CpZp3DpU8m0k15KFpwap6vxLxlMzNCLiPfmo/XTdT60BM1x+9MGy7Y/B5aPk3L7McCaMQdhUexA36dTRPL6lx+Ttf/P3C90g40aXDzXvmGeIYE08QuQnPxLTU607FUdMIYcQWau4jqkZTEq6ddEFKuo97rrKwSlM8lR+3raZ+3NzfjurPeQ8UG1cUXjaHuk+NpA/NAWZTDjj4I0QbyrT9NU9lHC1hqg/jjmcU50mGGu+0qpmcu15vVxvCUatoSkk51/KJEhfGcZmlPWEggtYF6wMx9nqPfAHuMNU1D7ooFnlbNd8XPQIGI4hvlp5P2Zg07JPGIju4iV7RTfR6dtlN6BVuYik8fLxRPga+Fcn2heUA60+O9JwzJwF2GWxlpYbeQDyMzVsuBnGM3KIuiznBvkVMlR/sSfCbfHu/rc798Gl3NafrRpHTbccuDpEtqeTcywNdFweytGZRwq5OSK93Qlv7m6c4+rHL/BSSytjmvfAIAjUwRr/BKL2krZETRj53L68wHAtICHrhEMIDKR4RxkhwbldTSyfyCx1yeZ1lYbw5UyqA7WntXVX7V7eQ8TiG+0attQXsipQ4jkBYmROXs1ge6niJyzJdxVl5mIzXstkXFPAUN8t005EjSn5yfb/MZa3ZZ25NW7XtvvIiYxhLmaJiAa0i1bWqYph1Gjtcwc2uJIQTFdxOccS0py2cJylzmpbgnHadUDltLMHJs680FdO8JMJ8/xmMFYmxCYo7VWdmHg/fplnRjqYDxJyl46u/tC5nGec+X1NPaPx/DwfadQ7QmIRU4b0tJFQOer5AHsBAAeowCUZplFIKYKbZtzzKNZm/LzCxqs7STxuYqEQut4mD9K588UwDU4BwGtGnU0iD/DHyEyplmY3HS0ofQ8CSlMwD+b1ylIaqWGzn877b9in3PQ6GX8y3tw8PdPTz8+Db3fARfqz49tUCliF56Ulr41y06a5vfmja6Re2uHRu0mDneHP1XwWy1HT1rxnM2z8=</diagram></mxfile>

paper/introduction.tex

@@ -0,0 +1,54 @@
+\section{Introduction}
+
+Development of product families rather than individual products is a goal for
+many engineering companies. Product Line Engineering (PLE) is a widely used
+approach for reaching this goal. It is common and accepted for electronic and
+mechanical developments and thus especially important for the automotive
+industry that historically comes from this area~\cite{bookssp19X19}. However,
+for quite some time the automotive industry is constantly moving its focus
+towards the development of software. This development is still ongoing and
+becomes more and more complex each year~\cite{ICSE03498}. In order to stay
+competitive in the future and to realize a competitive advantage, a fast
+adaption to the market and to customer needs is also required for software.
+Offering off-the-shelf software products with tailored customer features will
+increase the company's revenue. Fortunately PLE has also been applied to
+software engineering for many years already in the form of Software Product
+Lines (SPL)~\cite{confsplc2000}. An SPL increases reusability~\cite{Clem02a} and
+therefore increases quality and decreases development costs of software by
+building up shared core assets and customer-specific functionality. With this
+reuse in place, a business will be able to do larger scaling, with higher number
+of projects the development costs will drastically decrease compared to
+traditional engineering methods and the time-to-market will improve due to less
+development effort~\cite{confsplcAzanzaMD21}. Thus an SPL is one possible
+solution to win against competitors.
+
+But even after years of research, source code migrations to SPL are still
+complicated and there are no bullet proof concepts available that are applicable
+to actively running projects with tight release plans. Much research has been
+done on product line architectures~\cite{Svahnberg1999EPLA,
+confsplcTomashchukLJ21} and system engineering \cite{confsplcSchaferBAKR21},
+about feature model migrations~\cite{ncstrlustuttgartfiINPROC200185,
+confsplcGrunerBKR20, confsplcDuszynskiDB19, confsplcFritschAR20}, SPL
+evolution~\cite{journalssmrQuintonVRBGS21, Svahnberg1999ESPL, Eise02b,
+kconfigKernel} and safety aspects~\cite{confsplcWolschke0SAM19} of SPLs. On the
+other hand, \cite{confoopslaHetrickKM06} and \cite{confsplcAbbasJLESS20} have
+written about the overall process, general benefits and a change of mindset,
+but not specifically about source code. Contrary to \cite{confsplcRubinCC13},
+cloned variants are no option for us anymore. The authors of
+\cite{Krueger2001SMC} reported different migration strategies more than 20 years
+ago already: (1) proactive, (2) extractive and (3) reactive, but no work
+described a mixture of extractive and reactive migrations, which we needed.
+Inspired by the work of \cite{confsplcJepsenDB07} we aim for a strategy with
+which we are able to migrate multiple repositories to a monorepo, allowing
+developers and software product managers to proceed with their own pace and
+according to the project plan without risking its deadlines and always being
+able to do a step backwards if neccessary.
+
+In this paper we propose an iterative and incremental migration strategy in
+three steps. We structured the paper in the following way: Section two stating
+the challenges we faced in our projects and industry to explain our view on the
+problem and why standard solutions did not work for us, section three explaining
+our three step solution of the source code migration in detail, presenting
+infrastructure and build system ideas and section four presenting our
+conclusion, an overview on where we stand right now and giving a forecast on
+future work.