Labs is a technical playing field sponsored by ConSol where we – the employees – can share our Open Source involvement. We use this site to blog about our area of personal interest, from the daily business at work and from our spare time projects.
The GitHub repository toschneck/openshift-example-bakery-ci-pipeline contains, the sourcecode for the examples of the talk Continuous Testing: Integration- und UI-Testing mit OpenShift-Build-Pipelines at the Redhat/ConSol OpenShift-Day:
At ConSol we use GitLab as our central Git server and I am quite happy with its functionality. Lately, I have been playing around with GitLab CI with the objective of finding out if we can use it instead of Jenkins, our current CI server of choice.
Since most of our projects use Maven, I was particularly interested in setting up a simple Maven build job.
To cut a long story short, yes, I would use GitLab CI in my next project. We’ll later see why, but first I want to give a quick walkthrough of GitLab CI.
It has been a while since the last release in the Citrus universe. It took us some time to get the new Citrus release 2.7.2 ready for you.
Of course we were not being lazy in that time. Besides the new Citrus 2.7.2 release we are proud to announce a new player in the Citrus team. The Citrus administration UI is a
web-based user interface that helps you to manage your Citrus projects and test cases.
Often users complained about the complexity of having to learn all about Citrus and the Spring framework in particular as Citrus uses Spring for configuration and dependency injection.
Especially non-developers had problems to master the learning curve for Citrus and Spring when starting to use the framework. Also people asked for a way to have a user interface for managing
components and tests.
We heard you and introduced a new administration user interface for Citrus! There is a detailed Citrus Admin documentation (which is still ongoing).
However I would like to outline the main features of that web UI here in a short post for you.
The Prometheus monitoring tool follows a white-box monitoring approach: Applications actively provide metrics about their internal state to the Prometheus server. In order to instrument an application with Prometheus metrics, you have to add a metrics library and use that library in the application’s source code. However, DevOps teams do not always have the option to modify the source code of the applications they are running.
Promagent is a Java agent using Bytecode manipulation for instrumenting Java Web applications without modifying their source code. Promagent allows you to get white-box metrics for Java Web applications even if these applications do not implement any metrics library out-of-the-box.
OMD Labs Edition 2.40 for the Raspberry Pi has been released today. A month and a broken SD card (excessive use of /var/swap during the builds) after the release of the x86 version it is now possible to run a full-blown monitoring system on your ARM boards. It was tested on Raspberry 2 and Raspberry 3. If you want to run OMD on one of the older models, you might experience performance problems, especially when you enable InfluxDB and Grafana.
OMD Labs Edition 2.40 has been released today. The OMD Labs Edition is based on the standard OMD but adds some more useful addons like Grafana and Influxdb or additional cores like Icinga 2 and Naemon. This releases focus is on security and maintainance and removes some recently discovered CVEs in Nagios, Icinga and Naemon.
Sowohl End-2-End-Testing als auch End-2-End-Monitoring folgen dem gleichen Paradigma – sie betrachten eine Applikation aus der Sicht des End-Users. Hier darf es keine Rolle spielen, in welcher Oberflächentechnologie die Applikation geschrieben ist oder in welcher Art sie mit dem End-User in Verbindung tritt. Genau an diesem Punkt setzt das Open-Source-Tool Sakuli an.
Typical Java backend applications need to integrate with existing 3rd party services. In most cases, calls to these 3rd party services are authenticated. Frequently, Java applications are required to use login credentials for authenticated calls: A username and a password.
This scenario raises a problem: How can we store the password needed for calling the 3rd party service? We could store it in a properties file, but then everyone with access to the properties file learns the password. We could provide the password as a command line parameter or environment variable, but then everyone with access to the startup script learns the password. We could hard-code it in our application, but then everyone with access to the JAR file learns the password. We could encrypt the password using a master key, but then we have the same problem again: How to store the master key?
The common solution is to use a secure data store provided by the operating system. Our application runs on Windows Server, so we use the Windows Data Protection API (DPAPI) for protecting our secret passwords. This blog post shows how to use the DPAPI in Java applications.
DevoxxUS has been my first Devoxx outside of Europe so far. It was a total different Devoxx experience for me compared to the six times in Antwerp Belgium that I have been to in the past years.
Yet different it has been a great conference! I would like to share some of my adventures and thoughts in this post.