Modern Java app CI/CD observability with OTel, Quarkus and Gradle en

Well-functioning Continuous Integration, Delivery, and Deployment pipelines are instrumental to the stability of cloud-native applications, including disaster recovery when things go wrong. Hence CI/CD observability is instrumental and might be as important as one for production environments. Many tools provide integrations with OTel, and initiatives like OTEP-0223 target standardizing the reporting formats across the ecosystem.

We will focus on a modern Java stack for cloud-native applications: Quarkus, Gradle, Java Flight Recorder (JFR), recent Java versions, and prominent CD systems like Dagger and Argo CD. For observability, we will use the OpenTelemetry, Prometheus, and Jaeger stack, but the same approaches can be used for other OTel collectors. Get ready for some demos and live coding!

P.S: If you are interested in the subject, join the #cicd-o11y channel on the CNCF Slack!

Leveraging Kotlin and Gradle in the WireMock project and the community en

The WireMock project and developer community are growing fast, and we need proper developer tools to offer the best possible developer experience to our key end users and contributors. WireMock has been a long adopter of Gradle, and we’re also adopting Kotlin as a language for extension development and build definitions. Same developer-friendly language for both extension code, WireMock scripting and build definitions? Sounds cool for sure!

In this talk we will delve into how we use and plan to use Kotlin and Gradle to improve developer productivity. We will take a look at Kotlin DSL for and convention plugins for Gradle builds, mock definitions build flow, convention plugins for build definitions, extensions development in Kotlin and its DSL bindings.

Modern Java app CI/CD observability with OTel, Quarkus and Gradle en

Well-functioning Continuous Integration, Delivery, and Deployment pipelines are instrumental to the stability of cloud-native applications, including disaster recovery when things go wrong. Hence, CD observability is instrumental and might be as important as one for production environments. Many tools provide integrations with OTel, and initiatives like OTEP-0223 target standardizing the reporting formats across the ecosystem.

We will focus on a modern Java stack for cloud-native applications: Quarkus, Gradle, Java Flight Recorder (JFR), recent Java versions, and prominent CD systems like Dagger and Argo CD. We will use the OpenTelemetry, Prometheus, and Jaeger stack for observability, but the same approaches can be used for other OTel collectors. Get ready for some demos and live coding!

P.S.: If interested in the subject, join the #cicd-o11y channel on the CNCF Slack!

Guerilla DevRel 2.0 - How to start community programs and *survive* in a big enterprise culture? en

In 2021 I gave a talk about “Guerilla DevRel” at DevRelCon 2021. “How to start DevRel and turn around the culture without burning out”, I said. Oh well, actually I was recovering after one burnout and depression, and heading into much more turbulence. So, here is a 2.0 edition!

Many developers care about end user experience, especially when those end users are other fellow developers. But do their companies really care? Despite the product-led growth buzz, not everyone has a DevRel strategy beyond slides. “Top-to-bottom sales for the win”, “let’s work with VPs” they say. Can a single contributor turn around the culture and introduce developer relations in a big company? Maybe! Can they burn out in the process? Well, I did.

We will talk about setting up developer relations and open communications culture in a rigid enterprise environment. How to get started without any resources? How to find allies and avoid making foes? What could possibly go right (sic!)? And how to actually make a difference and prove it? What is InnerSource and how is it related to this talk? And, if you end up in a similar situation, I will be happy to share some tips on how to preserve yourself and avoid burnout, from me and other DevRel folks with similar stories.

Common pitfalls in Jenkins security - and How to avoid them en

Jenkins is remote execution engine which has access to project data… by design. So, how secure is your instance and data in it?

When it comes to Jenkins instances with hundreds of users, it is hard to retain status quo between security itself and its impact on user experience due to the restrictions and performance degradation. I will talk about Jenkins security model, best practices and common non-newbie configuration mistakes which we often see on production instances. In particular we will discuss Groovy scripting, controller-to-agent communications and resource isolation.

Target audience for this talk: experienced Jenkins administrators and users interested in Security.

Strange Quarks, Mocking Quarks - Modeling API services in Quarkus In high density environments en

Quarkus has a lot of capabilities for local development, including the recently released Dev Services that usually runs with Testcontainers under the hood. We can leverage Dev Services for providing great real-time API provider development experiences for Quarkus based service and client apps.

In this talk and live coding session I will show how to develop a REST API and gRPC 3-tier client-service-database app with help of WireMock, Quarkus and Testcontainers. We will go through live development and prototyping APIs, mocking data and API providers, and then also using WireMock as a proxy to inject some failures and chaos into the service.

See this Google Doc: https://docs.google.com/document/d/1dhz-YZ1zpUUGnFJsgFKt1uUbSocbPkdPhlaCT-TsRfE/edit?usp=sharing

Cloud Friendly(?) Jenkins. How we failed to make Jenkins cloud native and what we learned? en

Jenkins has been one of the most popular automation servers in the world. It is widely used for CI/CD purposes in cloud environments. You may have heard that Jenkins is not cloud native, and of course it is true. You may have heard that Jenkins controllers are a legacy monolith from the 2000s. That is not true, it is quite **cloud friendly** if used right. And yes we tried to make Jenkins cloud native, but it didn’t quite work. Why?

I have been involved in Jenkins architecture projects for more than ten years, including pluggable storage, multi-tenant Jenkins, cloud native agents, breaking down the controller monolith, Kubernetes integrations, etc., etc. Some of these efforts worked, some didn’t. But it was a great learning experience that can be used by developers and maintainers of other projects that consider re-platforming them to make cloud- and Kubernetes-native. I'll talk about the technical assumptions and mistakes we made in Jenkins, and how it worked. What to keep in mind when doing the re-platforming? And do you even need it?

It is a new session. I presented a draft version of it at the CNCF Bilbao meetup on 21 Oct 2023,

Mentorship programs. Growing new team and community leaders en

Mentorship and outreach programs are often considered as side projects. Although they are a nice way to spend time and have some fun, one may say they rarely add new long-term contributors to your company project or a community. Is it true? Is it even the main goal? Or is it about team bonding and growing new maintainers and community leaders?

Let’s talk about organizing mentorship programs so that they help to grow your current community and contributors. How to involve a contributor into wider community efforts? How to help them grow and take on new roles? Let’s talk about various program types: from wide outreach programs like GSoC or Hacktoberfest, newcomer assistance, focused maintainer mentoring programs, and to individual leadership training like shadow officers.

Open roadmaps for your open communities. Not a success story, but you may have one en

As open source projects and communities grow, it becomes difficult to understand what’s going on inside. A public and up-to-date roadmap can encourage new contributors to join the project and guide the efforts of existing contributors, and also give confidence to adopters about the direction and sustainability of the projects. Is it easy to create a public roadmap? Probably. Is it easy to maintain it? Not exactly. Did we fail with it? Yes.

Oleg will share the experiences of public roadmaps in the projects he has contributed to: Jenkins, WireMock, Keptn, CDF, etc. He'll share the reasons and principles that have guided creation of *open* roadmaps, the challenges encountered, the techniques and technologies that could be used in your projects. We’ll talk about maintaining roadmaps, mistakes we made there and how we addressed them.

In particular, Oleg will describe building a roadmap with help of GitHub Projects and modern features offered by the GitHub ecosystem. That could be the easiest way for new projects and communities, and can be also useful for established projects.

* References and prior talks: https://docs.google.com/document/d/1M752I3AbE0GDdK0NpAdT9kKaiTBUjlbvUHggzfcqHZU/edit?usp=sharing
* First talk together with Mark Waite, specific for Jenkins: https://www.youtube.com/watch?v=KOZ7nbaAbp0

[R]Evolution of Open Source CI/CD en

How do Open Source and DevOps cultures impact CI/CD? "Open source is eating the world". The same happens with the domain of automation tools, including continuous integration and continuous delivery solutions. There are many open-source CI/CD tools or open-source ecosystems on the market: Jenkins, Spinnaker, Woodpecker, GitLab, Tekton, BuildBot, etc. There are many generations of these tools, with their architectures and use cases. We will talk about these tools and their evolution.

What changed since CI was introduced 20 years ago? How do Open Source, InnerSource, and DevOps impact the landscape? What's next for the tools: cloud-native environments, machine learning, etc.? How do open-source foundations, including the Continuous Delivery Foundation, participate in the evolution of developer tools and facilitate them?

Open Observability for everyone. How and Why? en

With the growing complexity of modern systems, it is getting more and more difficult to ensure your system is supportable and that you can troubleshoot current issues and timely discover upcoming problems. Large scale systems introduced application monitoring and systems like Prometheus, Nagios or Dynatrace. Microservices made distributed tracing like Jaeger a must-have for modern setups. Modern SRE practices make tracking Service Level Objectives (SLOs) essential when it comes to maintaining the quality of service. In the 2020s there is an open source ecosystem emerging around all these technologies.

In this presentation we will talk about why observability matters for your projects, regardless of the technology stack you use. And why does everyone benefit from the open ecosystem around it? We will discuss how to implement it using the open source technology stack: OpenTelemetry (for traceability, logging, and metrics), CloudEvents, Prometheus and Grafana, and Keptn for tracking SLIs/SLOs and automating actions based on them.

Fake it until you `make it`. API Integration Testing with testcontainers and WireMock en

Testcontainers has become one of the most popular tools for software integration testing. If you can put your system-under-test into a container, Docker compose cluster or a pod, this is what you're likely to use. If your target isn't ready, not containerizable or just too heavy for testing as is, you can always use mock testing frameworks, e.g. WireMock or MockServer in the JVM ecosystem. Can you combine both approaches? Sure!

In this talk, we will classify integration testing and discuss application areas for WireMock and Testcontainers, and discuss which tool to choose for each use-case. And why not both? We will discuss putting WireMock into Testcontainers, and getting the best from their features thanks to the new WireMock modules for Testcontainers. Last but not least, we will see how to put WireMock in front of the Testcontainers or your real system to do deeper tests or even chaos engineering.

P.S: We will focus on the Java, Golang or Rust examples, but the same approaches can be used everywhere

Talk script:
1) Introduction. Classification of integration testing and common issues with it
2) Testcontainers and Mock testing. Why do they complement each other? How do you choose between them?
3) WireMock. Not just a Java library anymore. What’s going there and WireMock is now “a single tool to mock them all”?
4) Live Demo
5) Introducing WireMock in Testcontainers. Why and how?
6) Putting WireMock in from of the real system or Testcontainers for fault injection, fuzz testing or chaos engineering
7) Live Demos
8) Advanced use-cases
9) How to participate and join the community?

Scheduled presentations: JUG.ch (late 2023)

Living abstract document: https://docs.google.com/document/d/1VAZcVCNDdpjuBOv6T2DP_PCQaArYjtZDnKQg-Yi2F5g/edit?usp=sharing

API Mock8s. Mocking your APIs in Kubernetes en

Distributed and microservice architectures are all about APIs these days, whether you use gRPC, REST API, Websockets or any other interface. There are tools for integration testing that involve API providers, including mocking them based on OpenAPI specifications. There are even Kubernetes native tools like Microcks that are scalable and provide valuable features and observability out of the box. More classic tools, including my favorite WireMock, are available on Kubernetes too.

If you’ve ever developed for JVM or .NET stacks, most likely you’ve heard about WireMock. It's a popular open-source tool and framework for API mock testing, with over 5 million downloads per month. It has implementations and adapters for many languages, including Golang or Rust. The project offers container images and charts for K8s and Testcontainers. There are also gRPC adapters and Quarkus extensions for cloud native Java. Sounds like a good toolkit for a cloud native App development cycle, right? Let’s talk!

In this talk I will focus on using WireMock for testing Cloud Native applications in Kubernetes, including using it for common continuous delivery and deployment use-cases. We will see how to use WireMock as a standalone deployment, or together with Microcks. I’ll also show how these approaches can be used for contract testing and chaos engineering.

This is a talk heavily focused on the demos and on some live coding. I will need to present from my laptop. Good network connectivity might be needed too. The talk can be from 25 to 45 minutes

Advanced Code Coverage with Jenkins and API Mocking en

In 2015-2018, I talked about how to use the Jenkins Pipeline and custom libraries to do advanced integration tests and analyze code coverage. Coverage plugins were rather weak, and one needed some scripts and hacks to make it work, and to DIY for distributed testing. In 2021 the situation has changed significantly thanks to the Code Coverage and Checks API plugins. Distributed integration testing also became easier thanks to better coverage collectors and integrations with API mocking tools. So, good time to be alive… and use Jenkins!

We will talk about how modern Jenkins allows you to improve and analyze code coverage. We will talk about unit and integration testing with WireMock, Code Coverage API Plugin, support for standard formats (Cobertura, JaCoCo, gcov, JUnit, etc.), parallelization for heavy integration tests and API mocking, and integration with GitHub Checks API. How can you analyze code coverage in Jenkins and when do you need to create your own libraries? And what’s the fuzz about Testcontainers and WireMock for integration testing?

I will talk about how modern Jenkins supports code coverage analysis. We will talk about Jenkins Pipeline, Code Coverage API Plugin, support for standard formats (Cobertura, JaCoCo, gcov, etc.), test parallelization, and integration with GitHub Checks API.

Outline:
- Introduction into code coverage in CI
- How was it in Jenkins before?
- Code Coverage API, and modern integrations and reporting
- GitHub integrations through GitHub Checks for “shift left” reporting
- Live Demo for a Java project
- Going further with Integration tests. How do WireMock and Testcontainers help?
- Live Demos

Public Abstract Google Doc: https://docs.google.com/document/d/1RyKhKIjiOMVOsNk386xUUD9yBCNLQyhQ3LKnRK1_SNE/edit?usp=sharing

Automate your Changelogs with Release Drafter en

[Almost] nobody likes writing documentation, and same for the changelogs! So, can we automate them and improve both user and developer experiences? Of course!

We will review the Release Drafter - a handy changelog automation tool for those who use GitHub or GitHub Enterprise. It can be used as a GitHub Action and can easily generate changelog drafts, using pull requests and labels as a foundation. Many advanced features are included, e.g. text formatting and substitutions, semantic versioning support, and management at the organization level. So let’s take this tool and configure it for a project together!

During the presentation we will also review examples from WireMock, Jenkins and other open source communities. Those examples just need copy and paste.

See https://docs.google.com/document/d/1fFSdvDyEL23VDsx9oGTQKXjI8eJMCJLW8P4sdUV5bmI/edit?usp=sharing

Want a cup of Java? API and Data Mocking for Python projects en

When working in embedded and observability domains, I’ve used Python scripting to retrieve and pre-process data from external sources, and one of the issues I’ve seen is the difficulty in reliably testing data pipelines against external services: API limits and pay-per-use costs, service outages, etc, etc. So, can we model (aka “mock”) the services to reliably test our data ingestion pipelines? Sure we can!

In this talk, I will show a few ways to build test services, databases, and API providers with the help of Testcontainers and WireMock available on Python, thanks to the container technology. Then, we will extend the approach by adding the generation of fake data with the help of Faker libraries or Synthesized that can be used for both relational data and data sequences.

Outline:

1. What is a non-Python non-developer doing here?
2. APIs in Data Pipelines, and the problem of integration testing
3. Shifting left integration tests with API modeling
4. Introduction to Testcontainers and WireMock, with examples for unittest and Robot Framework
5. Capturing and randomizing data with WireMock
Mocking data with Data Faker libraries
6. Example for Pytest, with Dev Containers
7. Advanced vector and relational data randomization with Synthesized
8. My wishlist for Python tooling

The talk was presented first time at PuData Lausanne in November 2023

Testcontainers and API mocking for C/C++ en

Testcontainers has become one of the most popular tools for software integration testing. If you can put your system-under-test into a container, Docker Compose cluster, or a pod, this is what you're likely to use. If your target isn't ready, not containerizable, or just too heavy for testing as is, you can always use API mocking like WireMock to mock your interfaces including REST API, gRPC, etc. But are these tools available to C/C++ developers? And the answer is YES!

In September 2023 I created Testcontainers for C/C++. This is not a standalone Testcontainers engine, but a C-style shared library adapter for native languages like C/C++, and also D, Lua, Swift, etc. It is an MVP SDK that can be later extended for the languages. The project is based on Testcontainers for Go which is one of the most powerful implementations. And yes, I am happy to chat about how it does [and doesn’t] work under the hood!

References:
* Repo with code and demos: https://github.com/testcontainers/testcontainers-c
* WireMock and Testcontainers: https://wiremock.org/docs/solutions/testcontainers/

See the links here: https://docs.google.com/document/d/1zrM0e8kfbBjSF8aLEq-FV4a3_ITx_OPrAiyR49srGE4/edit?usp=sharing

Mocks as Code. Modeling services in configuration management flows en

When managing service configurations at scale, it is often required to automate testing of these configurations. In software integration testing we can use Testcontainers - a popular framework for Docker and other container engines. Can we use the same for testing configurations in environments? Yes! Can we go further and mock services that cannot be replicated in Testcontainers or do not even exist yet? Also yes! There are WireMock and WireMock modules for Testcontainers at your service..

In this talk I will focus on using WireMock and Testcontainers when building and configuring your services. We will take Pulumi as a configuration management tool and Gradle as an implementation, but the same approaches are applicable to other config management tools.

References:

- Integration testing in Pulumi: https://www.pulumi.com/docs/using-pulumi/testing/integration/
- Testcontainers: https://www.testcontainers.org/
- WireMock: https://wiremock.org/
- K3s Module for Testcontainers: https://java.testcontainers.org/modules/k3s/
- Docker images: https://github.com/wiremock/wiremock-docker
- Helm chart: https://github.com/wiremock/helm-charts
- WireMock and testcontainers: https://wiremock.org/docs/solutions/testcontainers/
- Pulumi for Java: https://github.com/pulumi/pulumi-java

OpenAPI extensibility - the Good, the Bad and the YAMLy en

Swagger and OpenAPI revolutionized the API landscape and created a thriving ecosystem of developer tools, from IDEs to contract testing and no-code solutions. In our projects (WireMock, Jenkins, Testcontainers and WireMock Cloud) we adopted OpenAPI to provide a great developer, and achieved great results. At the same time, the v3 version of specification has too many limitations, especially when it comes to behavior modeling: limited extensions framework, poor response flexibility limiting complex API options, and weak examples and self documentation capabilities. Good news is that OpenAPI v4 (Project Moonwalk) addresses many of those concerns and, hopefully, could address others before the release. Let’s, wearing our end user hats, discuss the v3 experiences and how we could address them in the upcoming major release!

Last slides version: https://speakerdeck.com/onenashev/openapi-extensibility-the-good-the-bad-and-the-yamly

References:

- https://swagger.io/docs/specification/openapi-extensions/
- https://www.jenkins.io/doc/book/using/remote-access-api/
- https://www.jenkins.io/projects/gsoc/2024/project-ideas/automatic-specification-generator-for-jenkins-rest-api/
- https://docs.wiremock.io/openapi/
- https://www.wiremock.io/post/creating-mock-api-templates-from-openapi
- https://github.com/OAI/moonwalk

Les Trois Moque-taires - Tous comme un, un comme tous (sic!) fr

Lorsque vous modélisez (aka “moquez”) des services pendant le développement en Java, vous devez imiter l'APIs, le logique métier, les bases de données, les données réalistes. On ne peut pas le faire simplement avec un seul outil, il faut en combiner plusieurs. La bonne nouvelle est que l'écosystème des Testcontainers permet de le faire avec quelques lignes de code!

Dans cette session, je montrerai quelques façons de créer des services de test, des bases de données et des fournisseurs d'API à l'aide de Testcontainers et WireMock pour un projet moderne basé sur Quarkus et Gradle. Oui, nous ferons du codage en live pour le client et le service, sans aucune re-build en CLI et délai! Ensuite, nous étendons l'approche en ajoutant la génération de fausses données à l'aide de bibliothèques Faker ou Synthesized qui peuvent être utilisées aussi bien pour les données relationnelles que pour les séquences de données.

P.S: Et qui est d’Artagnan? Préparez-vous à une surprise!

Testcontainers et WireMock ont été très populaires dans l'écosystème Java. Dans cet exposé, je montrerai comment les combiner et augmenter la productivité des développeurs pour une pile technologique moderne. Il n'y a pas de telles discussions en français pour le moment