DevOps World | Jenkins World 2019 Lisbon

The development of diagnostics instruments and solutions at Roche Diagnostics takes place in
a highly regulated environment. Quality Assurance is responsible that product releases are
compliant with processes and processes are compliant with regulations. Developing software
within this environment is often interrupted by manual QA process steps. This leads to long
release cycle times and finally, new versions are not released as often and quick as they
technically could. I will talk about the approaches taken at Roche Diagnostics to integrate quality assurance into the pipeline and show a recipe towards continuous validation.

The disconnect between DevOps and ITIL/ESM practices is slowing down your service delivery, whether you know it or not. Delivering the right value at the right time doesn't allow two different philosophies as silos within the IT organization.

TOPdesk has a firm reputation in breaking down silos between service departments at their own customer organizations. Jeroen Boks (CIO at TOPdesk) used that expertise to better TOPdesk's own service delivery. Together with CloudBees, he managed to close the feedback loop of the customer experience to the backlog of development by actively engaging the service desk in this process.

Join Jeroen and Gabriel Martinez as they describe how it was done, and how every organization can successfully marry DevOps and ESM together.

In this talk you’ll learn:

1. How automation and visibility reduced TOPdesk release cycles from 9 months to 2 weeks (with a goal of 15 minutes).
2. How a shared view on available data and an integrated tool chain ensure rapid feedback for all stakeholders.
3. How to empower customer-facing service specialists to influence the backlogs with valuable customer experience insights.

Candy Crush Saga is one of the most-played, most-grossing mobile games of all time. Its success boils down to fun, tight gameplay available in an incredibly varied number of devices. Maintaining the required high quality, from concept to execution, in an agile environment, targeting all types of device - from flagship smartphones to Facebook, and everything in between - poses an incredible challenge from a CI/CD perspective.

In this session, we will explain some of the tricks we use at King, in all the layers of the CI/CD process, to help our studios deliver magic moments to players, for almost every platform available in the market, and then some.

In this talk, we will discuss the process of integrating Dynamic Application Security Testing (DAST) in a CI/CD pipeline. We will focus on web application security, but the examples can be generalized to other application security domains. Integrating dynamic security scans in a CI/CD pipeline poses unique challenges that usually are of little concern for more traditional types of testing, such as unit and integration tests. One of such challenges is the scan time. A dynamic scan, without proper care, can result in an unacceptable amount of scanning time and stall the pipeline. Therefore, we had to devise several strategies in order to balance the total scanning time and the thoroughness of the scan. We will propose some strategies, discuss their strengths and weaknesses, and give practical examples using a Jenkins plugin we built to enable DAST scans.

The end goal of establishing a CI/CD pipeline is to achieve a continuous 'flow' of releases as new features get built, integrated, tested and deployed to production-like non-prod environments, and eventually to production. This flow depends upon the continuous integration and delivery of small batches of code, data schema and environment changes. Data friction results in the inability to have the right data being provisioned to the right non-prod environment, when it is needed by the right practitioner, causing the flow to be interrupted or at best slowed. Data friction, in turn, is caused due to the time and cost it takes to provision test data sets to multiple development and test environments in a secure, compliant manner. Practitioners who manage and those who secure data need to be brought into the cross-functional teams of those who need data, eliminating these 'silos' and extending DevOps practices into the data realm.

This session will go into client tested and proven methods and practices to address data friction in the CI/CD pipeline, and show how to bring secure, compliant data, on-demand to practitioners and achieve CI/CD flow.

The current environment of Continuous Disruption requires companies to respond with Continuous Adaptability in order to survive and thrive. Lean Software Engineering lays the foundation for the ability to continuously adapt. By focusing on maximizing value delivered and applying traditional Lean approaches to Software Development Lifecycle companies can achieve high levels of time to market, quality, productivity, and employee engagement.

In this session, we'll share our experience on how to avoid the redundant execution of repeated jobs using the Results Cache Plugin.

At King, we use Jenkins extensively to build our games and execute our tests. All of King’s development departments use this tool as there is a high-throughput of screenings, which generate large volumes of diverse data. This requires a flexible approach when building integrated, scalable and robust computational workflows for building. Maintaining our games is challenging.

In the build, test and release stages, there are two main workflows: “Merge to Meta” and “Hotfix” to build, test and fix all our libraries and our meta release, which are the most common sets of shared libraries used in all King games.

For example, each of these workflows could possibly launch at least a hundred of building jobs and this amount of jobs might potentially increase in the future due to the addition of new modules and features added every quarter. Therefore, they must be tested in order to deliver a good quality product. The same Jenkins job is repeated for a substantial number of times with exactly the same parameters within King’s Jenkins servers.

Buts sometimes, the job fails due to something not related to the job itself. It might be a failed connection in a GitHub repository, a timeout in the pending jobs queue or a disk space error in the Jenkins agent. One single job failure can ruin all the work done during the workflow execution.

So, what can we do to avoid the redundant execution of something that we know worked before?

Our initial search in the Jenkins Plugins page didn’t show any plugins that would solve the problem, so we had to research it from scratch.

We wanted the new plugin to ask for the status of a previously executed job at the beginning of the job execution: If it was a success, then it would just interrupt it and return a “SUCCESS” result, otherwise, it would keep on executing the job as expected. After execution, the ideal plugin would save the result of the execution, just in case the job is executed again in the future.

With that in mind, we created the Results Cache Plugin which can be found at the Jenkins plugins site.

We've all heard Marc Andreessen's quote about "Every business is a software business." But did you know the rest of that quote includes this gem: "Cycle time compression may be the most underestimated force in determining winners and losers in tech.” If you've automated everything and have bought the biggest hardware or clouds you can afford but STILL have engineers complaining about build and test speeds, perhaps it's time to take another look at the problem. In this session, you will learn how to accelerate your builds and tests on half your existing infrastructure - and keep your engineers off the ping pong table.