From this part of the post I will show you in detail the implementations of the individual components. Here I will discuss how to configure the automatic deployment, here jenkins, how exactly the interface is implemented in the web server and the most important part, how the website health checker is built up exactly.
First, I make the configuration of the jenkins. Here is a simple scenario for how to integrate the desired processes into an existing process pipeline. I’m assuming that a normal pipeline in Jenkins consists of two processes, the build and the subsequent deployment. What I am doing now is to integrate 2 more processes into this pipeline. The first process is after a successful build and before deploying. The second is executed after a successful deployment. In the end, both processes have only the purpose of calling the WebsiteHealthChecker via a provided interface and thus executing the checks. The first process collects information about the current state of the page BEFORE deployment and the second process collects information about the state of the page AFTER deployment and compares it with the results before it. This is already done automatically by the WebsiteHealthChecker, as soon as old results are available, so the interface, which is called from the jenkins, is always the same.
With the Jenkins itself I have decided to put in the processes on the Http-Request module, since it is very easy to handle Http-Request either via GET or POST also with parameters. In Fig. 1, you can see the crucial excerpt from the configuration with which I call the site HealthChecker from the Jenkins.
The URL that is being called is:
The parameters are interfaceUrl, which represents the interface of the website that provides the URLs to check, mailIdentifier, which serves as a unique identifier for the mail to be sent, and mailTo, which simply indicates the recipient of the mail, in which all the information of the check Are deposited.
All processes in the Jenkins together can be seen in Fig.2. There are the standard build and deployprocesses as well as the two new test processes, which are all executed automatically in the correct order.
As soon as these processes have been completed and the Healtch Check has been carried out, the registered recipient receives an e-mail containing the most important basic information of the last check. In Fig. 3 you can see an example of such an e-mail.
In this mail, the two types of confirmations can be seen. On the one hand, the message NOT REACHABLE, which always appears when a particular URL is not available. On the other hand, the message COMPARE CHANGED, which always appears, if the comparison of the current check to the last shows a difference either in the status code, in the browsertitel, in the markup or in the screenshot. Thus in the confirmation mail, only critical entries appear which potentially present a fault and need a more detailed examination.
In Part 4 I will explain in detail the interface of the website to check, especially the functionality with our Sitecore CMS.