When developing software that exchanges data with other components or services you may be confronted with the proper simulation of those foreign services during integration testing. This is because you need to connect with a foreign service
that is simply not available on your local machine or in a test environment.
For unit testing purpose you can use mocks that help out to simulate proper responses. There will be times where your software is deployed to a test environment
in order to perform some acceptance tests with your stakeholders before going to a final release. Usually this is also done with the customer exploring the software through manual testing. In these situations traditional service mocking is not
a good option and you need a real simulator instance that receives requests and responds with proper test data.
This is exactly what the Citrus simulator project provides for you. Standalone simulation and complex request/response processing with solid validation capabilities. The Citrus simulator provides a very easy and reliable definition of inbound and outbound messages for different scenarios.
Good news is that this is not only for Http REST interfaces but also for SOAP WebService, JMS, RMI, mail messaging and many more. So you can use the simulator whenever you need to integrate with another service that is simply not available on your local machine or in your test environment.
Docker Headless VNC Container 1.2.0 has been released today. The different Docker images contains a complete VNC based, headless UI environment for testautomation like Sakuli does or simply for web browsing and temporary work in a throw-away UI container. The functionality is pretty near to a VM based image, but can be started in seconds instead of minutes. Each Docker image has therefore installed the following components:
Which programming language should we use to write monitoring check_plugins? This question rose some discussion and this post is trying to give some hints.
I recently had to deal with two projects that have a common origin but separated at some point in time. I now had to try to bring them back together again - basically merging the changes. Sounds like a pretty standard
git merge or
git rebase job.
Unfortunately the separation was done in a not so clever way. Someone cloned the original repository, checked out some branch, made some first refactoring steps, got rid of the git stuff (probably
rm -rf .git) and started a new git repository with this status. Rumors are that the situation at that time was so tense that people wanted to make a clear cut - which they did in a technical way.
Quite some time later it was my task to try to get the projects together again. The only input I had was two git URLs and the above story.
Have you ever written a NEB (Nagios Event Broker) module? This article will explain a tool which makes this a lot easier, especially if the reason was that you are not familiar with C or C++. In this case the “Go NEB Wrapper” could come very handy and if you are new to this topic it is a good point to start with.
OMD Labs Edition 2.60 has been released today. The OMD Labs Edition is based on the standard OMD but adds some more useful addons like Grafana and Prometheus or additional cores like Icinga 2 and Naemon. This release updates many of the shiped components and adds some interesting options when resolving update conflicts.
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.