Wer kennt es nicht? Eine*r freut sich auf den nächsten Restaurantbesuch, hat im Vorfeld Google-Reviews zur Qualität des Essens und dazugehörige Fotos für einen Eindruck des Ambientes genauestens inspiziert und ist dann dennoch vor Ort bitter enttäuscht: die Akustik ist so schlecht, dass der Lautstärkepegel buchstäblich ohrenbetäubend ist, die Stühle sind unbequem und das heiß-ersehnte Steak ist ausverkauft.
Was dieses Beispiel aus dem Leben mit Qualität zu tun hat? Folgendes:
WeiterlesenAnsible ist ein nützliches Werkzeug, um schnell neue Slaves für eine CI-Umgebung bereit zu stellen. Docker ermöglicht es dabei, auch komplexe Systemlandschaften in einer solchen Testumgebung abzubilden und zu starten. Und mit Jenkins-Swarm registriert sich der Slave ohne großen Aufwand automatisch beim entsprechenden Jenkins-Server. Docker und Ansible sind in der Linuxwelt etabliert, aber manchmal fordern technische Rahmenbedingungen den Einsatz der Windows-Plattform, um bei Integrations- und Systemtests möglichst nah an der Produktivumgebung zu sein. Dass die Vorteile von Ansible und Docker auch in Kombination mit Windows zum tragen kommen können, soll der folgende Blogpost zeigen. Dabei läuft Ansible mit Linux als Kontrollsystem und es wird ein Windows-Slave mit Jenkins-Swarm und Docker Engine konfiguriert.
Es ist in Sonar möglich “quality gates” zu definieren. Damit kann die Qualität des Codes (oder des neuen Codes) gegenüber bestimmten Schwellwerten (Testabdeckung, Anzahl der Majors, etc.) überwacht werden (siehe https://docs.sonarqube.org/display/SONAR/Quality+Gates).
Wenn man den Sonar-Lauf von Jenkins aus startet, dann wäre es wünschenswert, dass das Ergebnis des Quality-Gates in das Ergebnis des Jenkins-Laufs übernommen wird. Glücklicherweise ist das mit dem neuen Pipeline-Konzept recht einfach.
Ja? Herzlich willkommen in unserer Projektwelt. Trotz über 20 Jahren Entwicklererfahrung in den unterschiedlichsten Projekten und Unternehmen, erleben wir bestimmte Problemstellungen als äußerst änderungsrestistent. Weiterlesen
Benötigt ein Prozess auf einem Linux Server eine Zufallsquelle, dann kann er hierfür auf die unter Linux Betriebssystemen üblichen Quellen /dev/random und /dev/urandom zurückgreifen. Hier gibt es einen wesentlichen Unterschied: random blockiert, wenn es keine hinreichend zufälligen Werte mehr liefern kann. Die Quelle urandom hingegen liefert weiter Werte, jedoch sind diese mit abfallender Entropie weniger zufällig.
Virtualisierte Server verfügen in der Regel nicht über Hardwareresourcen, welche sich eignen würden, um zufällige Startwerte für einen Zufallsgenerator zu bilden (beispielsweise ein Trusted Platform Modul, TPM). Auf Grund dessen erschöpft sich der Entropiepool hier sehr schnell und /dev/random liefert keine Werte mehr. Dies kann dann, wie in JDBC Zugriff auf Oracle-Datenbank scheitert mit I/O-Fehler: Connection reset (1) beschrieben, auch dazu führen, dass zwei Applikationen nicht verschlüsselt miteinander kommunizieren können.
Mit einer unserer Java-Anwendungen hatten wir plötzlich ein unerklärliches Zugriffs-Problem auf die darunter liegende Oracle Datenbank. Nach der Installation der Anwendung auf einer neuen Virtuellen Maschine scheiterte jeder JDBC-Zugriff auf die Datenbank mit dem Fehler:
[code gutter=”false”]java.sql.SQLRecoverableException: I/O-Fehler: Connection reset[/code]
obwohl der Datenbank Server selbst nicht verändert wurde. Wir konnten den Fehler mit einer einfachen Test Klasse repoduzieren und es wurde schnell klar, es liegt weder an der Anwendung, noch am Datenbank-Server.
Wir setzen schon seit langem erfolgreich Jenkins ein, allerdings war unsere benutzte Jenkins-Umgebung veraltet. Jenkins selber und die Slaves liefen noch mit JDK6 und die Jenkins-Version war 1.456. Also “sehr” alt. Schon das Einspielen neuer Plugins war im Prinzip unmöglich, weil diese in der Regel auf Java7 basierten. Mengenmäßig haben wir 20 Jenkins Slaves mit 27 Projekten und 200 Jobs. Die Projekte sind in unterschiedlichen Zuständen (gerade erst aufgesetzt, mitten in der Entwicklung, kurz vor der Release oder Wartungsmodus). Der normale Projektablauf sollte durch die Umstellung nicht behindert werden.
Wir haben uns entschieden, keine schleichende Migration zu machen, sondern komplett auf eine neue Jenkins-Version zu setzen und dabei gleich die JDK Version zu aktualisieren.
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.