Welcome to the 4th Developers@CERN Forum!

• Luis Rodriguez Fernandez (CERN)

Room: Idea Square

I made a website! Now what?

• Sebastian Witowski (CERN)

Room: Idea Square When you finish your website (or a web app) and you are ready to show it to the world, it's not the end of your work, it's just the beginning. Users will ask you to add new features, some bugs will be discovered or you will simply have to answer some emails about the website. But before this happens, you need to put is somewhere, so people can see it and start using it. Now, how do you select which of the 1047 different hosting companies will be the best? Or where do you get a cheap domain? How do you know that your website is up and running when you don't look or how do you communicate with people who subscribed to your newsletter? You don't know? Don't worry, during this talk I will give you some examples of tools and services that you can use when launching your website (with an emphasis on cheap/free and reliable tools).

OpenShift Workshop

• Alvaro Gonzalez Alvarez (CERN)
• Alberto Rodriguez Peon (CERN)

Room: Idea Square Workshop to introduce developers to the OpenShift platform available at CERN. Several use cases will be shown, including deploying an existing application into OpenShift. We expect attendees to realize about OpenShift features and general architecture of the service.

New Webcast Website Development and Deployment

• Rene Fernandez Sanchez (Universidad de Oviedo (ES))

Room: Idea Square Over the past few months we've been migrating the webcast website from PHP to Python 3 and Openshift. We have it completely rewritten and we now use new deployment methods using CI and Gitlab.

Refocusing your domain (until a better title)

• Nikolaos Petros Triantafyllidis (CERN)

Room: Idea Square This forum's subject is from 'Zero to Production'. But what exactly goes on during the 'zero' phase? What are the questions that you and your team ask yourselves before starting to code, and which are the first decisions you make? 'Apache or Nginx? Flask or Django? PostreSQL or MongoDB? Containers or VMs?', are usual questions that are brought forward during the design phase. Albeit cool and exciting, these issues are the wrong things to consider ourselves with during the first stages of software development. What is the domain your application operates on? What are your core entities and how do they interract with each other on a logical level? Which are the business rules that would persist whether you would be creating a Web application, a Command Line Interface or simple drawings on a whiteboard? Not only should these issues be the first for a developer to consider but their importance should be clearly reflected in the application's code. In 2012, Robert C. Martin (Uncle Bob) proposed a layered software architecture pattern named 'The Clean Architecture' (https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html). Built around the Dependency Inversion Principle (https://en.wikipedia.org/wiki/Dependency_inversion_principle), this pattern suggests a code structure that places the application domain (business entities & use cases) in its very core. It aims in achieving separation of concerns and produce software systems that are testable, adaptable and independent of external systems. This talk will be a general presentation of the above architecture followed by a brief demonstration of the pattern (probably in Go).

Change deployment in ServiceNow

• David Martin Clavo (CERN)

Room: Idea Square The goal of this presentation is to show you something different from what you are used to see. ServiceNow is a cloud-based PaaS¹ product with many out-of-the-box Saas² applications built-in. Customers routinely modify these applications or create their own on top of the platform. ServiceNow is used at CERN as the Organisation's Service Management tool. In ServiceNow, everything is stored in its database; data such as support tickets, but also the application code, and even the database structure itself. During this presentation, I will quickly develop a very small application and rapidly deploy it from our dev server into our qa server; then, develop and deploy an additional small change. Along the way, you will discover how changes are recorded and deployed effortlessly. You will also see how conflicts are resolved. Hint: version control in ServiceNow is *different*. (1) Platform as a Service (2) Software as a Service

System testing software deployments using Docker and Kubernetes in gitlab CI: EOS + CTA use case

• Julien Leduc (CERN)

Room: Idea Square The IT Storage group at CERN develops the software responsible for archiving to tape the custodial copy of the physics data generated by the LHC experiments. This software is code named `CTA` - *CERN Tape Archive*. It needs to be seamlessly integrated with `EOS`, which has become the de facto disk storage system at CERN. `CTA` and `EOS` integration requires parallel development of features in both software that needs to be **synchronized and systematically tested** on a specific distributed development infrastructure for each commit in the code base. This presentation describes the full gitlab continuous integration work flow that builds, tests, deploys and run system tests of the full software stack in docker containers on our specific kubernetes infrastructure.

If only Jenkins could scale

• Pablo Gonzalez Jimenez (CERN)

Room: Idea Square Jenkins is the most widely used continuous integration server today with a 70% market share (as reported in 2015 by ZeroTurnAround). Despite this success, Jenkins remains a difficult product to administer : First, Jenkins requires the installation of numerous plugins that sport conflicting dependencies and rely on evolving configuration parameters, making them hazardous to upgrade. Second, Jenkins does not provide any support to configure or migrate agent nodes collectively. There are however numerous tools that can help with this task, ranging from the Jenkins Groovy command-line interface, to official Docker images and the new Jenkins Pipeline feature set. We will present how such tools can be leveraged to deliver flexible and robust Jenkins infrastructures, letting deploy your applications to the cloud with confidence.

NXCALS - big data logging system - deployment & monitoring

• Wiktor Jan Jurasz (AGH University of Science and Technology (PL))

Room: Idea Square In this talk I will present tools and flow that we use to make the deployment & monitoring of the system manageable. Including: - Git & Gitlab as VCS - Gradle for artifacts building - Ansible for deployment and automatic generation of environment specific documentation - Jenkins with its DSL pipelines to govern the process of automatic softwaredelivery to various environments. Apart from main deployment flow, following tools will be discussed: - Monitoring the system using Prometheus, Alertmanager and Grafana. - Log unification and browsing facilities with the ElasticSearch stack provided by IT.

How to easily offer your application as a self-service template by using OpenShift and GitLab-CI

• Alberto Rodriguez Peon (CERN)

Room: Idea Square In this talk, we will show how easily you can offer your application as a self-service template in OpenShift. Using this method, your users can run and configure private instances of your application in only a few clicks, while you maintain full control on software updates and central configuration of all instances, all this with almost no effort thanks to OpenShift and GitLab-CI. To illustrate this with an example, we will showcase our experience running the Jenkins service at CERN.

.net core application lifecycle on Openshift

• Wojciech Kulma (University of Vienna (AT))

Room: Idea Square # .net core application lifecycle on Openshift I will show an example of a lifecycle of an OpenShift application with an emphasis on the continuous integration and deployment. The application compatible with [.net Standard](https://docs.microsoft.com/en-us/dotnet/standard/net-standard) can be easily deployed on OpenShift using [Source2Image](https://docs.openshift.com/enterprise/3.0/architecture/core_concepts/builds_and_image_streams.html#source-build) functionality, which doesn't require developers to maintain docker images of the application. I will also present how to efficiently integrate this feature into GitLab pipelines with an automated deployment of the "review" environment, as one its parts.

Closing Remarks

• Luis Rodriguez Fernandez (CERN)

Room: Idea Square