Krach, Sebastian

Seifermann, Stephan

English

KITopen

Catching Up with State of the Art Continuous Integration Pipelinesin Palladio — An Experience ReportStephan Seifermannstephan.seifermann@kit.eduKarlsruhe Institute of TechnologySebastian Krachkrach@fzi.deFZI Research Center for Information TechnologyAbstractPalladio is a fairly large research project providingvarious software artifacts. The large amount of main-tained projects makes Continuous Integration (CI) vi-tal. However, CI is more useful if the source of a de-tected problem becomes clear. The earlier CI infras-tructure did often not allow tracing back problemsand even made adding new projects challenging. In2018, we decided to completely rebuild the whole CIinfrastructure and the organization of source code tocatch up with the state of the art. Two years later, wecan now report on our experience in migrating suchlarge projects as well as on the benefits of spendingthe effort in this migration.1 IntroductionPalladio [2] is still a growing research project despiteits age. Software architects use the Palladio Bench topredict the performance and other quality propertiesof their envisioned architectures using a decent setof various Eclipse extensions. These extensions traceback to many smaller, individual projects maintainedby researchers at different universities. ContinuousIntegration (CI) is one building block to monitor allthese projects for problems and report them.The CI infrastructure used till 2018 struggled withproviding useful feedback to developers. It could suc-cessfully identify compilation issues and missing de-pendencies but reported them in a incomprehensibleway. Setting up the build environment locally to re-produce the issue was not feasible either. Addition-ally, creating the build management descriptions re-quired a deep understanding of the build technology,which hindered the integration of new projects intoCI. The deprecation of the used build managementtechnology Buckminster was the last straw before wedecided to change our CI process.We collected the issues of the existing CI infras-tructure and decided to spend considerable effort incatching up with the state of the art: We migrated allshipped source code from SVN to Github to increasevisibility and ease code contributions. We switchedto the build management tool Maven Tycho, whicheases reproducing issues locally and provides clearererror messages. The build descriptions became partof the repository itself and we reduced them to a bareminimum to ease setting up builds for new projects.As of now, we used the new infrastructure for abouttwo years. CI works as expected and we successfullymanaged to do two Palladio releases. In this paper, wereport on this new infrastructure and our experiencesin migration and daily usage.2 Requirements for InfrastructureWe collected requirements for the new CI infrastruc-ture to define an appropriate solution. The require-ments mostly stem from shortcomings of the previousCI infrastructure.R1) Comprehensible Error Messages: The CI shouldprovide all details required to identify a problemin reported error messages.R2) Locally Reproducible Builds: Developers shouldbe able to reproduce build results and predictthem by executing the build instructions locally.R3) Support External Contributions: The Palladiosource code was located in a semi-public SVNrepository that required a local account on theSVN server. The new infrastructure should allowexternal users to suggest code contributions.R4) Validation of External Contributions: Beforespending effort in reviewing external contribu-tions, the CI should ensure that the contributioncompiles and passes defined tests.R5) Autonomous Build Definitions: The integrationof builds into CI should no longer require admin-istrative but only regular developer permissions.R6) Resilience to Eclipse Downtimes: Builds shouldnot be affected by downtimes of the Eclipse up-date sites, which happened often in the past.We do not mention obvious requirements such as nouse of deprecated technologies or the ability to buildall artifacts required for Palladio.3 Overview on CI InfrastructureIn this section, we report on how our new CI infras-tructure meets the requirements of the previous sec-tions. An overview on our infrastructure is given inFigure 1. We explain the components and their rela-tion in the following.Github JenkinsPush EventRepo EventStatusInstructionsArtifactsJenkins Slaves WebserverUpdate SiteProxied DependenciesFigure 1: Overview on CI components and exchanged information.To improve error messages (R1) and allow localbuilds (R2), we switch from the build managementtool Buckminster1 to Maven Tycho2. Developers nowonly have to have a recent Maven version to builda project. To ease build definitions, we introducea parent POM hosted at Maven Central that con-tains all necessary build descriptions. It is only neces-sary to specify dependencies of the project in a targetplatform. Remaining tasks like building Xtend code,source features and update sites are already config-ured. By using POM-less builds3, there is almost nooverhead for specifying the build compared to puredevelopment inside of Eclipse.To support external code contributions (R3), wemigrated all Palladio projects from our institutionalSVN repository to Github. The challenge was to notonly migrate the code but also branches, tags and thehistory. Especially, old projects like the metamodelhave a huge history with many authors. We created apython script to automate as many tasks as possible.The source code is now visible on Github and externalusers can submit code contributions by pull requests.To verify external contributions (R4) as well as in-ternal contributions, we use a Jenkins extension thatdetects and registers hooks in Github repositories ofour Github organization. We chose Jenkins over otherCI solutions because we are already competent withit. The hooks notify the build server hosted at our in-stitute about changes and triggers a build. The actualbuild is dispatched to our build slaves hosted at ourinstitute and in bwCloud4 to speed up parallel builds.The execution of the Maven-based build takes placein a Docker container to isolate build jobs on the sameslave. The idea of using Docker containers for buildtasks has already been presented earlier by Düllmann[3] as well as by Reed et al. [4]. If the build suc-ceeds, Jenkins publishes the build result to Github.We configured all master branches to not accept apush. Instead, all contributions require pull requestsand therefore are checked before merging into master.To ease defining build jobs (R5), we use predefinedbuild pipelines that developers only have to parame-terize. The pipeline covers execution of Maven build1https://eclip.se/h52https://eclip.se/h43https://eclip.se/h34https://www.bw-cloud.orgjobs, collection of quality metrics and deployment ofthe produced update site to our web server. There aresensible defaults, so the only information required tointegrate a new build job is providing the location ofthe artifacts to deploy. Developers create a Jenkinsfilecontaining this information in the repository and thebuild server automatically creates the build job. Thisalso considers pull requests and branches but only themaster branch is deployed by default.To improve resilience to downtimes of Eclipse up-date sites (R6), we proxy requests and redirect themto the more reliable mirror of the University ofErlangen–Nuremberg. We inject the proxy configu-ration via Maven settings on the build server. In con-trast to hosting a local mirror of the Eclipse updatesites, this approach saves storage space but still re-duces issues because of unavailable update sites. Ad-ditionally, the URLs in the target platforms remainthe same and local builds still work as expected.4 Reusable Building BlocksWhen realizing the previously described infrastruc-ture, we had to work around limitations of existingtools that were hindering in our context. Therefore,we created several tools that can be reused in othercontexts than Palladio.Target Platform Mechanisms of Tycho were notas modular as required, i.e. composing a target plat-form of multiple target platform definitions was notpossible. Additionally, fixed version numbers are re-quired, which are difficult to define if we use rapidlychanging nightly builds. Therefore, we developed aMaven extension5 that merges multiple target plat-forms into one, updates version numbers to the latestavailable and provides filters to switch between nightlyand release dependencies. The benefit is that develop-ers only have to define specific dependencies of theirprojects rather than dependencies to Eclipse. Instead,the extension can merge one of our predefined tar-get platforms for various Eclipse versions6. We favorthe use of dedicated target platforms to only speci-fying repositories with automated artifact resolutionbecause we plan to realize reproducible release buildswith fixed artifact versions.5https://git.io/JUmRa6https://git.io/JUmRjEcore Code Generation is essential to ourprojects because many define Ecore meta-models andrely on generated source code for handling model in-stances. The original EMF workflow supports cus-tomizations on a method-level granularity by replac-ing and annotating parts of the generated source code.For large meta-models, maintaining these customiza-tions quickly becomes cumbersome. The GenerationGap pattern [1] describes a solution by separating cus-tom from generated code through subclassing. Ini-tial support for this pattern is provided through theEcore code generation component of the Eclipse Mod-eling Workflow Engine (MWE2)7. We provide com-prehensive support for working with the generationgap as part of a MWE library8. We ensure trans-parent behaviour of depending code by renaming thegenerated parent class while reserving the meta-modelclass name for the custom subclass. Any reference,including generated factories, thereby correctly refer-ences the customized class. We further integrated theworkflow execution in a convention-over-configurationmanner as part of the shared parent POM. If the de-veloper provides suitable modeling workflow descrip-tions at a predefined location, the respective work-flows are executed at the appropriate phase of themaven build. Consequently, we engage developers toonly commit their code customizations, allowing ourCI to ensure the consistency between meta-model andthe generated code artifacts.Build Pipelines predefined by us are suitable tomost of our projects but there are some which havedifferent requirements, e. g. use Gradle insteadof Maven. In order to minimize repetitive Jenk-ins pipeline definitions, we opted for a modular ap-proach based on the Jenkins Modular Pipeline Library(MPL)9. MPL allows us to define the pipeline as se-quence of abstract stages and provide customizationsfor each stage as separate module. The modules pro-vide support for dynamic composition, thereby givingus means of fine granular extensibility. For instance,the composition allows us to reuse the same modulefor setting up the build environment in isolated dockercontainers, and exchange the module calling the buildtool inside the container. We implemented an exten-sion10 to the Groovy-based Jenkinsfile DSL to providean intuitive way of selecting and configuring the re-quired extensions to the default pipeline.5 Experience ReportWe have been using the presented CI infrastructurefor about two years. The overall experience is good.Especially, reproducing build errors locally or even be-ing able to test the outcome of the build process before7https://eclip.se/h68https://git.io/JU3bX9https://git.io/JU3At10https://git.io/JU3xoa commit is beneficial and improves confidence of ex-perienced and novice developers. Novice developersalso start defining builds for their projects, which hasrarely happened before. The review process of contri-butions via pull requests and the visualization of buildresults of these pull requests was an enabler for involv-ing more and new people in the development. Expe-rienced developers benefit from easier reviews whilenovice developers get feedback to their contributions.However, there is still a need for dedicated CI ex-perts that are responsible for monitoring and main-taining the infrastructure. The effort of these expertsusually boils down to installing updates and provid-ing new target platforms and reusable Maven descrip-tions in case of changes of the Java or Eclipse version.Giving new developers a short introduction is anotherimportant task because there is still a lack of satisfy-ing documentation of these tools. We certainly haveto improve in this field.In summary, we believe that our effort was wellspent. However, the effort was not neglectable. Themigration from SVN to Github and from Buckminsterto Maven took a student researcher about half a year.Our previous strategy of migrating projects once theychange did not work at all. Such migrations requirededicated persons being in charge of the process.6 ConclusionIn this paper, we presented the CI infrastructure ofPalladio how it improved the overall development pro-cess. The use of state of the art technology in theCI pipeline enables fast feedback cycles, code reviewsand comprehensible build results. Adding a project toCI is now possible without deep understanding of thebuild process and without administrative privileges.Practitioners can benefit from the reusable build-ing blocks of our CI pipeline. Other research projectscan consider our experiences when reasoning aboutspending effort in their CI infrastructure.As part of future work, we plan to improve the doc-umentation of all tools and the overall process. Wealso would like to define a concept for creating repro-ducible release builds based on target platforms.References[1] M. Fowler. Domain Specific Languages. 1st.Addison-Wesley Professional, 2010.[2] R. H. Reussner et al. Modeling and SimulatingSoftware Architectures – The Palladio Approach.Cambridge, MA: MIT Press, 2016. 408 pp.[3] T. F. Düllmann. Don’t just watch the containerspass by: How we (plan to) use Docker to stream-line the Kieker development process and infras-tructure. Presentation at SSP’17. 2017.[4] N. Reed et al. Automating the Build Pipelinefor Docker Containers. Presentation at SSP’17.2017.

Catching Up with State of the Art Continuous Integration Pipelines in Palladio - An Experience Report

https://publikationen.bibliothek.kit.edu/1000139241/137613615

Catching Up with State of the Art Continuous Integration Pipelines in Palladio - An Experience Report

Abstract

Similar works

Full text

Available Versions

KITopen