DevOps with Jenkins X at Mentor Medier

The Scandinavian media publishing group Mentor Medier is in the process of replacing its old publishing solution (for digital content), in favor of Arc publishing, which is the publishing solution used and owned by the Washington Post.

Digital factory

Over the past two years, CoWork has assisted Mentor Medier with strategic IT management to lift the organization’s digital maturity. We have introduced a concept we call the Digital factory: Task control, focus on code quality, DevOps — development for operations — security and stability.

Due to the measured impact of implementing the Digital factory, Mentor Medier commissioned technical assistance with the migration process to CoWork. The tasks include migration of old content, training for new work processes, integration with existing systems, and new payment flows.

For the migration project, we could have chosen to continue using the existing CI/CD pipeline based on Jenkins. Instead, we decided Jenkins X.

Jenkins (without X) is probably the world’s most used code deployment tool. It has a long history and numerous plugins and add-ons that make it very flexible.

Jenkins X (with X), on the other hand, is a whole new product, based on the experience of developing and using Jenkins. While Jenkins is a workhorse that can do almost anything, Jenkins X offers an opinionated view of what is the best practice for development and deployment on Kubernetes.

Why Kubernetes?

So Kubernetes is a big difference.

So — why Kubernetes? Kubernetes is an open-source tool for managing IT systems. It has a large user base, and its open architecture has led to the development of a whole ecosystem of associated components.

By using Kubernetes, you can automate infrastructure setup — scaling of services, using separate environments for test, QA, production, etc. Kubernetes enables infrastructure as code — and code allows version control. Version control systems keep track of all changes, and we can easily roll out the entire environment if needed. Not least — Kubernetes is an abstraction over physical hardware, so our Kubernetes configuration is not related to a particular type of hardware or cloud service provider. We can move the entire system to another cloud provider, or — if we have to — run everything in our own private data center in the garage.

By automating time-consuming operation and development of IT systems, Kubernetes has enabled entirely new ways of working. It is easy to develop and roll out new services; it is easier to test, easier to roll back, easier to make mistakes, and not least, it is easier to correct errors. That’s why Kubernetes is one of the driving forces behind one of the recent IT revolutions, microservices.

DevOps best practices with Jenkins X

The Accelerate book documents research on what capabilities make IT projects succeed.

The main features are:

• Version control — everything is stored in git.
• Automated and continuous code deployment
• Loosely coupled architecture
• Testing of independent components
• Components are published independently
• The team makes its own technological choices (programming language, database, etc.)

Jenkins X allows us to build practices close to what the Accelerate book recommends. With Jenkins X, GitOps is a central concept, using source control as the single source of truth, storing application code as well as all configuration. When a developer is ready to publish a new feature, they have to create a pull request in git. A pull request document all code changes, and once Jenkins X detects a new pull request, it starts to build and test the code. Another team member must review and approve code changes before deployment is possible. GitOps enables documentation and knowledge sharing within the team and is an integral part of accomplishing the Accelerate ideals.

In the Mentor migration project, we use a mixture of Java, Python, and Javascript components. Jenkins X offers packages for different programming languages ​​in Kubernetes, so in most cases, you can run a simple command to import existing code into Kubernetes and Jenkins X. In “old” Jenkins, a Jenkins file defines the build process. Jenkins X uses a similar Jenkins-x.yml file to define the Tekton pipeline. Tekton pipelines are Kubernetes native, running on-demand (so-called “serverless”). Tekton can run in parallel and uses little resources, which is the total opposite of old Jenkins (without X), which is a continuously running web application, with high resource requirements.

Jenkins X is built for and on Kubernetes, which makes the entire Kubernetes ecosystem available to extend the solution with the components we need. In our installation of Jenkins X, we added filebeat and metricbeat, to provide observability of logs and metrics in Elasticsearch and Kibana. We use SonarQube to provide static code quality checks as part of our regular build pipelines.

Jenkins X at Mentor Medier has contributed to:

• Continous code deployment
• Automated tests reduce the number of bugs
• Easy and fast deployment
• Easy environment setup- QA, prod, and various
• stability
• scalability
• best practices DevOps methods (Accelerate)

A prerequisite for DevOps practices is to create a culture for sharing and collaborating. Mentor Medier, in cooperation with CoWork, had already taken the necessary steps to create a DevOps culture. Jenkins X provided the toolset we needed to develop microservices on Kubernetes, without having to spend years learning the intricacies of the Kubernetes API.